Locomotion Smoke and Mirrors

If we’ve done our jobs right, Wind-up Knight is a fairly simple game.  There are only four inputs, and only two are ever needed simultaneously.  Sir Sprint, our heroic spring-loaded knight, runs forward automatically, removing the need for a classic directional pad or analog stick.  The challenge is derived from careful level design rather than a complex interface, and though the game is not easy, it’s straightforward.

Achieving a control scheme that is simple to understand and simple to operate, even for a straightforward game like Wind-up Knight, is actually a pretty complicated problem.  The term I use for this kind of code is player handling, referring both to the steering of the player’s avatar, and to the manipulation of the player himself.  You see, games that control well often do it by lying to the player, by fudging the simulation, by breaking the rules.

Good player handling code is often smoke and mirrors; the player presses buttons and sees a reasonable result, but in between those two operations a whole lot of code is working to ensure that the result is the best of many potential results.  For example, my friend Greggman discovered that Mario 3’s jumping rules change depending on whether or not a level has slopes in it.  Halo’s targeting reticle famously slows as it passes over an enemy to make it easier to target with an analog stick without using an auto-aim system. When Spider-Man swings, he certainly does not orient about the spot where his web connects to a building (at least, he didn’t in the swinging system I wrote).

Good player handling code doesn’t just translate the player’s inputs into action, it tries to discern the player’s intent.  Once the intended action has been identified, if the rules of the game allow it, good player handling code makes the action happen–even if it means breaking the rules of the simulation a little.  The goal of good handling code isn’t to maintain a “correct” simulation, it’s to provide a fun game.  It sucks to miss a jump by three centimeters.  It sucks to take the full force of a hit from a blow that visually missed.  It sucks to swing into a brick wall at 80 miles per hour instead of continuing down the street.  To the extent that the code can understand the player’s intent, it should act on that intent rather than on the raw input.  Do what I mean, not what I say.

Wind-up Knight appears to be a pretty simple game, but we actually pull a few tricks under the hood to make the game control the way you expect it to (rather than the way it would if left to a pure physics simulation).

Jumping

Sir Sprint does a lot of jumping, mostly from off of solid surfaces.  But he can also jump right after running off a ledge–for a very short amount of time, we’ll allow a press to the jump button to result in a regular jump, even though there’s nothing under his feet.  This is particularly helpful to players on phones that occasionally slow down; they shouldn’t have to die because the frame rate fluctuates right at the point of a jump.

We also allow wall jumping to occur while Sprint is in mid-air.  If you jump at a wall and hit jump again before he lands on the surface, Sprint will automatically flip, snap to the wall, and jump off it again.  This makes the wall jump feel a little more sticky, and it means you have a larger margin of error when timing a wall jump; even if you press the button slightly too early he’ll probably still make it.

Rolling

If you are rolling under a low ceiling and release the roll button, the knight will continue to roll until he reaches an area where he can stand.  In that case, if you hit attack or shield while rolling, the move will be queued up and executed automatically as soon as the knight stands up.  This lets you make moves immediately after exiting the roll state even if you press the button slightly too early.

The low-hanging ceilings, by the way, often extend invisibly on either side so that you don’t automatically stand up into some spikes.

Collision Detection

We have a fairly complicated “hit type” system to allow the rejection of legitimate collisions based on arbitrary game rules.  For example, if an enemy hits the player as the player is in the middle of swinging his sword, we ignore the hit to the player and instead reverse it to kill the enemy.  There are no double K.O.s in Wind-up Knight; when it happens, the player always wins.

We also ignore hits from falling things to Sir Sprint’s body region if his shield is up.  If the shield is up, all falling things are considered impotent.  This way, if Sprint runs into an object that has just fallen in front of him (missing his shield but not his torso), he won’t die.

Camera

The camera in Wind-up Knight is the second most complicated system in the game (the first being Sir Sprint’s locomotion code).  It watches where Sprint is going and tries to prepare itself ahead of time for dramatic changes in motion so that it never snaps or cuts jarringly.

The most interesting case is the way that the camera watches for upcoming walls.  If Sprint hits a wall he turns and runs back the way he came, which requires the camera to do a fairly dramatic sweep in the opposite direction.  To smooth that transition out, the camera searches for walls ahead of Sir Sprint and then moves to align itself to them.  However, not all walls will cause Sprint to change direction; low obstacles, for example, are probably going to get jumped over.

It took me quite a while to find a heuristic that could reliably detect upcoming walls but reject lower platforms.  In the end I went with a system that shoots three rays out from Sir Sprint’s position, and only accepts an upcoming wall if all three intersect the same plane.  You might not even notice that the camera speeds up and slows down in order to deal with dramatic orientation changes, but without that code the game would feel a lot less smooth.

Sometimes heuristics are not enough to get the correct effect, and you have to fudge it even further.  We place secret camera “hint” objects in pits and shafts that Sprint is meant to slide down so that the camera can move to ensure the upcoming floor is always visible even before Sprint begins to fall down the shaft.

Though helping the player complete an action that they intended to complete is almost always the right thing to do, it is possible to go overboard with this kind of system.  Games like Prince of Persia (the next-gen cel-shaded version, not the wonderful original) go so far in assisting the player that it’s almost impossible to actually fail.  If the assistance is so obvious that the player notices it, the game feels suddenly like a false challenge, as if it is on rails.  For Wind-up Knight, we chose a few areas to smooth out to ensure the best play experience, but the rest we left up to the physics simulation and the player’s actual prowess.

It may be smoke and mirrors, but good player handling systems are almost always focused on translating player intent, rather than player action, into game play.  Hopefully the work we put into this area on Wind-up Knight makes it a better game, even if most players never know it’s there.