Re: [Rails-devel] Phase mgmt step 4, and 18TN Civil War (cee06b)

[Erik V. <eri...@xs...>]

Some answers below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]


> > 1. Phase management step 4: <Phase> can now have an <Action> child
> > with
> > (required) name and (optional) value attributes.
> > Each action causes gameManager.processPhaseAction (name, value) to be
> > called when that phase is activated.
> > GameManager in turn calls processPhaseAction(name, value) in the
> > current round.
> 
> I do not need to remind you that I am not happy that the Round mechanisms
> get more complicated again. Is there really no solution possible that
avoids
> putting phase mechanisms inside the rounds/gamemanager classes again?

GameManager is the central action broker, and action execution is controlled
in the various Round classes. 
That's the current architecture, and I have no plan to change that,
certainly not without a clear vision on what could be a better architecture
and a road map to get there.

Another reason is that I did not want to make this new feature specific for
any particular type of action.
I could have restricted its reach to company properties by putting this new
method into CompanyManager (and subclass it for 18TN), but then this new
phase-action mechanism would no longer be generic, which is what I want.

And thirdly: if we would start scattering around all kinds of action paths
over all kinds of different managers, that would IMO rather complicate than
simplify the structure of Rails.

> > 2. This new feature is used to implement 18TN Civil War (except the
> > revenue calculation).
> > The new code is in OperatingRound_18TN (updated) and
> > PublicCompany_18TN (new).
> > The latter method has a civilWar BooleanState that is set and unset
> > according to the 18TN rules.  This already works.
> 
> Again OperatingRound ;-)

Inevitable, as I'm overriding an existing OR method to implement this
specific 18TN feature.  Besides, OperatingRound_18TN already existed for
other purposes.

> So my solution will be that PublicCompany_18TN will implement a
> RevenueStaticModifier and will remove the shorter train
> 
> I assume that you have implemented the rule that a company with only one
> train (thus zero revenue) has its token unmoved instead of going left.

Yes.  It works.
 
> >
> > 3. To fully implement the 18TN rules, the CivilWar setting also
> > requires
> > publicCompany.hasRoute() to return true.
> > This is a new stub that always returns true (and is not used anywhere
> > else yet).
> > I hope we will once be able to detect route existence in the game
engine.
> 
> Existence of a route checking is easy to implement and is on my todo-list.
> I will add that asap.
> 
> >
> > Stefan, I trust you will now be able to finish 18TN completely by
> > implementing the effect of the Civil War on the revenue calculation.
> >
> > To check the company CivilWar status you could call its isCivilWar()
> > method directly , but from an architectural POV (client/server
> > separation) it would be preferable, if at all possible, to create an
> > Observer
> > (ViewObject) per company to register at the ModelObject
> > (=BooleanState) via the company getCivilWar() method.
> 
> No the push mechanism I use here is the RevenueStaticModifier (see
> above).

Fine.

Erik.