Jump to content
  • Advertisement
Sign in to follow this  
geo2004

RTS saved map format?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I've been thinking lately, what are some of the popular ways to save map and unit information in RTS games, like C&C, Warcraft 3, etc.? I'm working on a very simple rts, and considered XML. I could store each tile, its properties, each unit and its properties, etc. However this seems like it would be inefficient to parse when reading and saving, and could get insanely large when considering all the game objects. Anyone know of a few of the common ways to do this in order to save all the map information, including tiles, unit locations, any thing relevant to the AI, teams, resources, etc? Thanks, Jeff

Share this post


Link to post
Share on other sites
Advertisement
In my previous game project, a TBS game, the maps were randomly generated. I only had to store the seed used to generate them, a bit of information about each player (their levels and resource) and the location and information for each ship's location.

Consider also: If your game uses prebuilt maps, just save the name of the map, and then save the units and their locations. You don't need to resave the entire map file, in every save. Ofcourse, if the map changes, the saves become invalid, and you need to be aware of that, and have some way to indentify if the maps changed. If your maps are randomly generated, just save the seed used to generate them.

If you do that, you could use XML if you wanted to. I've never used XML, but you could do something like this:
<MAP_TYPE="random_map">
<MAP_SEED="12345">

Or:
<MAP_TYPE="prebuilt">
<MAP_FILE="myMap.map">

Then follow that with XML data for each player, and then more data for each unit. Since you are cutting out saving the entire map in each save file, the saves really won't be too large, unless each player has 500+ units.

Share this post


Link to post
Share on other sites
You'll probably want to be serializing the appropriate objects (assuming you're programming this in an OO language), and it'll make your life much easier if you're using a decent serialization system - one which keeps track of which objects have been serialized, and redirects pointers to those objects when they occur in other objects.

Ideally your base entity class will declare a virtual function called something like:


virtual void Serialize(ArchiveData &data, bool loading);



Then each of your derived classes will implement this appropriately, for example:


void Unit::Serialize(ArchiveData &data, bool loading)
{
BaseEntity::Serialize(data);

int version = 1;
if (loading)
{
data >> iVersion;
if (version == 1)
{
data >> m_health;
}
}
else
{
// Saving
data << version; // Write out the version number for this object
data << m_health;
}
}



ArchiveData should be some kind of stream object, whose << and >> operators are overloaded to read/write data to the stream.

Whenever your serialization format changes for that object, you increment version, and change the loading code to match the new structure.

When saving (or loading), you can simply call Serialize on whichever root object contains your game data, and any objects it points to will hierarchically get serialized out/in, too.

Note that this is just one way of doing it - the one that I'm familiar with. There might be other (better) ways of approaching the problem.

Hope that helps! :)

Share this post


Link to post
Share on other sites
Thanks for the replies so far guys/gals!
Mattdev: I did a little research on Serializing, and it looks like that might be the way to go. This part of my project is still a little ways down the road, but I want to start brain storming ideas now and doing research.

Anyone know if this is the common way to save games?

Thanks!
Jeff

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!