Saving game/state

Monkey Forums/Monkey Beginners/Saving game/state

TVCruelty

(Posted 2014) [#1]

Hi,

I'm writing a reasonably complex strategy game in Monkey X and I've started to feel slightly anxious about saving games. As far as I can see, the only option is to use SaveState, which requires me to create a csv of every (required) variable, including every element of every array and every field from every current object.

This feels very clunky, time-consuming and error-prone, so I wanted to ask if anyone knew of a better way to do it. I've thought of locating the variable stack and saving/loading that but I guess that would be very target-specific (hence the SaveState solution in MX).

I've also had a bit of look at Diddy, which I believe offers more in the way of file management, but my game's quite a long way down the road now and used mojo.

Any advice gratefully received.

Thanks

MikeHart

(Posted 2014) [#2]

For HTML5 you are bound to use SaveState. For basically all the other OS, you can use normal file operations. I would try to use a binary format, so your save files don't get bigger than needed.

Gerry Quinn

(Posted 2014) [#3]

The easiest approach is to have a serialise function for every object (you can skip the lowest level objects if you want). The typical pattern is like:

Class MyClass

	Field x:Int
	Field y:Int
	Field sc:MySubclass

	Method Serialise( loading:Bool )
		If loading
			x = SerialiseInt()
			y = SerialiseInt()
			sc.Serialise( loading )
		Else
			Serialise( x )
			Serialise( y )
			sc.Serialise( loading )
		End
	End
	
End

You can tweak the details to add error checking etc.

With this you'll need some basic functions for serialising ints and strings, and then a function for each object that gets called at the right time by the object that owns it, so that the entire game state ends up getting saved or loaded.

For example, if MySubclass has a bunch of fields, they will be saved/loaded in the MySubclass.Serialise() function, and MyClass doesn't need to know about them.

You can create the functions as you go, so that serialisation will be working from early in development (though you will need to have version numbers, start with a fresh game, or do some minor trickery every time you add new fields).

With very low level 'POD' objects, you might serialise them directly in the owning object as is done with primitives, rather than add a proper Serialise function.

TVCruelty

(Posted 2014) [#4]

Excellent - thanks for the replies. I like the idea of each class having a Serialise method: I can definitely see that working.