#### Archived

This topic is now archived and is closed to further replies.

# strategy(war) game memory

This topic is 6017 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Real-time or turn-based, what are some ways people have stored information on units in strategy games? Also, what''s the largest number of units anyone has seen in a strategy game? Create.

##### Share on other sites
That''s a bit of a loaded question, so I''ll try to answer it as best I can. I''m assuming you mean storing units to disk and just in the game in general, correct?

The simplest approach to storing a unit would be to simply store it in a structure like so:

struct StrategyUnit
{
float x, y, z;
int health;
int team;
}

The great thing about this approach is that it''s extremely to easy save and load the unit to disk because you can read and write the entire structure to the disk with one call (like fwrite(&MyUnit, sizeof(StrategyUnit), 1, File) or something similiar)

However, the problem with this method is that it''s not very extensible. Say we decide that we also need a tank in the game, if we add a Tank structure we have to write all new file routines that can save that Tank. That may make our old save games unreadable since they were saved before Tanks were expected to exist in our maps. Also, we will have to create an entirely different array/list/container to store the tanks in since they''re different from the StrategyUnits. Not to mention that this also requires we make an entirely new set of functions to manipulate the tank.

So, instead we should go with something more extensible. Say we go with a class like so:

  class StrategyUnit{protected: float x, y, z; int health; int team;public: StrategyUnit(); virtual ~StrategyUnit(); virtual void Update(); virtual void Draw();};

Now we have a much more generic structure, and if we want to create a tank we can simply derive it from the StrategyUnit class and we don''t need to rewrite Draw and Update unless we need more specialized functionality (notice that they''re virtual). This approach works really nicely, and it''s easy to work into a scene management scheme since all objects can be cast to the base type. Unfortunatly, it doesn''t work very well if you want to save the unit to disk (the trick above won''t work because the class has a virtual table). Plus, it still doesn''t solve the problem of the save game format being forced to change when you add a new type.

There isn''t really a good way around the file problem short of text files or making a really robust file format. The best thing I can recommend doing is to make a non-virtual unit class which contains all the attributes that need to be saved, and then just make it so that that''s the only type which is written to disk. For example, the class might look like so:

  class FileUnit{public: int x, y, z; //attributes we want to save for this example char type[16]; void operator = ( StrategyUnit& someunit ) { x = someunit.GetX(); y = someunit.GetY(); z = someunit.GetZ(); strcpy( type, "base_unit" ); } void operator = ( Tank& sometank ) { ... you get the idea }};

This works well enough, and we can write the FileUnit to the disk easily. The only real problem is that it might not map well to all units since it has to fit everyone, but it should work well enough if your units are generally pretty similiar.

Anyway, that''s just the tip of the iceburg, but I''ve already written too much anyway . It all depends on what your needs for your game are. Hopefully that will give a bit of inspiration.

##### Share on other sites
Thanks, not what I was looking for, but that''s my fault for
not specifying. I meant memory not disk space and when I speak
of units I mean units that are up on the screen, the ones where
you have to keep track of ammunition and health and fuel and
stuff. Also, my second question is important because I''m
working on a game and I''d like to have the largest armies
possible, so far I''ve got each unit taking 10 bytes using
bit fields and 14 if you include the pointer(singly linked
list). I''ve also thought about allocating larger blocks of
memory and just having a pointer to the block. Thanks again
The Senshi.

Create.

##### Share on other sites
I think you''re worrying a little too much about the details. At 14 bytes each even my pathetic machine can store over 3 million of them. It''s not really that big a deal, just allocate when you want one and deallocate when it dies. Only if your profiling shows that this is really slowing down your system should you worry about custom memory management or stuff like that.

##### Share on other sites
Kylotan is right, its not going to be memory that is the problem - it is the rate you can do AI updates and game logic for all the units that is going to slow you down. Having enough memory for 3 million units is all very well, but if your frame rate drops to one frame per fortnight because it takes too long to coordinate AI & collisions for all of them then it is a waste of time worrying about memory.

The best thing to do is to implement it, but dont hard code the pop limit. Then you can do your own experiments to determine how many units your engine can handle.

• ### Forum Statistics

• Total Topics
628658
• Total Posts
2984070

• 10
• 9
• 9
• 10
• 21