[Rails-devel] Current implementation, branch Rails 2.0?

[Stefan F. <ste...@we...>]

On Wednesday, August 10, 2011 12:31:42 pm Erik Vos wrote:
> 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.

Erik,
I do not agree here with your design:

In my understanding of Rails the term action is something different: All of 
them are user's actions and extend  the abstract class PossibleAction and 
belong to the rails.game.action package.

This new kind of "action" is in my eyes a named trigger which is activated by 
the train purchase. There is no need to pass the trigger through GameManager 
and Round classes with new methods and then call from the OperatingRound the 
method inside PublicCompany_TN.

My preferred solution would have been the possibility for PublicCompany_TN to 
register themselves with the PhaseManager and then get updated directly.

And only by convention actions are passed from GameManager to the Round 
(sub-)classes , but they design neither encourages nor enforces this:
Take for example the correction actions, they are processed in individual 
manager classes, and there is one for each action. If I have taken your 
approach all code inside the correction package would have been added to the 
GameManager too.

And that is my proposal or roadmap for those classes: Try to get GameManager 
focused on what is required for the top level class of the game (thus mainly 
storing the other component managers and interacting between them). Clean up 
the Rounds to include only the mechanisms to proceed from activity/step to the 
next and to switch between players/companies. All action processing should be 
done outside in individual components/classes.

For you it might seem easier to have everything in one place/file, but  I 
would prefer to refactor it somehow, before I am able to implement required 
adjustments for other games. 

Similar as it is difficult for you to write revenue code, it is difficult for 
others to change the Round or GameManager classes. But if nearly everything 
important is inside those classes, no one else will be able to help you 
implement the parts of new games that require changing those classes.

But if you split those classes into smaller pieces it makes it easier for 
outsiders (including myself) to understand the insides and it is less risky to 
change it without causing side effects.

See below for some stats if you do not believe my words.

My intention is not to blame you or to a blunt critique: It is my sole 
intention to help with coding. But I realize that I am mainly adding code 
around the core (revenue calculation, configuration, correction, states etc.) 
as I avoid touching the Round/GameManager  components.

And adding another algorithm for revenue gets a little boring if we are still 
waiting for 1825 and 1835 to work properly/fully.

However as I seem it hardly possible to refactor against a moving target (as 
you are stilling adding new functions to the core classes - and rightly do so, 
as long as there is no alternative), I suggest to create a new branch inside 
the git repo for a potential Rails 2.0. 

This branch would allow to refactor main parts without any fear to break the 
existing code/games/save files etc. It would also allow cleaning up from 
legacy code and components and a better support for unit testing.

In the main trunk new games/features could still be added to Rails 1.x, until 
Rails 2.0 is stable/mature enough.

Stefan


Some numbers on the size of classes in Rails.

The package Rails.game has 40960 instructions.

From those are the 5 largest
OperatingRound 7062 
PublicCompany 3817
GameManager 3623
StockRound 3200
MapHex 2962

And here you still have to consider that for PublicCompany and MapHex most of 
the code is in fact initialization and configuration.

Compare this to the top 6 largest packages (after rails.game)
rails.ui.swing 27949
rails.algorithms 12198
rails.game.action 5616
rails.ui.swing.hexmap 4792
rails.game.specifc._1856 4538
(from those the largest are again Round subclasses with a
sum of over 4000 instructions).
rails.game.specific._18EU 4136
(from those the largest are again Round subclasses with a 
sum of over 3000 instructions). 

Taken altogether it is not too far fetched that nearly 50% of all Rails.game 
code is part of the Round classes and subclasses. And the largest of it 
exceeds all other packages of rails except two.

And if you think about so important packages like move, model and state:
rails.game.move 1776
rails.game.model 863
rails.game.state 798

And those three packages consist of 10+ classes each.