Game Design Deep Dive: Movement in Road Not Taken

Game Design Deep Dive is an ongoing series from Gamasutra, with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all. Also read about ammo collection in Wolfenstein: The New Order and Amnesia's "insanity meter."

Who: Daniel Cook, Designer and Co-Founder at Spry Fox

Some of the past games I’ve worked on include Triple Town, Steambirds, Tyrian and Realm of the Mad God. For Road Not Taken, I was the main designer and spent most of my time buried in config files. In general, any non-technical, non-art flaws (including all the goat jokes) are all my fault. Spry Fox is an odd duck of a company because we try to make mechanically inventive games in all sorts of different genres. With that goal in mind, we focus on robust prototyping over pure content production. Small distributed teams, new platforms, new business models and bottoms-up development are common.

What: Movement in Road Not Taken

Movement in Road Not Taken uses one of the oldest movement techniques in computer games: you can move on a grid in cardinal directions (north, south, east, and west.) Press left and move one square to the left. Players can control the game with either a keyboard or a gamepad. However, we also decided to make the character animate while moving to give that small additional element of polish. We thought when we made this small decision, “Surely moving on a fixed grid with an animated walk cycle is a solved problem?” Research First we did a bit of research and were surprised that there were almost no games that did this well. Most games, such as NetHack, simply move the character instantaneously from one cell to the next. A rare solution we did uncover seemed to be a simple fixed movement speed. Players would press the button and the character would animate smoothly from one cell to the next over roughly 300ms. So we built a prototype with this functionality and put it in front of players for testing.

Why?

There was some discussion at this point on whether or not we should invest in something as trivial as movement. In general, we operate on the principle that the highest-frequency interactions should get the most polish. Movement, though not the sort of thing that makes either a good pitch or good PR, is one of the highest-frequency interactions in the game. If the thing you do during 99 percent of your playthrough feels bad, we are building on a rotten foundation. Playtesting Three distinct playstyles emerged during playtesting: Tappers, Holders and Analog Stick players. First were the ‘Tappers’. These players never held down keys and instead would tap out the directions on their cursor keys. To move in a diagonal, they’d tap up twice and to the left once. To make matters interesting, expert Tappers would hit keys quickly. They became extremely frustrated by the fixed 300 ms ‘delay’ in which the animation played. The game was ‘unplayable’. Next were the ‘Holders’. These would hold down keys and then change direction by continuing to hold down a key until key repeat turned on. Then they’d hit a new key to change direction. While changing directions, they often would be holding down two keys simultaneously. Occasionally they’d be holding down 3 keys. Next were the folks using analog sticks on controllers. These players madly flopped the joystick around and hoped the character went in the right direction. Think of them as inexact versions of the Holders. Directional pads worked much better, since they were roughly equivalent to cursor keys and had usage patterns similar to Holders.

The results

Solution for Tappers Tappers were the main problem, because they felt the game was unplayable. We tried several experiments: First was simply speeding up the timestep. This removed much of the animation and made the game feel less polished. We knew that instantaneous movement was acceptable, but wanted to avoid it if possible. This option became was our fallback in case all other experiments failed. Next we tried queuing commands. Players would tap in their commands and then the game would execute them. This also seemed slow and the player didn’t feel like they were completely in control. We tried various configurations of queue length and timesteps, but none worked. Finally, we attempted a more radical solution. Different players had different expectations of how the system would work, so what if the system adapted to the player behavior? Lead developer Cristian Soulos created a variable timestep for the entire animation system of the game. Now we could play a turn’s worth of animations slowly, or we could play it quickly. Then we measured the timing between button presses. The first button press would cause the character to move using the default timestep. If they pressed a second time with a time less than the default, we’d make that timestep value the new default. If the gap ever ended up being more than the default, we’d reset animation back to the default speed. This allowed Tappers to quickly hammer in a destination. For the fast movers, we’d speed up the whole game to be in sync with the character movement. There was still a slight amount of lag in that first move as we measured the input stream, but it seemed acceptable. Solution for Holders Our initial implementation worked reasonably well for this group. The main solution was to trigger a change in direction on key down and ignore the other keys being held. Combined with the use of variable timesteps, this generally works. Solution for Analog Stickers Analog sticks tended to trigger when the player didn’t expect them to, especially when the stick was close to the center. The main solution here was to increase the dead zone. This meant you really needed to push in a direction to go that way. We also shortened the default timestep to increase the feeling of responsiveness.

Unexpected benefits

Something that fell out of this whole system was the ability to also slow down each timestep. There’s a point in the game where you are running out of energy and your character is about to die. We intentionally slow down the timestep here so that each step feels exhausting and laborious. It is a nice little example of using control feel to provoke an emotional response. I certainly wasn’t expecting to discover a strong sense of game feel in a turn-based, grid-based rogue-like. But that’s the joy of bottoms up prototyping. We watch the players react to our functional prototypes and listen for opportunities. Then we amplify them.

Future challenges

Ultimately the schedule only allowed so much time invested into movement prototypes, so I’m still not 100 percent satisfied. Expert Holders will still express a rare desire for a ‘run key.’ And when you tap out commands quickly, the very slight lag and variable speed doesn’t quite feel as rock-solid as might be desired. If there were more time, I’d instrument real player patterns and graph the results visually to see if there are any obvious moments of awkwardness we could polish out. This, however, is more my own quest for perfection than anything that damages the release. Sometimes you need to know when to stop. Movement was never going to be a delighter, so the most important goal was that issues found in playtests seem fixed. After all this we now have solid movement animation in our grid based game that no one really notices. Perfect. If anything, this whole exercise was a reminder that seemingly solved ‘trivial’ topics in game design can be far more complex than they appear on the surface. Are you a developer interested in contributing to Gamasutra's Game Design Deep Dive series? Email editor-in-chief Kris Graft: [email protected]