The case of “A.IR”
Back in 2008 Sebastian and Tobias, my friends of si-entertainment.org, had the idea to develop computer games that could be controlled with the new Nintendo Wii controller Wiimote. In addition to various acceleration sensors, the Wiimote has an infrared receiver that uses signals from the Wii transmitter bar for orientation in three-dimensional space.
We wanted to turn the principle around: Use the Wii’s well-functioning receiver to control the computer “without a controller”: Only with gestures of our hands. First prototypes consisted of self-soldered infrared LED arrays that illuminate the hands. The light reflected back from the fingers was to be detected by the Wiimote and translated into signals for the PC. It turned out that the infrared LEDs were too weak for reliable operation (However, a nice eye-catcher was the use of a lighter as infrared source – so you could control the cursor with flame).
The flame showed us that a necessary intermediate step had to be the use of an active infrared source – the so-called “A.IR Remote” was born. This consisted of nothing more than a circuit board, a single infrared LED, a battery compartment and a switch.
This remote control was used to operate the stick in our first game A.IR Hockey (a play on words from air for wireless control, air field hockey and the IR for infrared). Since the Wiimote could recognize several infrared sources separately, it was even possible for two people to play against each other on one PC.
Later, a second game, A.IR Connect4, was added: By means of two infrared LEDs (one attached to the thumb and one to the index finger of the player) tokens could be grabbed and thrown into the playing field.
Unfortunately, we never managed to finish the games. They were playable demos, alpha versions at best. Nevertheless, from my point of view, they are nice examples of how software-intensive products are developed in practice: A technology (in this case the Wiimote and the API for the PC) triggers development, iterative development takes place, and – assuming a lot of luck and staying power – a finished product comes out. (Doesn’t read all that different from innovation management classics like Stage Gate, does it?) A product that one must hope will appeal to potential customers: The search for a possible business model begins. Customers – or at least users – have hardly been on our radar so far. Who do we want to address? Who should pay something for it?
si-entertainment.org is non-commercial, so it was not directly a concern for us – nevertheless the question is interesting how to proceed. Sales channels already existed in 2009, although not to the same extent as today. We also had the casual gamer in mind, casual gamers who play with friends and have a good time together. But what makes these gamers tick, what demands they make, that’s something we might have noticed when testers told us “but I can’t do that on my own,” but we didn’t really have it in mind.
Conclusions
Why am I writing this story? Well, I find it interesting that it is only in retrospect that I realize that Requirements Engineering played no role at all for us as engineering students at the time. We wanted to play, try out, test. Nevertheless, we came up with something innovative – gesture control wasn’t very widespread back then – unfortunately we couldn’t (and probably didn’t want to) develop it into a finished product, because that would have been really hard work.
So just do some Requirements Engineering and it would have been better? That would be a great exaggeration. We would have been overwhelmed even in the pre-planning phase. What exactly do we want to develop? For whom? Who has requirements and for what?
Probably the beginning was right. Trying something out, playing around, creative chaos. But at some point we should have gotten our act together and thought about what to do next. We found it (too) difficult to translate the chaos into business, so we didn’t even try. Transferred to requirements engineering and its methods such as classic Quality Function Deployment (QFD), this means: Find room for creative chaos – but don’t forget the strengths of methodical product development. Creative chaos is great, but at some point chaos is no longer enough. Bringing both sides together is the solution from my perspective. No solution, on the other hand, is the “religious war” of whether one side or the other wins in the end.
