I'm currently fiddling with the data hierarchy. That is, the convenient way to record all the many variables (and lists...) describing a ship in terms of a game system. Yes,
a game system - I'm planning at least rudimentary support for Rogue Trader and SJG Ogre too.
Currently, I'm thinking something along these lines (instead of lumping all variables together the way they are now):
class ShipData
- contains several system-agnostic variables, notably coordinates of all important components (the ship, the vector, the number of models and model type, as well as the type/size of the formation; and finally the fleet to which the ship belongs - e.g. "Player 1's Fleet").
- A variable that indicates which game system is used with this ship (it should not be allowed to load a ship made for GURPS Spaceships into an Ogre landscape and vice-versa).
- an instance of each of the several (3) game system-specific classes (see below), of which only one is used at a time.
class GameSystemSpecificClass (name subject to change)
as an abstract class only, maybe with some methods that are identical between game systems (e.g. . Maybe, just maybe, it should be enumerable (if I can implement that - not sure yet)
class GURPSSpaceshipsData (inherits from GameSysSpecClass class)
contains a series of variables/properties, some of the public/writeable, while others only supporting a get accessor (due to being calculated from other properties)
class RogueTraderData and class OgreData (ditto)
as the GURPS one.
-------------------------------------------------------------
Does this look as a reasonable course, or are there some things I am going to regret later?