Actually SaveGame was one of the first rules I had to implement because the simple test project I was using relied on SaveGame to reset the game when you die. And just yesterday I implemented the ability to distinguish between temporary and permanent slots, but I haven't tested it yet. I think it'll work, though.
instance of a layer or a map, it simply resets
the existing layer or map to the state stored in the saved game. This may change somewhat because I just encountered a possible problem when switching maps. There's no way to automatically reset a map to its initial state to simulate the .NET behavior of unloading and re-loading a map if you choose to unload a map when switching to another. So I might be forced to at least make a map and its layers reset-able if not 100% serializable. Sure I could simulate this by internally saving the initial state of a map and its layers for use with the reset feature of SwitchToMap, but that seems like cheating. Then you'd have 2 copies of the initial state of the map in memory -- one in the code and one in the serialized copy.
And the saved games will not be saved in normal files, of course. Temporary saves will still be in memory only, but permanent saves will be in HTML5 "Local Storage" using localStorage.setItem. It's a beautiful thing, and as I was working more on the saved games yesterday I was very pleased with how well it fit right into what HTML5 provided. I'm glad I didn't do this earlier when it could have been much messier.
I know the feeling of "can't contain... excitement"
. What they hey, I might as well post what I've got so far: http://sgdk2.enigmadream.com/ben/BenJ.html