Usability has been a goal of interface and interaction engineering since the beginnings of human factors research. Games have, for the most part, carried on this banner of ease-of-use via tutorials, in-game instructions, well-labeled interface elements, and standardized controllers. With this project, we contend that usability and fun are (or at least can be) orthogonal.
For prior art, see Tarn Adam’s Dwarf Fortress and Nude Maker’s Steel Battalion. Both present expert interfaces to complex simulations: in the former, the player oversees a community from seven up to a hundred dwarves, deciding on zoning law, public policy, military strategy, and cultural achievement; and in the latter, a player uses three joysticks, three foot pedals, and a bushel of switches, knobs, and buttons (including “Fire Extinguisher” and “Windshield Wiper”) to try and navigate a walking robot (or “Vertical Tank”) through various combat missions. Mastery over these complex interfaces is a significant part of the enjoyment of these games just as mastery over one’s own body is a significant part of the design of any physical sport.
Unfortunately, Steel Battalion’s controller has nothing in the way of haptic feedback: it is a pure input device. Therefore, we wanted to investigate an input/output mechanism that we feel is not just reactive, but reactionary; a controller whose goals are different from the player’s. Initially, this design took the shape of an autonomous lifeform like a steam-powered horse, but in combining the reactionary UI concept with Ryan’s previous work in gesture-based controls, we found a way to further increase the noise and chaos in our system: a second player.
In our current design, two players cooperate to control a flying vessel. One player (the pilot) sits at a laptop wearing two special gloves. The left glove selects the type of weapon to be used, and the right glove fires that weapon. The right glove is also used to move and dodge enemy shots. Bright LEDs on the back and the palm of the glove can be observed by the laptop’s camera, and the ship tries to move towards the corresponding point on the screen. The ship will continue to move towards the last seen point if the light becomes invisible.
The pilot isn’t in this alone. In fact, she is dependent in nearly every way on the second player: the engineer. The engineer manages the power output levels for the pilot’s weapons, restoring power after shots are fired; he also monitors and controls the color mix and positions of the ship’s shields which must match incoming shots in order to block them. If the pilot wishes to fire the ship’s ultimate weapon, he also needs the engineer’s cooperation to arm and then discharge this mighty attack.
The engineer cannot see what’s on the pilot’s screen, and the pilot cannot see a weapon’s status before deciding to fire that weapon. If the shield mix is incorrect, incoming shots will penetrate and damage the ship. If the charge level of a weapon is low, it will fire only feebly. Worst of all, incoming shots disrupt the shield mix and fired weapons lose power, requiring the engineer to recharge them. It is vitally important therefore that the pilot communicate to the engineer about incoming threats and that the engineer make it clear to the pilot what attacks are available.
We hope that this game forces players to reevaluate their relationship with their games, their controllers, and each other. Specifically, we hope that the conception of a “game” moves away from a piece of media plugged into a player and towards a sense of social contract in a space arbitrated by rules. The design of this game, its controllers, its installation context, and its social context are tightly coupled, and by using these bespoke interfaces games can provide much more nuanced and special input. Games should let players aspire to be good at them, and reward practice with increased subtlety and grace.