Re: [Rails-devel] Allowed user actions (was: M&H)

[brett l. <wak...@gm...>]

Comments inline...


On 8/13/06, Erik Vos <eri...@hc...> wrote:
> It's a very old message that I'm replying here to.
> I have looked it up because it was about the last time that
> we discussed the subject of special properties.
>
> I'm revisiting this subject, partly because I've encountered it
> in a different context in 1835, and partly because I just discovered
> that the existing extra tile laying code for 1830 is broken.
>
> There are two aspects to be considered (applied to tile laying):
>
> 1. The game mechanics should be aware of extra tiles to be laid,
> and, if necessary, extend a player's turn to allow for it.
> This worked 7 months ago for 1830.
>
> 2. Make the user clearly aware of this special situation.
> The only clue so far was that the current player highlight did not move
> after laying the first tile. To do something about this,
> I have just added an extra prompt message (in red) to the
> existing prompts above the map about the option to lay an extra
> tile or token.
>

Agreed.  I prefer using the prompt messages instead of messagebox popups.


> However, my main concern is that the current way in which the UI
> and the game engine communicate, pretty complex as it already is,
> will not easily accommodate different special property types and
> their application rules. I'm always keeping in mind that one day
> we want to turn this into a client/server application.
>

Generic 18xx is a complex endeavor.  I don't think we have any choice
but to gradually increase the complexity of the main subsystems.

> For a solution I would propose the following approaches.
>
> 1. The game mechanics:
>
> I think the best approach is to generalise a mechanism that already
> exists in some contexts, i.e. train buying and share buying and selling,
> and that I have found very fruitful so far.
>
> The generic mechanism would be, that after each user action the UI would
> get a fresh and complete list of all allowed actions at that point,
> including state information about who's turn it is etc.,
> by one or two calls to the Model.
> This will reduce (or hopefully completely eliminate) the current need
> for the UI to have it's own (partial) state memory.
>
> For this end we will need a new "allowed actions" class hierarchy,
> derived from some abstract base class. The result of the above-mentioned
> "what can I do" call would then be a List of objects which are
> instances of subclasses of that base class. The existing class
> BuyableTrain would become such a subclass.
>
> An example of such an object would be "Lay a tile on hex XY".
> This would already work for the special extra tile lays.
> We can't yet restrict normal tile lays, so we would
> have a blanket "lay a tile anywhere" object instead.
> Once we have route awareness, this would be replaced
> by a series of objects, one for each hex where a tile can be laid.
>
> (I think this approach would also make the future client/server
> separation easier: a main component of the client-to-server information
> stream could exist of a serialized version of this List).
>
> I'm looking for a good and shortish name for the base class.
> We have already consumed Action, Move and Option.
> AllowedAction might do, or UserOption, but I would prefer a short
> one-word name that can easily be incorporated in its subclass names.
> What about Play?


Overall, I like this idea.

I think AllowedAction or UserAction are good.  The problem with
single-words is that they're very ambiguous.

I'd like to keep the API reasonably descriptive. Hopefully it will
make the learning curve for any new developers slightly less steep.


>
> 2. The UI:
>
> A corollary of the above approach would be, that the player turn will
> never be over if the allowed-actions List is not yet empty.
> So we will need an always-available Done button
> (in fact the current No Tile and No Token buttons have that role,
> but for clarity I would prefer to get rid of those).
>

I'd really like to see the No Tile/No Token button merged with the
Done button, and just continue to change the text of the button to
represent it's current action.

However, I don't really like forcing the user to step through each
phase. I'd really like the UI to do something along the lines of
SimTex's 1830 game, where you can skip unneeded phases by choosing the
option you want to do.

I'm not certain we could do this without reworking our phase handling
a bit, though.

> We could still accommodate an automatic end of a player turn if the
> allowed-actions list is empty, but we should then tell the user about that.
>
> What about a popup saying something like "End of turn for A, it's now B's
> turn"
> that would appear *each* time when a new player (or President) gets the
> turn, regardless whether the turn change was automatic or triggered
> by pressing the Done button?
>


As mentioned above, I prefer using prompts rather than pop-ups.

I personally get annoyed by applications that overuse modal pop-ups.

However, a popup may be something that is necessary when we implement
hidden money values, so that we hide all values, pop-up the player
change, then redraw only the current player's wallet.


> To exercise special actions that fall outside the normal sequence of
> events in a round, we could add a menu bar, with options that would
> only show up (or be active) when such an action can be exercised.
> In 1830, this would apply to buying Privates and the M&H/NYC swap.
>
> The above is mainly of interest for the OR.
> I'm not sure if we should extend this to the SR, where we already have
> the situation that Done/Pass must always be pressed to end a player turn.
> However, here also we could implement an automatic turn end (with warning)
> if there is nothing a player could do (i.e. the allowed-actions list is
> empty).
>
>

Agreed. I think most SRs don't really add as much complexity as the ORs.


----Brett.