See Part 1 here
I am a current student at Tribeca Flashpoint Academy. The school offers courses on game development. My first year was about all areas of game development. For the second year I am studying programming almost exclusively. Even though I am focusing on programming, my studies are still a bit diverse, covering a variety of subjects including rendering, AI, and gameplay. Another class includes a major project of reverse engineering a current piece of technology. Reverse engineering is a good exercise to see if I can reproduce what the industry is doing and help advance my programming knowledge. Another huge benefit is adding it to my portfolio to impress employers.
The technology I will be reverse engineering is the reverse time mechanic from the game Braid. I chose this option because it is very interesting as well as challenging. The mechanic allows for the player to rewind and playback gameplay at various speeds. It is not the first game to feature the mechanic though. Prince of Persia: sands of time also has a rewind feature, but no playback. It is also limited to ten seconds. Braid was released five years later and allows for nearly unlimited rewind and playback.
Before I went to the web, I pondered how I might design the system. I quickly discovered that the answer would be maddeningly more complex and difficult than the problem suggests. Rewinding a game is many time more difficult than rewinding a movie. My main idea was to solve it the brute force way, by saving the relevant state of every object. With the minimum amount of data for each object in a 2d game being its x and y position, and needing to save that every frame, the amount of resources needed to rewind time nearly indefinitely like Braid does would be enormous. Rewinding and playing back would be cheaper than when the objects were initially generated, especially if they use physics.
My initial research confirmed that my plan was one of the few way people have figured out how to do time controls like in Braid. Searching a little more I found another way that could be much easier on resources. It involves making a deterministic engine, where every action has exactly one outcome, and each action can be undone by an opposite action. This seems like a much better solution, but also a much more complicated to design one. Using this strategy raises the question of what language and/or engine to use.
Unity is a fairly good and basic engine that I may be able to use, but I may not have enough control to make a deterministic engine. If I have to use the brute force strategy the engine may not be optimized enough to handle it. It would be very easy to make the brute force in this engine though.
The XNA framework is a good option because I will have a lot of great features while having enough control to make a deterministic engine. However, it would require me to write an engine as well as the mechanic. It also has the benefit of being used by Braid.
C++ with DirectX would be the ideal option because I would have ultimate control over the engine. The drawback is also much bigger due to making an engine would be more difficult.
I will do some more research about the theory behind this mechanic, and I will choose what to program it in later. I will most likely do some small scale prototyping to see how well the various engines and frameworks can handle the brute force method. Ultimately I will probably use the deterministic solution due to it being the more technologically impressive one.