From: Stefan F. <ste...@we...> - 2012-09-03 19:45:25
|
Erik: actually I do not think I have changed the layer/package structure substantially. To the contrary I tried to keep most of the terminology and structure of Rails1.x. I mostly agree with your characterization, however I do not agree that the game components classes and the round classes are in different layers. I think that the game logic is shared between the two in the current implementation and it is the correct way to do so. Or better: That there is no correct way to create a strict separation such that the game logic is only kept in one or the other. So my current understand about the Rails structure: 1. There is a core engine layer in rails.game.state, which provides A) The Change/State mechanics B) The Item hierachy C) Portfolio and Wallets are a hybrid of both A) and B) This layer does not assume anything about 18xx games at all and could be used to support any other (board)game computer implementation. 2. The main 18xx classes in rails.game, which provides A) The game components like Bank, Companies, Certificates etc. B) The game mechanics like Rounds C) Managers are a hybrid to link and support A) and B) This layer should support all standard elements of 18xx games, but no special stuff. I intend to split that into sub-packages as rails.game really grew very large. I was considering something like rails.game.components and rails.game.rounds 3. The main classes use components from the following packages A) rails.game.action for game actions B) rails.game.model for components that can be observed by the UI C) rails.game.special for special properties I believe that the separation between 2. and 3. is not a very strong one, as there is a strong interdependence between elements both in 2. and 3. E.g. it would make sense to put the related models and the game components into one package. 4. Then there are two service packages A) The rails.algorithm package for network calculations B) The rails.correction package for correction mechanisms 5. And two utility packages C) The rails.common package for xml parsing and other supporting services D) The rails.util package for further utilities, which do not find anywhere else 6. UI packages in rails.game.ui.* 7. Game specific packages in rails.game.specific.* The dependency structure is: The game engine (2/3) depends on the core(1) and utility(5) The service classes (4) depend on the game engine(2/3) The UI(6) depends on the game engine (2/3) and the service classes (4) Game specific classes either change the game engine(2/3), service classes(4) or the UI(6). > > Now we have (at least) three layers (in my view). The terminology is mine > (and I have used a similar concept successfully several times throughout my > career in IT): > > 1. The application layer. In Rails, that's mostly the Round classes. > > 2. The service layer. Companies, Portfolios and such. I think the Managers > belong here too. > > 3. The lowest layer (core). That is (in Rails) where you register States, > move items around, manage Undo stacks etc. > > In my opinion, your "little bit more complexity" should be handled in the > service layer. If that is what you intend to do, I'm happy. > But if you put it in the application layer, then I start worrying. > > Erik. > |