Blu3wolf
commented
5 years ago It seems like there is room to have an Assault class, which would handle individual combats in Anti-Armor and Close Assault steps. Each instance would list the user's units involved in that combat, their target hex, potentially a second target hex... class methods would include many of the steps in Anti-Armor and Close Assault combat. The object would be created when the user assigns units to attack a hex. If further units are assigned to attack the same hex, those units are added to the existing object rather than creating a new object. The object would be destroyed once the assault it represents is destroyed (or cancelled).
The 'obvious' way to me at this stage is to have a single, top of model, object, which contains information about the game state. This would presumably be a Game object, with properties containing what phase/step the turn is at, whether the software User is the phasing player or not, what Game Turn we are up to, whether the User is CW or Axis, and at a guess, one property would be a List of every Unit the User has. Potentially another List would contain every Counter the User has. Possibly, another List could contain Notes, which the User has made in particular Forms, for gathering intelligence on the enemy, particularly intelligence gathered from combat results.
The Game class would also contain methods that allow the Game to advance. This might include things like advancing to the next phase, skipping through to the next applicable phase, ending a game turn, or they might cover things like providing a list of all units in a particular hex, or adjacent to a particular hex, or represented by a particular counter.
The process described in #4 Combat more or less seems like it would be a function, or a series of functions, of the Game class. So the Game class would handle all combat, calling functions of Units to modify their state based on the game rules and input from the User.
This Game class then would be instantiated when either a new game is created, or a saved game is loaded. A new game would be started by instantiating the Game object using values for a Scenario. The default state for Scenarios could be saved in XML files, each file representing a given Scenario. Potentially, a Scenario Editor could be written that would allow editing and creating new Scenarios using a simple GUI to write and save the equivalent XML file.
A saved game could be loaded by instantiating the Game object using the values that were saved previously. For initial development, it seems like saving the state of the Game could be accomplished by writing it to an XML file. For future development, it seems like some form of networked arrangement would be beneficial, possibly with an online database. This would be to allow for a future version to have multiple clients planning their respective parts of a turn, ahead of their stage of the turn, and saving their plans to the database, to be implemented once their part of the turn arrives (similar to the process of play for the actual game, where responsibilities are shared among 5 to 10 players per side). This thought is handled in #6