top of page

Undo/Redo System for Phasebreak

Where it started

Working on a turn-based strategy game, I knew how important an undo feature will be. Allowing the players to try out lines of play and then rewind to test out other ones felt like a massive quality of life improvement to our game.

Being the lead programmer of the project, at first I was not the one working on this system, instead one of the very talented developers we had in our team implemented the first iteration of this feature. But after finishing with the Proof of concept, they had to continue to work on other features so I stepped in for the rework of the feature.

header.jpg
Undo3Done2.gif

One of the biggest issues I faced during my work on this feature was, what happens when an action causes an actor to spawn, which in my case was when one of the playable characters spawns a bomb as her unique ability. The problem being that the system needs at the start of the turn to gather the current state of all actors in the combat scene, and as this actor does not exist during that point the system will bot be aware of it's existence.

After some deliberation with myself I came up with a solution, creating a new structure that will wrap around the normal struct that holds the difference information. This new structure will add 2 pieces of information, where and in what orientation was the actor spawned and of what class. This way when the undo system sees this type of structure during an undo/redo it knows to apply special logic (either delete the actor in case of an undo or spawn an instance of the actor in case of a redo). 

Introducing a new challenger!

Where it stands

I put most of my focus on 2 areas, the first being what data is being saved and in what form, secondly I focused on how simple is it to add new logic into this system.

For my first concern after trying multiple options of implementation I landed on having the system handle non-specific typed data (variant data) and it will only save the data points that were changed during the action and not the entire state of an actor. This makes the system decoupled from the data it holds and allows for the actors themselves to decide what data members get saved and how.

Being a tools programmer at heart, my second concern was always scratching at the back of my mind. For my first iteration of this feature I had each actor test if any of it's data points where different then a given state. This became very messy when it came time to implement undo logic in actors, as it would involve very big hard coded switch cases and branch checks. 

 

Seeing that the logic of checking for the differences was the same, I moved it to the system itself, clearing up the implementation and making it very simple to add to any new actor.

Untitled-2026-07-05-2116.png
bottom of page