Re: [Alephmodular-devel] Saving multiple levels (was: General Status Overview)

[Woody Z. I. <woo...@sb...>]

What about saving sort of a 'diff' for each level?  Err, I mean, each 
object stored in the file would be whole, but only those objects whose 
states differ from the state at load-the-level-from-the-Map-file time 
would be saved.  I mean, wouldn't that let you store the game-state 
exactly, but much more efficiently?  And of course you could always 
store the stuff compressed with some kind of general-purpose lossless 
compressor to save a little more space.

I mean, even if save files still ended up being 5-10MB apiece, I think 
users today would be willing to pay that much disk space.  (Especially 
if things are set up so the user can return to previous levels - in that 
case there's probably less need to keep lots of saved-game files per 
player per scenario.)  It shouldn't take terribly long to save etc. 
since most levels will probably not have changed since the last save and 
their data could just be copied.

Feels like it would be a problem to keep multiple levels in memory at 
once (if the user has changed more than one level but hasn't yet saved), 
but really the levels the user's not currently playing could be held in 
memory in this 'diff' format (prepared when the user leaves the level 
before the next one loads), so the data could not be confused with the 
current level's "live" data.  Then the in-memory diff(s) could just be 
dumped out to file when the player next saves.

Well anyway I guess the point is, this sort of thing is a possibility 
later, but I'm not sure that it requires any special preparation at the 
moment.  (Aside perhaps from being able to mark objects that have 
changed since level-loading, so it's easier to write the 'diff' output.  
That marking could be related to the copy-on-write object stuff... see 
another e-mail not yet sent to the list for that idea.  Heh heh.)  
Naturally modularization should (will) make it easier to swap in 
different saved-game handlers at some point, so sticking in the new code 
to save and load the "all the levels" format should eventually be easier 
than it would be today in A1.

The "approximate saving" scheme Br'fin talked about strikes me as a 
compromise that e.g. a game system might need to make, to fit its saved 
data into a fairly small space for e.g. a cartridge SRAM or a little 
memory card, but currently A1 primarily runs on machines with hard 
disks, which makes conserving space a much lesser concern.  Shrug.

Woody


On Friday, January 3, 2003, at 08:56  AM, Br'fin wrote:

> Well, given that the map file for M2 is 19.5 megabytes, I don't think a 
> PID-style of save all the maps is approachable. Unless your map, 
> externally, is actually handled like the original PID map. (a 2D grid 
> of values+extra lists of information is so much smaller than a full map 
> of lines, points, and polygons)
>
> Something I would like to see develop is the ability to swap out how a 
> save game is done. Notice how many games focus less on 'save 
> everything' and work with 'save my current stats, where I am, and what 
> I have earned'
>
> For something like PID it might be appropriate to save my current 
> level. Then for all other levels note how cleared out a given section 
> is... 'left portion of map 80% clear (10 monsters left), room of death 
> (0% clear, 100 monsters left)' and just randomize the remaining 
> monsters within the cleared section if you revisit that level.