Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 1, 2014
arrowPress Releases
November 1, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Game Design Deep Dive: Movement in Road Not Taken Exclusive
Game Design Deep Dive: Movement in  Road Not Taken
September 3, 2014 | By Daniel Cook

September 3, 2014 | By Daniel Cook
More: Console/PC, Indie, Art, Design, Production, Exclusive, Deep Dive

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?”


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.


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.


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:

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Multiplayer Level Designer - Treyarch
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States



TC Weidner
profile image
nice write up, I enjoyed it, very creative solutions you guys/gals came up with.

"After all this we now have solid movement animation in our grid based game that no one really notices." I also think people will indeed notice and enjoy even if they are not totally conscious of why they are enjoying it. Little touches like this is what adds life to games and make them "special" IMHO.

Barn Cleave
profile image
I've been working on the cardinal grid-based movement for Chuck's Challenge now for nearly 4 years. We are about to launch an update on Steam in the next few days and it includes yet another refinement in the controls, along with lots of other stuff we’ve been working on for months (The update is available already to test as an Alpha through Steam, as we give access to both an Alpha and Live version of Chuck’s Challenge 3D).

What we’ve found is people expect the character to stop when they let go of a direction aka analogue controls. However as it’s grid based the character is always going to move fully to the next square aka it’s digital. Some players get it straight away. Others think the game is being laggy, because it didn’t respond to the key release, but after a while they get it.

Shay Pierce
profile image
Thanks a lot for sharing this detailed design analysis! It's great to hear people sharing the real problems they end up solving when theory meets practice.

For the "tappers" problem, why not force the current animation to finish in just one more frame?

By which I mean:
- Whenever directional input is first received, start animating the character moving in that direction over 300 ms.
- If a second directional input is received before the prior animation completes, force the animation/movement to render for just one more intermediate frame; in the frame after that, the character has finished the animation; the frame after that, the new movement begins.

So the player presses RIGHT. The 300ms animation starts. Then, 200ms later, the following happens:
- Frame 1: The player presses UP.
- Frame 2: The character was animating to the right, and was 2/3 of the way through the animation. For this frame, it renders the 5/6 point of the animation (halfway between where it was in Frame 1 and the end of the animation).
- Frame 3: Animation is completed; the character is in the center of its new cell.
- Frame 4: The character is now animating in the "north" direction (which will also take 300ms, unless similarly interrupted).

This means a perceptual delay of 3 frames between pressing in a direction and the character starting to move in that direction, which is pretty responsive. The intermediate frame (in "Frame 2") is of course a concession to make the "teleport ahead" move less instantaneous and jarring.

This would probably be a safe system to add the "queueing" system to... seems like it can't hurt, though it would only be necessary for players that were tapping in inputs faster than 1/3 the framerate.

Of course, this might not actually feel good! It might feel strange for your character to suddenly "jump right" when you hit "up", and then start moving "up" at a leisurely pace again. Just an educated guess on what might feel responsive and not look too strange.

Dan Ogles
profile image
This was a great post, and I hope Gamasutra features more content like this in the future.

From a process standpoint, I'm curious how you interface with the engineer(s) when iterating on something like this. A lot of game "feel" comes down to fiddly tweaking of both code and data, and in my experience is difficult to do in collaboration.

My first stab at this problem would be to queue commands, and always be moving X% from the current position toward the position at the end of the queue every frame. Movement would automatically speed up as commands are queued, and have a nice ease as they reach the desired position. I haven't thought how this might trip up the Holders/Analogs though. :)

Olivier Besson
profile image
Thank you for this interesting article, unveiling an usually neglected aspect of game design.

Some other approaches come to my mind, but it deosn't mean they could be relevant to your game:

* keyboard's "key repeat" common in any OS is another classic (and know to most users who practice Word or Excel ;-)) way to handle the "tappers vs holders" issue.
It requires 2 parameters:
- initial delay before continuous repeat
- repeat period

* Another interesting approach would be to separate the hero from the actual target grid cell ("cursor"). This cursor could be move instantly according to "excel controls" (see above), but hero moves towards the cursor with a speed depending on the cursor distance.

Barn Cleave
profile image
Yes that’s the technic we use in Chuck's Challenge 3D. Woop the main purple character moves to the highlighted square aka the Disco Dance Floor, which is controlled by the player.

R. Hunter Gough
profile image
I was also going to suggest your second approach, but I realized it would fight with the game's turn-based nature; the other characters move at the same per-tile rate as the hero. So if the cursor is diagonal from the hero's current position, it will take the hero two "turns" to get there, and during the first move something else might move into the target tile and block the hero, so a nice smooth diagonal movement wouldn't work. It would also fight with the fact that the hero's coverage shape changes depending on what you're carrying.

An Advance-Wars-style path-drawing system would be better, but it would still fight with other characters moving into the path.

Olivier Besson
profile image
Oh you're right. Actually I meant that the hero would'nt move directly towards the cursor (not diagonal, then), but would rather follow exactly the path of the cursor, as in Advance Wars indeed.
If the speed varies according to the distance (expressed in tiles), for sure other actors would have to synchronize with the pacing and move at the same speed.
I've no idea if it actually "works" ;-)