Iteration - If at first you don't succeed...

One of the stronger ideas to come out of out conceptualization was an idea for an on-rails platformer. The core of this idea was to take the timing challenges found in platformer games, and intensify them by removing direct movement control, allowing for very dense, rewarding levels. Of course, just having an on-rails platformer isn't really enough, as that's a genre that's been heavily explored over the past few years thanks to games like Temple Run and Canabalt. So we also decided to play with the concept of layers.

Our first prototype took a physical approach to the idea of layers. We set up three parallel lanes, each one with its own set of obstacles. The player could switch between these lanes at will, as well as jump to avoid obstacles. You can see an image of it below.

This prototype had more than a few issues. On a basic level, the player's jump physics were incredibly floaty, allowing the player to traverse great distance with a single jump. In general, this felt wrong on a visceral level. Although it's not the most complex problem, it's still worth noting; for a physical mechanic like this, it is imperative that things feel proper.

A more pressing issue was the placement of the parallel rails relative to the camera. At the angle shown above, it's fairly easy to see what's going on at each of the side rails. You know what obstacles are there, and what are coming up, and it fills the screen, giving the action an intimate presence.

The problem is in what you can't see, not what you can. I noticed during testing this first iteration that sometimes, when shifting lanes just after passing an obstacle in the lane you shifted to you would still collide with said obstacle. It was completely out of your field of view at this time, making these failures feel unearned and out of place. What you can't see in the picture above are two translucent 'ghost spheres' that follow the player's progress along the other two rails. At any given time, if the player switches rails their position immediately becomes the position of the appropriate 'ghost'.

It's therefore quite problematic that these markers aren't seen. The problem lies in the camera placement; although being tight on the current rail makes the action intimate, it also cuts off the sides enough that you can't actually see where you're going whenever you change rails. By zooming out, it became possible to see all three rails properly, but at the expense of that valuable intimate view; with a larger field of view, your control over the character felt a little more abstract, and your ability to determine the position of obstacles relative to the player was lessened.

In order to solve this problem, we ultimately decided to shrink the scale of the rails. Since bringing the camera out wasn't an ideal solution, it seemed like bringing the rails in was the next best thing. Instead of jumping to the lanes to the left or right, the player would simply shift position within the center rail. This captured the same gameplay feeling, but allowed the player to actually see their destination before moving. The place-marker spheres were removed during this build, but they were fully visible before, a large improvement. However, this wasn't perfect, since this smaller focus took away from the conceptual draw of the layer idea. Now, you were essentially just sidestepping, and the prototype was a standard rail platformer.
Still, it was a vast improvement over the initial version.

We simultaneously created another version of this prototype, one which took the concept of layers in a different direction. Instead of having the various rails distinct, we decided to place them on top of one another, allowing the player to change their actual environment rather than their position within it.

At the press of a key, players could toggle which color blocks were opaque and which ones were translucent. Although this prototype was conceptually neat, it had many of the same problems as the first. Although only having one rail avoided the problem of not being able to fully see where you were shifting to, the translucent rails were hard to fully place in space, making it very hard to know where obstacles were. Even as the person who actually built the level, I find it difficult to successfully navigate. Although the phase-shifting was cool, it didn't come across all that well in this first iteration.

For our second iteration, we decided to shift the camera view to the side, and present the whole concept as 2.5D. It did wonders for conveyance; obstacles could no longer hide from the camera, and it was abundantly clear what the player was supposed to do in order to progress. The switch was also useful from a general learning standpoint; although the player moved at the exact same speed as in the first prototype, it felt significantly faster. Without being able to see things coming up, the reaction time required to clear each challenge was lowered, making the game as a whole harder.

Although both these iterations were real improvements, they both shared one key weakness. Next time, we'll get into that weakness, and look at what it takes to make a useful prototype.