edit: clarified my question. I also realized that I didn't pick a very conclusive question title, which unfortunately I cannot change anymore, sorry.
to improve my programming skills a little and getting familiar with good design patterns, I'm trying to program a litte turn based strategy game, and I am at the point to choose a good data structure for the configuration of different terraintypes and unittypes etc. which do exist.
What I have implemented so far is a big "Game Object" with knowledge about everything in the game, and many of its properties are big associative arrays (I'm using PHP, but my question doesn't really have to do much with the language), for example an arrays of units, a map array.... What my array structure is comparable to is the type object pattern mentioned here.
Example: A single unit is of a certain type, say 'Infantry', and shares many data with all the other infantry untis on the field. Instead of copying all these values, I give every unit a "type" so it can look up the details there. Similar with terraintypes. Example:
terraintypes = array() terraintypes = array() terraintypes['name'] = 'Forest' terraintypes['capturable'] = false unittypes = array() unittypes = array() unittypes['name'] = 'Infantry' unittypes['movecost'] = array() unittypes['movecost'] = 5 //Movementpoints needed for forest unittypes['movecost'] = 7 //Movementpoints needed for terraintype 1
A specific unit or tile on the map wouldn't know its movement costs or name, but would be able to look that up in the
unittypes array. Example:
sometile = array(); sometile['owner'] = whatever sometile['type'] = 0; //this tile is a forest someunit = array() someunit['type'] = 0 //This is an "Infantry".
The problem is that getting any kind of information will produce very verbose code, for example finding out how much it costs for a
unit to move onto a
tile will be
I am trying right now to move to using more objects and classes, so if I give a unit a reference to its unittype, it can lookup information itself, for example
terraintypes = new Terraintype('Forest') unittypes = new Unittype('Infantry') someunit = new Unit(unittypes)
Now, if I ask a unit something only its unittype would now, the unit can look it up itself, e.g.
someunit.getName() will be implemented in the unit like
So far so good. However, how could a unittype store its movecost on the different terrains? Basically I would need an array indexed with terraintypes, but as that is not possible, I will have to swhich back to translate everything to numeric keys, and have a movecost value for every pair (terraintype, unittype).
Who assigns these numeric keys and where? Will every single unittype need to store some kind of identifier which is unique among all the unittypes?
Should I use some constants like
const FOREST = 0; const ROAD = 1; const INFANTRY = 0; const VEHICLES = 1 etc?
Another of my problems for finding a good data structure is that if I don't give the game all the data directly, but break everything down to smaller parts, then many parts will need to know about the same objects.
For example, if the Map object knows about all tiles of the map and the units on it, then the game doesn't really know anything about the units, it only knows about the map, and every command in the game which affects a unit needs to be passed to the map, even though its not actually a "map task", like healing units.
This seems like breaking the single responsibility pattern. However, storing references to all the units in several places (so both the Map and something else store references to units) seems to be troublesome with bookkeeping.
To sum it up a little, can you hint me to data structure which are suitable to represent what I am describing? Thanks in advance!