BGA Undo policy

Introducing "Undo" features in games can lead to bugs and/or bad interface design.

Please read the following carefully before implementing an Undo feature for your game.

What you must NEVER do

When you are restoring a game situation A from a game situation B:

• The Undo action must never change the active player. In other words, if player X clicks on "Undo", it must NOT make player Y active.
• If several players did game actions between A and B, you must NEVER provide an undo. In other words, an "Undo" action must NEVER force another player to redo some moves.
• No hidden (or private) information must have been revealed between A and B.
• No random event with a visible effect must have been triggered between A and B. This includes cards shuffling, dice roll, elements picking, ...

When to propose to Undo?

As a rule of thumb, on BGA we advise you to not undo moves.

Undo are painful for opponents, in real world and online. Some players may also use Undo to "test" situations while they should just think instead.

In many cases, proposing an "Undo" means also adding an extra step, which is not good for the game interface.

Undo may be useful in 2 main situations:

• To allow players to take back a move following a "misclick" that may ruins their game.
• To allow players to take back a very complex series of actions.

About Undo to avoid "misclick"

I most cases, you don't need this: players must pay attention :)

However, if several of the following cases correspond to your situation, you may consider adding an Undo for "misclicks":

• If the zone to click is very small, or close to other zones, misclicks may happened frequently. Note that if this only happens on mobile, you can propose the Undo to mobile users only.
• If there is already another step after the step you want to undo. In this case, adding an "Undo" does not add an extra step.
• If you are in the middle of a real "game action". For example, on Chess, it is normal to allow to undo the selection of a piece in order to select another one, as the move hasn't been done already.
• The action done by the player is obviously a mistake (in this case, please also consider adding a confirmation before the action).

On the contrary, you must be reluctant to add an Undo if:

• This adds an extra step.
• The game action is clear and the zone to click is large.

To conclude: we may allow a player to undo a move caused by a "misclick", but we shouldn't allow a player to undo a bad move he plays consciously.

About Undo to take back moves from a complex series of actions

Games with a complex serie of actions are an "exception" to BGA Undo policy.

In most games, you shouldn't provide an undo because players are not allowed to "explore" the different possibilities by playing and undoing their moves.

However, in some games, this is commonly admitted that players are allowed to take back a move. The typical example is a complex strategy game with a long serie of actions during your turn. "Through the Ages" or "Tzolk'in" are 2 good examples.

To know if this is a good idea to propose an undo, ask yourself the question: "when playing in real life, will my opponents authorize me to take back this move?". Depending on your answer, you should propose an Undo, do not propose an Undo, or maybe propose an Undo as an option for the game.

How to implement Undo

There is 2 ways to implement Undo:

• The framework undoSavePoint/undoRestorepoint methods.
• Your own method.

As a rule of thumb, this is way better to us your own method to provide an Undo. The reasons are:

• The framework method is quite heavy to use (it saves the WHOLE situation). To cancel a simple move, it is way more efficient for you to execute the opposite move.
• The framework method is doing a full "reset" of the game interface. It is way more beautiful to play the opposite move from a player point of view.
• The framework Undo provides only ONE save point. If you want to provide a complex Undo (ie: the possibility to undo all the previous steps one by one), you must implement it by yourself.

However, the framework is very handy to use (only 2 methods), so this should be your first choice if some moves are very difficult to reverse on client side.

How undoSavePoint/undoRestorepoint works?

The undoSavePoint method makes a full copy of the game database state.

The undoRestorePoint method:

• restore the game database
• remove all your game HTML + the player's panel
• restore the game HTML + the player's panel according to their state at browser's page loading page
• call your "setup" method

Important: because undoRestorePoint is calling your "setup" method, you must ensure that your whole game state can be restored from there. In particular, all your member variables must be initialized inside the "setup" method (and not only in the constructor !).