Best solution for "level string"?

Question

I have a game that generates a random level map at the start of the level. I want to implement some way to save and load the level.

I was thinking maybe XML would be a good option for saving all the variable, then it would be easy for me to build something that can parse that XML and generate the exact same level.

But XML is probably overkill for my needs. I remember back in the day with the old Sega console that didn't have the ability to save your game (I think the Worms game did it too), that they would give you a bunch of character that you could write down. If you punched in that string later on, it would load the exact level.

Would a "level string" be a good option? Would it be some kind of "base60" conversion? How would I implement this?

Answer 1

Presumably all you need to save is the random seed, which is generally just an int. You could encode the int to base64 if you wanted to make it a bit more opaque, but thats probably not needed.

Answer 2

Whatever format you use for your save games, for goodness sake put a version number in. You'll be able to have backwards-compatiable loads by branching on the version number, or you'll be able to safely recognise saves that are too old to load.

You'll regret it if you don't.

Answer 3

JSON is good, but YAML is better. :) http://www.yaml.org/ and http://code.google.com/p/yaml-cpp/ for one of the nicer-to-use implementations.

YAML is a superset of JSON that adds support for a few nice features, most notably:

• Binary nodes. This is great for serializing the kind of data you might be dealing with for level descriptions. JSON requires you to translate to some intermediate format of your choice, like Base64, before writing / after parsing. YAML has a !!binary node type which tells the parser library to do it for you.
• Intra-document references. If the same object appears twice in the document, JSON will write it twice, and when you read it back in, you'll get two copies. Many YAML emitters can detect this situation and instead of a second copy, output a reference to the first, when can be detected when loading.
• Custom node types. You can flag each map in a list with e.g. !!Player, !!Enemy, etc., and so keep your type information more out-of-band.
• YAML supports more readable formatting.
• Since JSON is a subset of YAML, most YAML readers will have no trouble reading JSON documents.

Answer 4

If you want to serialize all the data in game, I would recommend JSON as your file format, it is why easier to use the XML and the support is very good across many languages.

I have used this library for C++ and it works very well.

http://jsoncpp.sourceforge.net/

Answer 5

XML is a good choice if you're not limited by size and it is supported natively (eg in .NET and Flash) but if you want a slim format you can create your own format and parser quite easy. I normally use 1 character eg. comma to seperate each object. To decode the string do a split on comma. Now each object needs different properties so seperate these with a different character eg semi colon, and use another character to seperate the property names from property vales, eg. Colon. All thus can be decoded easily without regex just by using string.split. Here is an example:

id:1;x:5;y:45.2;angle:45,id:28;x:56;y:89;angle:12;health:78

you can save even more space by keeping property names down to 1 character, eg h for health. Eg.

i:1;x:5;y:45.2;a:45,i:28;x:56;y:89;a:12;h:78

Compare to JSON alternative:

{"o":[{"i":1, "x":5, "y":45.2, "a":45}, {"i":28, "x":56, "y":89, "a":12, "h":78}]}

Also, if you want to get the size of your numbers down, you can encode them using the full set of printable UTF16 characters. This thread inspired me to ask a question over on Stack Overflow of how much data you could pack into one on-screen character. The answer seem to be somewhere over 40,000 values for an integer, if you don't mind having brail, Kanji and chess pieces: ♔♕♖♗♘♙♚♛♜♝♞♟

To get a further size reduction, you can use read/write order to determine which value is which, so the first two characters represent the id, the next two are the x position, the next two the y, then the angle, then health, etc. So:

F5DGP@%&002DFTK#OP1F

could store all the same information as the other examples.

Tile grids can be stored as just a string with each character representing a different type of tile eg:

i789pog5h3kl

where I might mean lava, 9 mean grass etc

Answer 6

If you are coding in .Net then XML is super easy to go with, as you can serialize/deserialize your level class into/out of XML with just a couple lines, and then its all in a nicely managed class.

TheMap would be a variable of type Map that you have all of your data loaded into.

Dim TheMap As New Map

Assuming you have a Map class already built, this would save your map into XML:

Dim Serializer As New System.Xml.Serialization.XmlSerializer(GetType(TheMap))
Dim Strm As New FileStream("c:\Map.xml", FileMode.Create, FileAccess.Write, FileShare.None)
Serializer.Serialize(Strm, TheMap)
Strm.Close()

This would then load that XML back into your map class, to be used again in code.

Dim Reader As New StreamReader("map.xml")
Dim Serializer As New System.Xml.Serialization.XmlSerializer(GetType(TheMap))

TheMap = Serializer.Deserialize(Reader)
Reader.Close()

From this point on your XML file is now loaded into your class for easy use.

As for your "Level String" issue, what was stated before would work great, you could just use the Seed number as the "Level String".

Otherwise, you could just pre-generate however many different maps you wanted, and have them all saved with a "Level String" and then use that to pull up the proper map.

Answer 7

I'd use a simple struct or similar device (depending on your language) to store all game state in a central place. If you want the protection of setters/getters, you can wrap the struct in a class.

If you feel up to it, make use of bitfields or simply do bit manipulation yourself using bitwise operators.

Be aware that in some languages, the rules for struct padding and packing may be a bit complicated -- but it may also not matter much for your case if you have a byte or two of padding.

You may also be able to use a #pragma (such as #pragma pack(1)) or an __attribute__ to closely pack the struct, eliminating padding. This may or may not work depending on your compiler and target architecture.

Note that use of bitfields and pack pragmas or attributes can reduce portability. Across hardware architectures, the struct field endianness (byte order) may also change. So you may want to avoid this if you're trying for portability.

(For e.g. Pac-Man, this struct might naively contain a map id or map seed, a Pac-Man x and y position, four ghost x and y positions, and a large bitfield for the presence or absence of 32-64 pellets, whatever the maximum is.)

Once you have your struct, pass it to something like an xxencode function:

encode_save( char * outStringBuf, size_t outStringBufSize,
             const SaveStruct * inSaveData, size_t inSaveDataSize )

Writing this function is a bit error-prone; you need to shift and combine bytes as necessary to get e.g. 6 bits at a time, then translate into an appropriate character. I'd personally try to hunt down someone else's code, unless I was doing this for "fun" (and I'd probably want a test suite for it).

Never underestimate the power of the old-school struct in the right places. We've used it a ton for GBA and DS games here.

Answer 8

XML is good for arbitrarily structured documents(elements can appear in different levels of the tree) or foreign format embedding(like putting svg in an xhtml page). If you don't have those requirements it's a really inefficient format, and something more simple like csv or json is preferable.