Temple Run 2 presented the challenge that the original track pieces were baked into single object meshes for optimization, but every track piece took up space in memory and required external editing to change or optimize. I changed this with time and created template environments to use as building blocks for the environment. This became the foundation for the new track system.

To start, I broke the track down into core parts:

• The track surface, where the player runs

• The gutter, or the sides of the track that contain the track surface

• The out-of-bounds, or non-playable area which serves as the surrounding environment

• Obstacles, which sit on the track surface and can harm the player

• Gaps; the absence of track as a hazard.

Each of these parts has a subset of variants, be it in width, height, length, or some other measurement. But, each of them serves a gameplay or visual purpose in every environment.

To create reuse, we created building blocks for these parts which were used to create track segments. Since the segments were now a sum of all of their parts, design could build them how they wanted with a level-design focused approach.

Every game has a limit on the amount of art it has, whether its due to budget, platform, or time. The track system needed to create a believable environment which felt grounded in reality and provided a sense of exploration. My guiding principle on this was that even though the a track segments may inevitably repeat, the player shouldn’t see the same art in back-to-back segments.

To accomplish this, I needed a system that allowed non-destructive layering of assets. This allowed not only for the randomization of appearances, but also for combining two separate track themes into one by creating limited asset palettes.

The track needed to provide challenges for the player. We didn’t always know what these challenges were going to be, so the system needed to be scalable so artists or designers could prototype new track parts without blocking each other.

From the start, we decoupled the final art from the track parts so that design could place parts with greybox representations. This allowed design to work independently of art when building track segments. Final art would automatically populate the track segments at runtime based on a theme.

Gameplay elements were templatized. A Jump obstacle would always be a specific size, no matter how it was themed to appear. By providing these guidelines, it removed the guesswork from the process and created a clear chain of tasks for each new element.

Perhaps the biggest challenge of all was to ensure that the games remained performant and ran smoothly on all sorts of mobile devices. The games targeted extremely low-end Android phones at 30 FPS, while mid and high spec devices maintained a 60 FPS target. Achieving these numbers required architecting systems that wouldn’t cause hitching or frame rate decreases and implementing guidelines and validation tools to ensure the games met their targets.

As part of the development of the system, I set hard limits and expectations for art going into the system to ensure we could reach these goals. I also worked on tools to support low-end performance and decrease loading times.

Exploration is a core tenet of Temple Run games. It should feel like the player is moving through a believable environment. This meant running into temples, along beaches, across platforms in the sky, or jumping on the backs of crocodiles while crossing a river.

Every environment is built off the same core building blocks, but the world around the player should change. Beyond simple randomization or asset placement, each part of the environment needed to be independently styled to give the impression it came from a different biome. For the player, a run might start in the swamp, but it should end somewhere different and provide them with a sense that they have been somewhere.