Here’s an interesting question. Suppose two teams started with the same carefully thought out moderate design for an educational game, and went their own ways with it. The starting point would be a reasonably concrete and carefully thought out plan, but then creativity and serendipity would be allowed to make their influences on each project. How similar would the two projects end up?
We have done just this with two independent companies each coding independent math games based on the same design. The design clearly describes the game, but not in precise detail. For example, although ideas for the graphical content are explained in prose, the actual artwork was left to be realized. Gameplay was done in the same way. General functionality was described well enough to convey basic ideas, but technical detail was left to the realization. Two parallel projects were then undertaken by professional software engineers, each of which with decades of experience building production software. Prime Escape, Randy Schenks’s Android game has just been released on Google Play. Nuhubit Software Studios LLC’s game, Bubbly Primes, for iPhone, iPad, and iPod touch is just a little bit behind.
The two math games are similar but different, in interesting ways. They both accomplish their educational goal (the player becomes adept at factoring, recognizing prime numbers, and so forth). Gameplay is similar on a high level. However, the pace, the look and feel, and strategic play on deeper levels is extremely different. The artwork is definitely different.
I wonder to what degree people might feel they are different versions of the same game or perhaps different related games. Having played beta versions of both, I’m not sure what I would say myself. Although, I’m not exactly sure whether I would consider them to be different games or different versions of the same game, I do think that what is different makes sense, and really, is what I would have expected. At their core, the games are pretty similar, and yet, beyond that, they ended up very different.
Organizing ideas into a design is hard. Implementing computer software based on a moderate design is hard. Shepherding a software project to completion is hard. Our approach acknowledges difficulty at every step. Instead of attempting to front load the difficulty of the project by putting together a foolproof design ahead of time, conceptual work is spread out more evenly over the project, requiring experience, judgement and hard work from beginning to end, from the top-down and from the bottom-up. And occasionally, it permits an invigorating glance past the threshold of chaos.
As our first educational math game, Bubbly Primes, approaches completion, I’ve been reflecting on some of the philosophical aspects of software development. Although I’m writing about some technical aspects of the software creation process, I have the goal of this being interesting to non-programmers.
The threshold of chaos provides a wellspring of art, source of beauty and inspiration, and catalyst of revelation. Artists in many fields grow familiar with this.
Software development is rarely thought of as art outside of a few non-mainstream subgenres like musical compositional algorithms, and experimental games. In most software fields we simply don’t spend much time thinking about artistic issues, despite shocking parallels between the disciplines. And significantly – we usually try to keep our software safely away from the threshold of chaos.
One of the most powerful tools for keeping this distance is formal design, which occupies a lot of energy in the software world, and raises a lot of the same issues that are of eternal concern to artistic work. There is a fortuitous pun here on the word formal. “Formal Software Design” connotes weighty official documents in massive notebooks, beginning with a page of legal-looking approval signatures, like formal dress at a ceremonial event. However, formal also refers to a description of structure, as when composers or musicologists discuss the form of a musical composition.
To me, good formal design really means carefully thought-through creative thinking and planning. We need it for the same reason it’s difficult to do. There’s a joy in implementing ideas as they come along. They build onto each other, and can create wonderful inventions that would have been hard to conceive ahead of time. However, even the simplest of software can quickly grow out of control, like a cute little baby pet alligator in a tiny apartment. Software design attempts to predict and organize complexity in ways that avoid the unwieldy tangles that spell trouble.
There’s plenty of common wisdom (and folklore) on the topic. The Joel on Software blog has a series of excellent blog posts advocating the value of up-front software design, as well as smart, practical advice on how to do it. But beware: medium and large projects are continuously tempted with overweight designs which attempt to pin down all the details, which they can’t, subsequently leading to a wide variety of flavors of failure. It’s a cliché that such software, when successfully completed, is frustrating for the user because its goal became “meeting spec” instead of becoming a useful tool for accomplishing user goals.
One excellent approach, like with so many things in the world, is moderation. Insufficient advance design can wend its through the gates of chaos, and continue deep into the kingdom. Too much advance design wastes time, chokes creativity and suppresses serendipity. Finding a balance? Well: somehow moderation can be easier to talk about than to achieve. A thoughtful analysis of this topic was written by Tynan Sylvester in his fantastic book Designing Games. Actually, Tynan proposes a much more sophisticated solution than moderation, advocating an adaptive approach. There’s some great thinking there, but it is not necessarily a generally applicable solution, and in fact probably wouldn’t have made sense for Bubbly Primes. We used the simpler solution of an appropriately moderate design that not only provided the right level of structure, but allowed a fascinating experiment to take place.
I’ll write about that experiment next time.
To Be Continued …