Mandible Games

One of the trickiest issues with designing any novel game is the interface. If you're putting together a first-person shooter or a MMORPG it's easy – you just do what everyone else has done before, unless you really think you have a brilliant new idea. (Chances are good that you don't.) Any game more complicated than that and you're going to need to invent something new.

One of Katamari Damacy's (many) charms was its two-axis control system. While that control scheme wasn't new (Virtual On's twin sticks come to mind, and I'm certain VO didn't create it either) it provided quite a lot of control over your Katamari – not the most precise control, but you never found yourself saying "if only I could move to the left". You didn't fight with the interface. You fought with the Katamari sometimes, but the player ended up saying things like "man, a large katamari is really hard to maneuver", not "this interface is terrible and I think the game designers should be shot."

I've played games where the latter happened. They aren't fun.

For any game with novel mechanics, you're going to have to make certain that the player can pick up on the key assignments quickly. Fighting with your controller isn't fun, even when fighting with the monsters can be. The game industry is littered with games where the interface hurt what could have been a great game (PN03, Red Steel) and where a well-built interface sent a game from "good" into "great" (Abe's Oddysee, Guitar Hero).

Interface design in Devastation Net has been problematical since the very beginning.

First off, D-Net is meant to be played with game controllers. This isn't a problem on an actual game console. A PC, however, is not a game console. When you plug a controller into a conventional game console, the console knows which button is which. Your PS2 has no trouble distinguishing between the "circle", "square", "triangle", and "cross" buttons. On a PC, a game controller shows up as a pile of axes and buttons. A PS2 controller, as far as my computer is concerned, is four axes, twelve buttons, and a hat switch.

There isn't standardization on which button is which. The buttons are in a random order, depending on the manufacturer of the controller or adapter. Even the axes might be mirrored – you can rely on the first two axes, but when you have a dual-stick controller (like all the modern standard controllers) the remaining axes might be in any order.

Partly, I could avoid this problem simply by not using gamepads. I admit I'm taking a more difficult position on this one than necessary, and of course I do support keyboards. But D-net is designed so that you can support a dozen players on a single computer – and for that, you fundamentally need gamepads.

Making those gamepads useful has been a problem in itself.

In most areas, you can find UI experts who will do excellent jobs of designing an interface for you. This is because the principles of UI design are mostly understood by now. We know where to put buttons, we know how to lay out screens so humans can comprehend them.

Games are tougher. The only time a game needs a serious amount of thought on the controls is when the game is trying to do something new. If I was writing a first-person shooter on the PC I would just duplicate Unreal Tournament's controls. There just aren't many top-down tank games, though, and there are even fewer that work with game controllers.

I ended up with a few different control methods. The standard mode was the obvious one – one axis for turning your tank, one for moving forward and backwards. Next I had a more automated mode, where you would move the stick in the direction you wanted your tank to go and the computer would try to figure out how to do so. And finally I had a mode inspired by Katamari Damacy, where you would control each tank tread separately. With each of these modes, each axis could be chosen separately by the player.

The computer-controlled mode quickly proved a dismal failure. The computer would happily drive into walls, and trying to write enough intelligence into it to not do so was difficult at best. On top of that, I didn't want the player's tank to be controlled by a computer. It's a player-vs-player combat game – not a computer-vs-computer combat game.

Katamari Damacy mode was a failure as well. With D-Net style tank combat, you spend a lot of time rotating in place trying to aim, or moving directly forward and backwards when you're aimed properly. Doing this with two treads was simply difficult – it was fun, but it wasn't particularly intuitive.

Standard Mode, as people usually set it up, was surprisingly ineffective as well. Most people would make a single stick do both turning and moving – move the stick left to turn left, move the stick forward to go forward. But those two, again, are things that people want to do separately.

It turns out the best control method (at least, the best we were able to find) is to have "forward/back" on the left stick, and "turn left/right" on the right stick. In fact, it's so much better than the others that everyone quickly started using it.

As a result, that's the one D-Net now suggests. In fact, I've removed all support for the computer-controlled mode and for Katamari Damacy mode. To a large extent, more options is just confusing – adding dubious control methods doesn't make a difficult-to-manage game any easier.

At the beginning of this project, the controls were hardcoded. In the middle I had more options than anyone wants. Now, I've got a control scheme that's simple and very effective.