From: Erik V. <eri...@hc...> - 2006-09-14 19:41:10
|
> > 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. For clarity (and to open up name space), I have renamed the package game.action to game.move and the old class (game.action.)Action to (game.move.)MoveSet. A new package game.action will hold the allowed action classes. The base class is PossibleAction and I have started with LayTile. I hope these changes does not create too much confusion.... Erik. |