use "snapshot" stuff for a higher level undo buffer

Got a cool idea that should be in R'n'D? Let's hear it!

Moderators: Flumminator, Zomis

Post Reply
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

use "snapshot" stuff for a higher level undo buffer

Post by filbo »

Hi,

Copied over from where I started spewing this idea in the <<"Fast as possible" not working>> thread...

Speaking of snapshots, I'm reminded of a frequent frustration. Suppose I'm playing a level, in my usual fashion of play-until-die, playback at high speed (display off: '51' or more likely '5155') until near-death, try again from where I was; etc. And then by mistake, after a certain death, I hit a key (like "space"!) that means "start playing from the beginning".

Poof, all gone!

Even in this new world where the memory contents which just went "poof!" might have included thousands of snapshots of the previous run.

Any way, when starting a completely blank new run, to keep around at least one copy of the previous run? + UI to say "whoa, let's go back to that saved-other-run snapshot"? I'm not looking for a long chain of undo's, a fancy UI retaining recent heroic efforts, or anything like that. Just a single "undo" for "whoops, didn't really mean to wipe everything just now".

The precipitating event is sometimes (but rather rarely) "whoops, I hit <Enter> on the wrong menu line (Levelset)" or "whoops, I clicked on Levelset by mistake". So it would be a small bit better if the proposed undo buffer were retained even when falling out of the level, as long as another level wasn't initialized; or even if one was initialized, but not played / playback'd. I expect each incremental request here makes the whole thing another moderate amount more difficult to implement... :)

OTOH, I can think of an implementation which would be immune to pretty much all such user errors while costing only a little bit of memory: an LRU cache, indexed by [levelset,level], of most-recent-run on the last N levels. Where N could be, say, 5 (and maybe user-tunable). So if I fell out of the level (whoops hit <ForwardArrow> while on the "Levelset" menu line); or fell out of the levelset; or whatever -- and re-entered the levelset and level -- it'd be recoverable. In this implementation, each [levelset,level] would have either 0 or 1 entry in the cache; and the corresponding "undo" action would be effective only on a level with an entry in the cache. The user doesn't need to know which entry it is, it's inherently indexed by what level he's looking at.

No expectation that this should last across executions of the game binary. (Except, well, to "feel" the same in an Android environment it would probably have to do exactly that!)

The one other thing that feels a bit tricky is: how do you keep this level's "undo" entry from being instantly destroyed by the new run I mistakenly started? i.e. back at the top of this, where I mistakenly hit <Space> when I meant to hit '5', now I've started a new run, shouldn't that be the current undo buffer? I guess a good heuristic for this would be: not eligible to be stashed as "undo" until 10s of game play. Where perhaps "10" is another user tunable (both probably only in setup.conf). Playback should never be considered "play" for this purpose -- though playback followed by hitting the "Record" button would be (and, I think, not subject to the 10s eligibility rule).
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: use "snapshot" stuff for a higher level undo buffer

Post by filbo »

Hmmm. Given this scheme, the "undo" could simply be "re-enter this level". Currently, when you enter a level, the game is either initialized to completely blank (if you've never saved a tape); or to the saved tape.

So hmm. This idea isn't quite right then. Wouldn't want to make it so you couldn't easily get to the formally saved tape, merely because you had played this level within the last N levels. No, definitely no. Entering any level should continue as now -- initialize with the saved tape. Maybe <Ctrl>R (for "recover" / "recent"/ "retrieve") to retrieve the recently recorded run for this level? Which would be <Cmd>R on Mac, and -- some sort of visual widgety thing or menu entry on Android & iOS, I guess...
Post Reply