Recreating the time mechanics of Braid (Part 1)

Project introduction See Part 2 here

The rewind mechanics of Braid are not entirely unique, but they are few and far between. Prince of Persia: sands of time also used a rewind feature. There are also few time manipulation based flash games, though many of those have a less direct rewind time mechanic.

My first reaction would be to simply save off the state of every object every frame, and then play it all back. The major problem with this solution is the extremely large amount of data that it would require. It would be a good proof of concept and would probably work for a few seconds like in Prince of Persia, but it wouldn't be as powerful as Braid.

Next I searched on the internet to see if someone else has tried to recreate it. The major strategy that came up on many web sites was to make a deterministic engine. The idea behind it is that every action has exactly one outcome. With only one outcome, the actions can also be reversed, and I could save the actions and when they occurred. The problem with this solution is the large amount of designing. It would be very difficult to adapt a full game engine such as Unity into a deterministic engine. I would have to use XNA or a similar language/framework in order to make my own engine in a reasonable amount of time.

Another cool idea that showed up was to make a simulation. The reverse would be as simple as playing the simulation in reverse. It is similar to a deterministic engine except a bit more confusing and a bit less functional.

Eventually I was able to find how Jonathan Blow accomplished the task. Like many other junior programmer, I was a bit disappointed. Instead of some fantastic and complex system, it was simply my first hunch. He saved off relevant pieces of the game state. However, he did an extremely large amount of optimization to make the amount of data manageable.

I will focus on two major optimization to begin with and research what else he did later. The first is only save the state if it changes. This allows for objects that hardly move to use hardly any data instead of everything needing tons of data. The second is only save every few frames and interpoate between the two. This is a trick I probably wouldn't have caught but it is a genious example of the illusion of videogames. It allows the system to save on data by generating during runtime, and most people would not be able to spot the difference.

Now that I have a good direction, I will use Unity at least for prototyping and getting the basic functionality working. I will also add my own little twist and take advantage of the fact that Unity is a 3D engine and make the system in 3D. It will increase the amount of data I need by about 50% due to adding the extra dimension. I can always constrict Unity down to 2D if the data becomes too large.

I don't have much research left to do, so future posts will be all about implementation and polish. This will be a five part series with the fifth being the post mortem.