Controls

Controls are hard to get right. Here is a rather lengthy description of how I developed the scheme for RUBICON:

First, I needed to explicitly see what you DO when playing this kind of game wrote out two overarching objectives:

• shoot enemies.

• don’t get shot.

The first is accomplished by interacting with those enemies via bullets that come from some yourself at some angle. The second is accomplished by moving out of danger areas. Challenges arise when these two conflict; you need to simultaneously be in a position that does not contain bullets while trying to fill their position with bullets.

Geometry Wars is about as pure as you can get in this respect. You move and shoot independently, and control both very precisely. Scrolling shooters (eg Zero Wing) are similar, but without the whole “aiming” thing. “Bullet hell” games are the logical extreme of this, where the game is almost purely a function of keeping your ship in the approved areas of the screen while holding down a button.

Asteroids is a bit more complex, where the shooting/movement angles are tied together, and objects in motion tend to stay in motion. I like this because it really forces you to balance keeping yourself safe and shooting at the enemy; you can either be steering OR aiming. Having inertia makes it so you need to constantly monitor and occasionally modify your trajectory instead of shooting things.

I tried mixing these sorts of controls and physics to see what felt the best. This, as best as I can remember, was the sequence of events:

RUBICON started out having steering semi-independent of aiming; there was a firing arc in front of the ship controlled with the mouse, but the ship was turned with the keyboard.

PROBLEM: people lost track of either the mouse (where they were aiming) or the direction their ship was pointing. To shoot at something, they needed to both turn the ship AND click where they wanted.

I tried fixing that by just making the ship always face forward and turn the rest of the world (see video). It made my testers stop losing track of which direction the ship was pointing, but still forced them to do two separate things to aim anything. Also, slight nausea was reported.

So I just tied ship turning to the mouse’s position. The ship would rotate at whatever turnspeed I’d defined for that type of ship towards the mouse.

PROBLEM: the point of having a firing arc was to be able to shoot in one direction and move in another. With both just tied to the mouse’s position, it was totally superfluous and just make controlling the ship harder. Compounding this was the fact that physics were still in “rocket” mode, where all ships were constantly thrusting in the direction they were pointing it. My testers couldn’t even avoid asteroids.

Giving the ships an auto-aiming feature, where they just shot at the predicted position of the nearest enemy your ship was pointing at, totally gutted gameplay. You just pointed your ship at them and shot. Everything was terrible.

So I went back to the basics, and just copied asteroids. Inertia, only thrusting when you hold down a button, and can only shoot straight forward. I was still tied to the idea of specific turn speeds for each ship- more “maneuverable” ships being able to turn faster- but soon found that having a slower turn speed actually made shooting easier, because you could get finer control of where you were aiming when your target was far away. This works fine for Asteroids because the playing field is so small; the difference in firing angle isn’t as noticeable when the radius is so short.

I eventually killed turn speed and just had the ship always face the mouse. This setup is great for supporting the core gameplay (shooting enemies and not getting shot) because you can seamlessly switch between the two while still having to make compromises. Having inertia forces you to plan ahead and spend a certain amount of time and attention to modifying your movement. Aiming at the mouse allows you to have a fine degree of control over exactly where you’re shooting. Both of these are is HUGE for having a seamless interface. The player doesn’t have to think about HOW to do something, and can respond to challenges (be it an incoming asteroid or lining up your shots) instantly to try and resolve the situation.

There you have it. Controls and gameplay are inexplicably entwined. A game provides both challenges and a way to react to and overcome those challenges. Making it so the situation presented on the screen can be effortlessly modified (according to whatever set of rules/physics of the game in question) is an absolutely essential job of the game developer.

I once played a modified game of Pac-Man that was set up for an example of drunk driving; all it did was put a four-second delay between a button press and response of the game. It was the MOST FRUSTRATING thing. You saw what needed to happen and it wasn’t happening. It’s the same thing as waiting for a webpage to load, or why people backseat-drive. Good video game don’t force you to fill out paperwork and wait for 5-7 business days before denying your application.