[Alephmodular-devel] Random brainstorming on restoring defaults changed for specific levels

[Br'fin <br...@ma...>]

This was originally posted to the AlephOne mailing list. But I want  
to note it and consider it here in case I ever manage to do something  
more with AM.


I just had a relevant thought. It doesn't exactly apply to the  
current problem, but seems useful to contemplate.

After all the problems of default data, per-level physics data,  
starting MML, per level MML, Lua and all. I took a moment to think of  
how I might want to approach this for AM if I ever get around to it.

What if the state of the game setup by MML/physics was stack based?  
You have a cluster of values that makes up the current settings, and  
when entering a new level you Push the state. The new state is an  
exact copy of the previous state and until a value is explicitly  
changed, you look it up in the previous stack frame. When the level  
is over, we Pop the physics/MML state back to where it was before.

Such a repository might also be much more handy for saving/loading in  
a saved game wad. The only draw back is existing Minf levels that  
somehow rely on custom physics from the previous level bleeding  
through... though I would think that was just poor scenario design.

I have no clue when such a thing would be implemented in AM. API-wise  
it might look something like AM's preference mechanism. (That system  
is modeled after preference API in Java and MacOS X, you ask for an  
object representing the appropriate preference domain, and then have  
a hash of values to keys that's strongly reminiscent of a MacOS X CF  
Dictionary.)

Alternative conception of implementation:
You have an API to write to every value that can be set/changed. A  
pushed stack frame is empty, except for it's list of dirty values  
(When you Push, the saved frame has a list of all dirty values, and  
the current frame has a clear list of such). But each time you change  
a previously unchanged value, you mark that value as dirty and note  
the original value in the dictionary for the previous stack frame.
The previous stack frame becomes a list of diffs to restore itself.
This way is messier/more error prone, but could allow for faster/less  
abstracted data reads. Though it might be slower when setting/loading  
data. It might be easier to streamline the 'lookup previous data if  
unchanged' methods of the first implementation.

-Jeremy Parsons
http://alephmodular.sourceforge.net/