lexys-labyrinth icon indicating copy to clipboard operation
lexys-labyrinth copied to clipboard

Let undo go back further

Open eevee opened this issue 1 year ago • 0 comments
trafficstars

Part of the reason undo is relatively limited is that the size of an undo frame depends a lot on the level, and also is hard to measure in a useful sense. For CC2LP1's 185 Bigger Boulder Alley, watching the replay caused Chrome to chug a few times (GC, I would think), and it turned out the undo history was like 15MB with hundreds of entries per frame, including numerous pink balls constantly being created and then destroyed. If I ran it at 2× or faster, the tab crashed.

On phones that's gonna be, uh, even more of a problem.

Some ideas:

  • Destroying objects creates relatively big undo entries (the whole tile), which is not great for the common pattern of a cloner aimed into water. I'm tempted to say "object pooling"? Does object pooling intersect with undo in a reasonable way? The last thing I want is issues with ghost tiles getting confused about whether they exist or not.

  • Currently I create an undo entry every tic, but this isn't strictly necessary, especially for steam-strict which runs at 60tps. I could easily batch them to player-initiated movements and/or a few times per second.

  • I could also go back and consolidate older undo entries later on, so you can still rewind further, it just becomes somewhat coarser. It might be a good idea to stop using closures for undo, in that case, in the hopes that I can consolidate those together somehow.

  • I could also just straight up roughly estimate the size of the undo entries (just number of tiles affected, that kinda thing) and limit by that instead of by amount of time. Then gigantic levels would just not be able to undo as far.

eevee avatar Apr 12 '24 05:04 eevee