Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformationhangs game

[Stefan F. (web.de) <ste...@we...>]

Erik,
I know it is still a lot of underspecified ideas. It is good to know that it 
does not raise immediate and spontaneous rejection. 
And the best way to address concerns is to provide working and readable code 
examples, thus that will be something I will work on.

The step-by-step approach is two-fold:

1) Working on smaller bits (StartRound or ShareRounds instead of 
OperatingRound) or special classes

2) Keeping the new structure side-by-side to the existing code and only 
activate it for the test case 1870 in the beginnig. This is easy to do, as 
there are several hooks to activate different classes for game and round 
management.

After that you can still decide to follow that path or not, considering the 
implementation examples.

A few comments / replies to encourage more discussion:

* My own first idea was to use a specific trigger interface and require 
triggers to be explicitly defined. But I realized that the moves are 
excellent triggers and the Moveset a very good place to pass the messages.
Moveset could still delegate the task to a TriggerManager, if a better 
separation is required.

And I want low-level triggers, to avoid that every (high-level) implementation 
has to remember to call the trigger.

Take the example: A candidate in the long run ist the function that checks if 
a company is floated. Every (high-level) method that moves shares out of IPO 
has to check if the company has floated. If the trigger is used, this is done 
automatically. This would also cover special cases in games, which are not 
yet implemented.

(However it might be optimal to provide a generic version of ObjectMove to 
simplify that).

* I agree, the break-up into actions/action controllers and the separate 
sequence control provides the granularity/modularity that is required to 
configure the flow of actions by an XML file. But the XML file itself is for 
sure the end and not the start of the process. 

And you are right: The sequence manager should take care of the different 
types of action (availablity and conditionality). Currently I see three major 
classes of actions:
A) Required
B) Optional, but in sequence
C) Optional, always available 

The basic OR consists of:
1) Tile Lay - B
2) Token Lay - B
3) Train Run and Payout Decision - A
4) Buy Trains - B
5) Buy Privates - C

I intend to have two modes for the action availibility:
Beginner mode: Always offer the next A or B action
Expert mode: Offer all actions in sequence until the next A action or the next 
player/company takes over.

The current client of Rails currently supports only beginner mode, thus 
everything is offered in sequence and one has to inform Rails that one 
intends to not lay a tile or token. 
In the expert mode at the start of the turn tile lay, token lay and payout 
decisions would all be available. In fact Rails would already suggest the 
current optimal run and after each tile/token lay update the best run 
accordingly. A choice of a later action deactivates the earlier actions. 
(Thus a token lay would make further tile lays impossible.) Lemmis moderator 
is an example of the expert mode. 

This does not mean that I intend to change the client now, but I intend to 
make the backend compatible for future enhancements.
Stefan


