Question

I'm fairly new to c# and am getting into XNA a bit.

So far all is fairly simple and I can find info on it, but one thing that I've been struggling with is finding good tips/tutorials on how to create game save functionality.

I don't really want to use XML for saving neither the configuratio, nor the game since it just makes the value changing too easy. So, I decided to go for binary files, since it adds a layer of complexity.

Sadly I wasnt able to find much information on how to do that. I saw some posts suggesting users to create a structure, then saving it as a binary file.

This seems fairly simple (I can see that being done with the controls, for example, since there aren't that many variables), but I can't seem to find info on how to convert the actual

public struct controls{
   public int forward;
   public int back;
}

structure ... well, to a binary file really.

Another question is saving game data.

Should I go for the same approach and create a structure that will hold variables like player health, position etc. and just load it up when I want to load the game?

I guess what I want to ask is - is it possible to "freeze" the game state (amount of enemies around, items dropped etc.) and load it up later?

Any tips, pushes and nods towards the right direction will be much appreciated.

Thank you very much!

Was it helpful?

Solution

Well, simple answer is yes you can store game state. But this is mainly depends on the actual game implementation. You have to implement one/several data classes which will store the data vital for game state recreation. I think you can't just easily dump your game memory to restore the state. You have to recreate the game scene using the values you saved earlier. So you can use these simple methods to convert virtually any class marked by Serializable attribute to byte array:

public static byte[] ToBytes(object data)
    {
        using (var ms = new MemoryStream())
        {
            // create a binary formatter:
            var bnfmt = new BinaryFormatter();
            // serialize the data to the memory-steam;
            bnfmt.Serialize(ms, data);
            // return a byte[] representation of the binary data:
            return ms.GetBuffer();
        }
    }

    public static T FromBytes<T>(byte[] input)
    {
        using (var ms = new MemoryStream(input))
        {
            var bnfmt = new BinaryFormatter();
            // serialize the data to the memory-steam;
            var value = bnfmt.Deserialize(ms);
            return (T)value;
        }
    }

Also you must know the rules of binary serialization. Which types can be serialized out-of-the-box and which needs some workaround for serialization.

Then you can optionaly apply an encryption/decryption to that byte sequence and save/load it using System.IO.File.

        //read
        var data = File.ReadAllBytes("test.dat");
        //write
        using (var file = File.OpenWrite("test.dat"))
        {
            file.Write(data, 0, data.Length);
        }

OTHER TIPS

In this situation, there's no a real "correct" answer. If you just want to "encrypt" data, why just don't create an xml in memory, and then apply you preferred criptographic function to protect it before saving?

Surely, this is not a catch-all rule: saving game data in binary format result in less space occupied on disk, and maybe faster load tines: a very long number, such as 123456789, can be stored using only 4 bytes. If you want to save it in xml, there's so much overhead due to xml tags, and conversion from string to int.

A good approach for your project is to create an helper library with serializers/deserializers. Every struct will have its own, and when called on a specific structure the function will convert structure fields into their binary representation, concatenate them as strings and erite them to file. This explains why every structure needs its own deserializer: it's up to you to chose the order of fields, binary encoding, etc

Finally, the above problem can be solved in a more elegant way using an OOP approach, maybe with every "storable" class implementing a serializable interface, and implementing ad hoc serializazions methods.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top