Please include an "Undo" move button in your games.

[cigma]

Undo is not a box you check to just make it happen. On many games, it's the most complicated part of development and testing. Furthermore, once implemented, undo is is very bug prone and players still request more savepoints and functionality. As such, it's often avoided by game developers.

Adding turn confirmation buttons is a grsat way to prevent misclicks and is easy to do.

Hello Kayvon,
I'd be interested to know about the technical difference between "Undo" and "Confirm". I'd imagine that both use a similar kind of temporary memory, which is set back in case, but this is obviously not true after your description. Can you please help us understand?

[Tisaac]

Undo is not a box you check to just make it happen. On many games, it's the most complicated part of development and testing. Furthermore, once implemented, undo is is very bug prone and players still request more savepoints and functionality. As such, it's often avoided by game developers.

Adding turn confirmation buttons is a grsat way to prevent misclicks and is easy to do.

Hello Kayvon,
I'd be interested to know about the technical difference between "Undo" and "Confirm". I'd imagine that both use a similar kind of temporary memory, which is set back in case, but this is obviously not true after your description. Can you please help us understand?

I think Kayvon speaks about "small confirmation", IE confirmation for a "single action". What i mean is that in ArkNova for instance, the confirm turn step is indeed exactly the same as a whole undo. But if you stay with arknova, choosing to place a worker on the association board, then choosing the conservation project to support, then thé bonus from the Map, then the animal to release, is all done only on client side, which means nothing is sent to server and nothing was stored. In other word if you refresh, you go back to the "choose where to place your worker" state, and that's easy to do with a "cancel" button instead of refreshing. In the same vein, if you play a card game, you would usually ask for confirmation about the card you want to play, which is easy to do, but once the card is played and a bunch of effects triggered, letting playing undo back to card selection is not as easy AT all.

[Kayvon]

I'd be interested to know about the technical difference between "Undo" and "Confirm". I'd imagine that both use a similar kind of temporary memory, which is set back in case, but this is obviously not true after your description.

You have a keen eye for detail. They are indeed quite different. May I explain by way of analogy? When you're playing a game in person, you probably plan out your turn in your head before taking it. You can completely change your mind about the move and no one's the wiser. Once you actually move pieces, you've "confirmed" your move. At that point, you probably need to ask the other players if you want to take back your move and do something different instead.

Likewise, when you take actions in your web browser, it doesn't send your move to the server until you hit the confirm button. Other players can't see what you have planned until you do so. (If you've ever refreshed your browser at this point, you'll notice that the move wasn't saved and you have to redo it.) Once it's sent to the server, pieces have moved and undo'ing it requires figuring out how to revert the state. For some games, that's fairly simple, especially when playing in person. For others, it's definitely not.

I suppose you can call your browser (or your head when playing in person) a "temporary memory". Once pieces have moved, there's nothing temporary about it. Reverting the state requires the game to keep track of where everything just came from and when such a thing is allowed. You probably shouldn't be able to undo after rolling dice. If you undo after playing a card and that causes the discard pile to be shuffled, now you need to unshuffle it back to how it was, especially if that order was important to the game.

I think I've rambled beyond the scope of your question, but I hope that's helpful.

[MathCT]

You said it all Kayvon

[cigma]

...

I think I've rambled beyond the scope of your question, but I hope that's helpful.

Thank you both for your detailed answers! They were quite helpful.

So this is my understanding: Sending data to the server kind of settles them and makes them difficult to be reset (Undo). When you use Confirm, you first collect the action data of the turn (or a part of it, in cases like rolling dice or drawing cards), then send them to the server. If the player instead Cancel their turn, the collected action data are erased. That's clear to me.

And how is this done without Confirm? Do you immediately send each action data to the server? Then I suppose adding Confirm after original programming isn't that trivial either?

I want me and other players understand the difference between Undo and Cancel, so we don't bother you programers any longer with request for Undo

[Kayvon]

how is this done without Confirm? Do you immediately send each action data to the server? Then I suppose adding Confirm after original programming isn't that trivial either?

Right. Without confirm, data is sent to the server as soon as you click/tap on an option. You can see this in older implementations and in simple games.

Adding a confirm button is relatively easy, even late into development. Worst case, deciding not to confirm (to cancel) can just reload your browser. Undoing it after everything is processed is not trivial.

[cigma]

...

Thanks again for your kind and detailed answer, Kayvon. Now we all have an explanation we can refer to when it is needed

[MathCT]

The most complicated thing is sometimes finding a good balance. Confirmations are relatively simple to implement but can break the fluidity of the game... Undos can cause bugs and cannot be implemented everywhere... We try, when we develop games, to find this good balance... but there will always be players who want more or less.... We try to adapt as much as possible.