Undoing and again can be confusing

[ClementSparrow]

In this example from the unit tests (source code), with the mechanics of Draknek's Boxes Love Boxing Gloves, if we do DOWN, DOWN, UNDO, RIGHT, RIGHT, UNDO, we get back to the start position. Here is the whole sequence in pictures:

START: DOWN: DOWN: UNDO: RIGHT:

The animation in the last picture (showing the whole sequence from the beginning) ends in the same state than the picture with the black border. Undoing from there brings the player back to the state of the first image.

This may be confusing for the player because:

• The number of UNDO key pressed (2) is clearly less than the number of other key presses (4). We have intuitively that notion that UNDO will cancel the last key press.
• Visually, even if it was because of an UNDO, we arrived in the cell south of the westmost crate from the south. So we can easily forget it was because of an UNDO (that was 3 key presses earlier), and believe UNDO-ing again would lead us in the bottom-left corner rather than back to the starting position.
• It looks like a diagonal move was undone, and there is no such thing as diagonal moves in this game.

The rationale behind this behavior of PuzzleScript is that undoing to the previous frame would simply trigger the again command again, and it would just redo what we just undid. So we need to UNDO back at least to the last frame before all the again commands. But in this example, that would lead us in exactly the same level configuration than before the UNDO, and the player would think that the UNDO did not work, or even that it is disabled in that game/level. So we go back to the last frame that was not triggered by an again command AND that has a different level configuration.

Game devs can alleviate this issue by designing their games such that undoing a move cannot look like performing a move (e.g., by using an avatar sprite facing the last direction of movement: undoing would look like walking backward). If I extend the engine to actually show sprites moving continuously from one cell to another (instead of disappearing from a cell to reappear in the neighbor cell), that could also help. As would playing backward the animations for the creation/destruction of objects (if I implement such animations).

But we can also go further and play backward the various frames triggered by again commands. It could look strange, so that would require some parameters that the game devs can play with:

• duration of the UNDOne frames (typically, shorter than the again_interval),
• maximum number of frames undone (some games rely on long animations ; 0 would disable the feature),
• detecting infinite loops (e.g. alternating between two states) and visually undo only at most N loops,
• extra screen effects during the undoing
• special animation for undoing more than the maximum number of frames (e.g. fade to black before showing the undone state)
• ...

[ClementSparrow]

Feedback received from Rekiron on the Thinky Puzzles discord:

a concern i came across was that my effect slowed down the speed at which you can undo, making it kinda annoying when you need to undo a lot. i tried making it as quick as possible but it was still annoying, so my (bad) solution was that if you hold the undo button, it gets faster and skips the animation
should have just made the effect independent from the speed

My answer: Yes, the time required to play backward the changes is an issue. But I feel it's a more general question about queuing inputs and skipping animation frames when the queue is not empty, which is something that affects 'forward' inputs as well as 'backward' (undo) ones... => This is also a point where PuzzleScript can be improved, but a separate issue (#26).

Rekiron also suggests using shaders or particle systems to create undo visualizations. You can't do that in PuzzleScript, but you can in javascript, so I could add support for it in Pattern:Script, but I don't think it's in the spirit of the engine... What I could do, however, is implement myself a small number of screen effects that people would want to use, and provide them as commands or as event-triggered effects => This is also a separate issue (#27), although if I go into that direction, I need to make sure these effects can be applied to undo events.