On Saturday 26 June 2010 16:01:51 Erik Vos wrote:
> See below.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Saturday 26 June 2010 00:24
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
> duringCGRformationhangs game
>
> A) Triggerable Events
> 18xx games have a major class of triggers: Purchases of trains can change
> the
> (game) Phase, which themselves (potentially) impact any dimension of the
> game
> play.
>
> Rails implements that already with the Phase/PhaseManager class.
> But digging deeper, nearly every 18xx has some actions, which have
> side-effect, but are not (full) phase changes. Even in 1830 there is at
> least
> one example: The purchase of the first train by public B&O closes the
> private
> B&O.
>
> A very striking case is the destination run in 1870. Each tile lay a public
> company can trigger this sequence of several actions for any other company.
>
> On the first glance I believe there should be a a trigger / triggerable
> interface combination. But Rails already has a potential trigger
> infrastructure in the state/move objects. Thus triggerable objects should
> define the potential moves/state changes and register themselves to those
> changes.
>
> [EV] Perhaps a better example is the existing Phase.addObjectToClose()
> method, which in fact provides a register-for-callback function. It's
> currently used to close/remove some specific privates, bonuses and bonus
> tokens; in this case, on phase changes only. Indeed I already had in mind
> for some time to extend this function for wider use.
> Closeable could be extended to (or become a subinterface of) Triggerable.
>
> [EV] I doubt if it would be wise to overload State/Move with such new
> functionality. It's low-level, and IMO should stay so.
>
>
> B) Round/Turn Sequence and Queuing
> The sequence of rounds and that of activities inside of rounds is currently
> managed inside the classes implementing the executing logic. There is no
> (additional) framework/classes controlling the sequence alone.
> Any interruption of the standard sequence requires some tweaks to make that
> happen. And one has to be carefull to make it undo-proof.
>
> There are several examples already in Rails for such interruptions
> (especially
> the treasury shares and merger rounds). 1870 would add for example share
> protection here, which changes the sequence inside a stock round.
>
> A general framework (call it SequenceManager) which controls the sequence
> of
>
> rounds and turns (activities inside a round) would make thoses cases
> easier. New rounds/turns would register themselves with the
> SequenceManager, which should also support the queueing of rounds/turns
> (take merger rounds as example, which might occur only after the round/set
> of rounds is finished). It also manages the consequences of undoing those
> sequence changes.
>
> [EV] This reminds me of an idea that Brett and I have discussed several
> years ago (should be in the archive): to make the [OR] actions and their
> sequence configurable (in Game.xml). Some actions can only be done in the
> proper sequence, like tile/token laying. Some steps are optional or
> conditional (e.g. must have the money to lay a token). Some can be executed
> at any time (private buying). An XML structure should be designed to cover
> all such possibilities.
>
> [EV] Currently, sequence management is shared between the rounds and the
> game manager. I don't know how that could be pulled out into a separate
> structure, and whether it should, but it might be an idea worth further
> consideration.
>
>
> C) Splitting of the Round Classes
> The two subclasses of Round are currently the swiss army knives of Rails:
> StockRound and OperatingRound are the main generator and consumer of
> actions
>
> (in addition they are responsible for the correct sequence of activities
> during Rounds, see above).
>
> This has some benefits (espcially synergies with respect to joint variables
> and commonly used methods), but would work not very well with the more
> flexible structure suggested in B. To gain the full benefits breaking up of
> the round classes into smaller sub-units is required, at least from my
> point
>
> of view.
>
> My suggestion here is to use an action type as the atomic unit for such a
> split. Thus for example a LayTile action works in parallel with a
> LayTileController, which generates the action and processes the actions.
>
> The final configuration would look like that (somehow simplified):
>
> A (simplified) OperatingRound controls the sequence by adding the different
> Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.
>
> The SequenceManager would activate the controllers according to the defined
> sequence. The controllers would generate actions and process the responses
> from the UI. After executing their actions the controllers would deregister
> themself from the SequenceManager.
>
> [EV] How about the fact that several different actions types might be
> allowed simultaneously? Such as private buying and loan taking, that in
> many games can be done at all times during an OR turn?
>
> How does a destination run in 1870 work?
> This special (game specific) object is triggerable by TileMoves and checks
> if
> the conditions for a destination run is met: If so, it adds itself (or if
> possible a modified Revenue and LayToken controller) to the SequenceManager
> with the instruction that those actions are queued at the end of the turn
> of
>
> the acting company.
>
> [EV] OK, this kind of answers my question above. However, I would rather
> trigger it by the LayTileController finding that the action is/can be/has
> been executed, rather than the TileMove, which is only the physical
> execution phase. See my comment above.
>
> I have already some ideas, how that structure offers better support for
> optional actions and special properties, but I want to focus on the general
> ideas first.
>
> So what are you comments? All of this will for sure not be done in a single
> step, but only step-by-step.
>
> [EV] I wonder to what extent this can be done 'step by step'. In particular
> C) will be hard to do stepwise.
> I would propose to start with a pretty isolated case, like the 18EU start
> round. Or the 1835 start round, which has old code that needs an overhaul
> anyway.
>
> [EV] It's too early to give a final answer to your ideas, but it all sounds
> rather good, and, as said, partially fits with ideas I already had. But you
> are going a lot further, and I can't yet quite oversee everything. An
> actual working case might make it much clearer.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel