Games should be frustrating.

It’s not a word we tend to associate with our favorite games. The word we usually choose is challenging, but they’re similiar enough concepts, except one is considered a good thing and the other not. No matter how motivated, no job seeker is ever looking for a bigger frustration, and no lover regards a perpetually limp dick as a challenge. But the purpose of a game is to put obstacles between you and your goal—to frustrate you from your goal, in other words. If it does this well, it’s a challenging game.

In Fissure, you’re supposed to travel around in a cave and locate salvage. You’re inside a small moon, and we assume that you’re deep enough that gravity isn’t a factor. (This effect is called the Shell theorem.) Effectively, the only force acting on your mass is your own thrusters. I had to think up a control scheme to operate a capsule moving in free space.

Now, games always make tradeoffs between accuracy and ease. Guns don’t jam, greasy food gives you health instead of a raging case of the shits, and no one ever slips on a wet sidewalk. Picking the right degree of realism means striking a balance between challenge and frustration. If you can make a game out of repairing a jammed pistol, you add a level of realism and a new degree of challenge.

With Fissure, I had to strike that balance as well. I wanted to make motion part of the challenge—a game mechanic in its own right. I started out with a completely realistic model, applying Newton’s Laws of Motion.

If you want to rotate a space capsule, you can’t just put a foot down to push. You have to generate thrust at a right angle to the axis of rotation. More thrust, or the same thrust applied for a longer time, means a faster rotation. If you want to stopturning, you have to generate a thrust in the opposite direction, and wait until your angular velocity is zero.

Which it won’t be, I promise. There will always be some fraction of momentum left over, and if you try to correct for it, you’ll overcompensate and go spinning the other way around, and have to correct for that, and so on. I figured this would become annoying in very short order, and discarded that model. However, I still wanted Newton somewhere in the game!

The model I settled on allowed simple (and physically unrealistic) rotation via the arrow keys. Push a key, you turn, release the key, you stop. (You’d have to be blowing a serious amount of reaction mass to get an instantaneous change in velocity. That’s why it’s physically unrealistic.) Okay, I can live with that for the sake of the player. For linear motion, however, I kept Newton around. Push WSA or D to activate a thruster. Hold the key down to keep that thruster firing, and you’ll keep accelerating—until you hit the cave wall. The collision is inelastic: energy is absorbed by the cave wall, and by your shields.

The only thing I didn’t like about this scheme is that it didn’t give me fine control. I wanted the player to ease up to a chunk of salvage and press a button to pull it in for processing. So I made the thrusters start with a small acceleration, then gradually build up to a maximum thrust. At some point, I tossed out the requirement to press a button to process the salvage, because I didn’t see the point of introducing another control button for the task. Just as players in other games can run over health packs or ammo, I let the player crash into salvage to process it.

I practiced with this control scheme until I could fly the capsule blindfolded, then I wrote up the rest of the game and showed it to some people. The reaction?

The capsule was impossible to control. Seriously. No one liked it. I admit, I wasn’t expecting that. Hadn’t I compromised accuracy for fun? Hadn’t I created achallenge?

Not enough of one, apparently. It was still too frustrating. In the next post, I’ll talk about what went wrong and how I’ve tried to fix it.