Best way to implement Undo function?

[TimeLoop]

I read some articles about how implement undo functions in games.

I got a game that could be classified like a kind of roguelike in what the player is able to move in four directions with the keyboard and interact with objects changing their coordinates only.

When the player wants to undo, the character moves to the previous coordinates, and if any object has been changed its possition, make the object to return to the previous possition.

What is the best way to implement this undo functionality?

Thanks.

P.S. I'm not using objects.

EDIT:
----------
Remember the player may move a lot of times and the objects may be changed their possitions a lot of times too.

[Robin]

There are basically two ways of implementing undo:

Snapshots (or: Git)
You keep track of a list of the complete state (so: where is the player, what is their health, what weapons and potions do they have? Where are all the things that can move? Etc.) This is useful for when the state is small, a lot of things change each undo-step, or you want to go back in larger jumps rather than necessarily visit each step.

Deltas (or: Mercurial)
For each undo-step, you keep track of the things that change. This is useful when there is a large state (lots of things and variables), but little of it changes per undo-step, and when you always want to do one undo at a time.

Both are roughly the same difficulty to implement, depending on the way you keep track of state.

Which of these two should you use? It depends.

[TimeLoop]

There are basically two ways of implementing undo:

Snapshots (or: Git)
You keep track of a list of the complete state (so: where is the player, what is their health, what weapons and potions do they have? Where are all the things that can move? Etc.) This is useful for when the state is small, a lot of things change each undo-step, or you want to go back in larger jumps rather than necessarily visit each step.

Deltas (or: Mercurial)
For each undo-step, you keep track of the things that change. This is useful when there is a large state (lots of things and variables), but little of it changes per undo-step, and when you always want to do one undo at a time.

Both are roughly the same difficulty to implement, depending on the way you keep track of state.

Which of these two should you use? It depends.

Which one would be better for a Checkers game, where there are several pieces but they only change their (X,Y) coords, which is in fact the only property that they have.
There are no other things to have into account such as ammo, health or etc. Only coordinates of the player toon and the pieces that will be moved.
Only one piece can be moved per action, so it is not possible to move several pieces at the same time.
Also it is like a turn-based game where all game logic happens after the key is pressed, and nothing happens while keys are not pressed. In a similar way than a roguelike, checkers, chess, shogi or whatever.

Thanks.

[Robin]

In a checkers game, it doesn't really matter much, you can go with both approaches. I'd suggest storing deltas, because you only have to store 2 or 4 numbers for each turn that way (depending on whether it is single player or multi player).

[TimeLoop]

In a checkers game, it doesn't really matter much, you can go with both approaches. I'd suggest storing deltas, because you only have to store 2 or 4 numbers for each turn that way (depending on whether it is single player or multi player).

Yes, deltas seems the best way.
Actually it is singleplayer game without any movemement or decission made by some AI.

Thanks.

[TimeLoop]

Using this same topic to ask one more thing:

In a chess or checkers game, ¿should the player have unlimited undo operations or only allow to undo the last move?

I'm not sure if unlimited undo in a game like that will break the game. Just need oppinions. Thanks.

[Plu]

Depends on the kind of game whether unlimited undo breaks anything. If your game is really single-player and small like that, I would just implement a table of turn-states, and make undo nothing more than

Code: Select all

Turn = Turn - 1

to load data from the previous turn back into the game.

If your game is about discovering gamestate through interaction (ie; a black room with limited vision that you have to navigate around) then unlimited undo is going to make the game really easy; you just leap around to map out the level and then complete it in one go. On the other hand, if the whole level is visible from the start and the goal is to solve a puzzle, then unlimited undo will probably make the experience more pleasant because you can roll back poor solutions without having to start all over.

[substitute541]

Using this same topic to ask one more thing:

In a chess or checkers game, ¿should the player have unlimited undo operations or only allow to undo the last move?

I'm not sure if unlimited undo in a game like that will break the game. Just need opinions. Thanks.

It can break the game if you go way too far backwards. Like, if you store an array of pieces moved, and go beyond the boundaries of the array, it will certainly break.

Then again, why would you want unlimited undos in a chess/checkers game?

[T-Bone]

Using this same topic to ask one more thing:

In a chess or checkers game, ¿should the player have unlimited undo operations or only allow to undo the last move?

I'm not sure if unlimited undo in a game like that will break the game. Just need opinions. Thanks.

It can break the game if you go way too far backwards. Like, if you store an array of pieces moved, and go beyond the boundaries of the array, it will certainly break.

Then again, why would you want unlimited undos in a chess/checkers game?

Most chess software I've used allows unlimited undos. It can be very useful for educational reasons, like testing various strategies. It probably doesn't make much sense in a competitive multiplayer scenario, but that's far from the only way to use a chess game.

[Lafolie]

The SRPG game "Tactics Ogre: Let us Cling Together" features a fascinating undo mechanic. The player is allowed 50 turns worth of history, and it also keep branches where you have previously gone back to a previous turn. I very rarely wanted to redo more than 50 turns, so it practically gave you unlimited do-overs. As a long time SRPG player, I was first skeptical about the idea, but soon warmed to it. It's useful for experimenting, mis-clicks and just checking what happened in previous turns (which does come in handy now and then). It's also completely optional: if you want to tough it out or consider it cheating, just don't utilise it.