Bound Against Time Update: Developing Across The Space-Time Continuum

This week, we explore the trials and tribulations of building a game that needs to run forwards and backwards through time. We caught up with developer and skateboarding enthusiast Jeremy Burns to ask him how he tackled the issue while developing the puzzle-platformer Bound Against Time.

Bound Against Time, as its name might suggest, is a game about time. Players must use the mysterious rifts that have sprung up across the world to travel back in time, restoring order to the timeline. One of the central mechanics of the game is the manipulation of objects and parts of the environment in “forward-time” (i.e. the natural flow of time) and then having those movements and manipulations replicated rigidly in “reverse-time”.

Initially, developing an engine that worked in reverse-time didn’t seem particularly challenging. Developer Jeremy Burns started by recording the position of objects at each frame in forward-time and placing those objects at the appropriate locus in reverse-time. It worked fantastically well — until he introduced physics to the world. Physics added a layer of confusion to the basic record-and-replay functionality. Something as simple as a crate falling would look lovely and solid until Jeremy attempted to replay it in reverse-time, at which point it would start behaving very strangely.

After a bit of digging, he realized he wasn’t recording enough data; positional data was not enough. Looking at the example of the crate falling, the crate operates according to the laws of physics when moving in forward-time. It has velocity, indicating its direction and speed of travel. Moving into reverse-time, the physics would lock out to allow the crate to follow the path it had traced in forward-time. But then, if the player entered forward-time again, the physics would kickstart up once more, this time using the velocity that the crate had just had in reverse-time to launch the crate into the air. To fix this issue, Jeremy started recording the velocity of the initial movement of the crate in forward-time. This allowed the crate to resume its natural path when going from reverse-time to forward-time, by calling up that original velocity rather than relying on the movement from the reverse-time.

It wasn’t as easy as simply adding this additional layer of recording however. Each new puzzle element introduced in the game needed to be evaluated for its optimal data recording. Each puzzle reacted differently when exposed to the transition between reverse-time and forward-time. Rope puzzles required a different set of data than crate puzzles which in turn required a different data set than destructible object puzzles.

Now, all this sounds like it could be rather cumbersome on the engine (and your computer). However, Bound Against Time runs at a tick rate of 30 frame per second (fps), extrapolating positional data between the frames to create a smooth 60 fps on most modern computers. This means the game logic only runs every other frame, significantly reducing the need for memory. In fact, hundreds of objects can move on the screen for up to a minute without any noticeable performance issues.

To further streamline the game’s system requirements, Jeremy also developed a series of non-physics based objects and environmental obstacles that follow fixed paths in both forward-time and reverse-time. The floating leaves at the beginning of the Forest area use this fixed-track technique to create the appearance of travelling back through time.

Have you experimented with developing engines with tricky physics-based problems? How did you tackle your developmental woes? Let us know your thoughts in the comments below and be sure to subscribe to our MADSOFT Games newsletter for more Bound Against Time news, interviews, and behind-the-scenes development updates!