The Organic Process

In the games I work on, I prefer to keep the development process as organic as possible and I try not to plan anything out beyond what is necessary at that stage in development. This may be the opposite of the approach many development studios prefer, but I find it to be the most effective method for developing the best game possible. Due to the highly unpredictable nature of game design, which I discussed above, a more organic process leaves me room and time to experiment with how the gameplay will work. Instead of writing a mammoth document, I can first try to get some portion of the game to be fun before I start adding detail and length to the game. Of course, keeping the process organic needs to be balanced with concerns about budget, schedule, and keeping a large team of developers occupied. Indeed, having too many developers too soon on a project can be a real problem, as they will have to move forward on creating content before you are sure what that content should be. Adding too much content to the game too early can be very wasteful , if not actually restrictive . This excessive detail can take the form of an elaborate design document, a script for the game s dialog, detailed maps of the various areas players will explore, or even fully built levels for the game. It makes no sense whatsoever to create these elements of the game until you have a firm grasp on what the gameplay will be, and have a working prototype that proves the gameplay to be fun.

Too Much Too Soon

The problem with creating scripts, documents, or levels without a prototype is that these assets will make assumptions about how the gameplay will function, assumptions that may turn out to be incorrect once the gameplay is actually functional. If a designer builds an elaborate game design on principles that turn out to be flawed, the entire game design will probably need to be reworked or, more likely, thrown away. But if people have devoted large amounts of time to creating these flawed assets, they are going to be understandably reluctant to throw them away. If a designer gets too attached to those ideas, even if they later prove to be unworkable, she may try to cling to them. This is an understandable natural human tendency. After all, a lot of work went into planning the game in advance via a long design document ” how can it all just be thrown away? Cannot the assets be reworked to be usable? If you are not bold enough to throw away your inappropriate content, in the end you run the risk of producing a game that is patched together after the fact instead of built from the start with a clear sense of direction.

When I set about working on my first published game, Odyssey: The Legend of Nemesis -, admittedly I had little idea of what I was doing. I had inherited a game engine and some portion of the game s mechanics from the previous developer. At the time, the project was very meagerly funded , and as a result, the publisher only requested a meager amount of documentation about where the game was going. I drew up a six-page document that briefly described all of the adventures players would go on. First of all, since the document was not very detailed, with just one page per major island in the game, that leftme lots of room to maneuver. Second, by the time I had implemented the first two islands, I had learned enough about how the game truly worked that I decided to throw away the last three islands and design them over again. Since I had only written brief outlines of the gameplay in the first place, I did not actually lose much work.

Keeping the development documentation light and using placeholder art kept Odyssey s development extremely organic.

Another interesting aspect of Odyssey s creation was that I developed the game entirely using placeholder art. Along with the game s engine, I had inherited a fair amount of art from another project, and kept using that as much as possible. Since the project was underfunded, I did not have an artist to work with during most of the game s development, so this decision was made more out of necessity than foresight.

However, it did mean that by the time I had the money to hire artists to finish the project, all of the game s design was done and fully playable , and as a result the artists created almost no art for the game that went unused. Using the placeholder art had not hindered the game s development in the slightest. I concentrated first on getting all of the gameplay working, and then was able to focus on the visuals. Since I was not constrained by the thought of losing already created art assets if I changed the design, I was able to take the design in whatever direction seemed most appropriate while I was working on it.

On Centipede 3D , a significant amount of work was done before the gameplay was actually fun, and almost all of that work had to be thrown out as a result. The original idea for the gameplay had little to do with how the original Centipede functioned from a gameplay standpoint, and featured a more meandering, less-directed style of play. Using this original gameplay conception , six levels were actually built and numerous other levels were planned out on paper. For various reasons, the gameplay simply was not much fun, and we began to look at what could be done to fix that problem. In the end, we made the enemy AI function more like the original game s enemies and adjusted the gameplay accordingly . When we tried it we were not sure if it would work, but that gameplay style turned out to work quite well. Unfortunately, much of the level design work that had been done was lost. All of the levels that had been designed on paper were thrown away because they were incompatible with this new style of gameplay. Of the six levels that had been actually built, three had to be discarded in order to support the new gameplay, while the others had to be changed significantly in order to play well.

Looking back, if we had focused on making the gameplay fun before making a large number of levels, we could have avoided a lot of extra work and wasted effort. With the gameplay functional, we were able to draw up documents describing how the rest of the game would function. For the most part, we were able to hold to those documents throughout the remainder of the development process, with only minor changes necessary. Of course it would have been catastrophic to the project if we had been unable or unwilling to throw away the work we had already done. If we had tried to keep all of the levels without changing them significantly, the game would have shown it and those levels would have been greatly inferior to the ones made with the proper gameplay in mind. If we had been foolish enough to stick to the initial design completely, the entire game would have suffered and the end product would not have been as fun as it turned out to be.

Keep It Simple

Early in development, it makes sense to work with only your focus instead of a long design document. The focus is short enough that it can easily be completely rewritten if your game changes direction. Yet, at the same time, the focus will give you a clear direction for what you are trying to achieve with the gameplay you are endeavoring to implement. In the prototyping stage, the focus may change many, many times as you shift the game s goals to match what you find to be working out in terms of gameplay. When your prototyping is done, you will have a solid focus that you can reasonably hope to follow for the rest of the game s development.

Unfortunately, you may not always have the option of keeping the game design process organic. If you are working for an established company, you may have a fully staffed team working on your project from the very beginning, and those people need to be kept busy making art, building levels, or coding up systems, even though there may not yet be a functional and fun gameplay prototype. It does not take a large team to get the initial gameplay working, and indeed such a large team may only get in your way as you try to keep them busy while experimenting with how the gameplay will work. You may also have demands from those funding your project s development, whether it is your employer or the publisher. Whoever is paying the bills may want to see a complete design document or script up front, before a prototype of the game has been developed. You may be forced to abandon those documents later as the gameplay turns out to work differently than you had anticipated. Obviously, crafting these documents prematurely can be quite wasteful, yet you are forever beholden to whomever is providing the funding for your project. In some ways, if at all possible, it may make sense to self-fund the project until you have a fully functional prototype. Work on it under the radar if you are at a large company, or work on the gameplay prototype before you try to find a publisher. Besides, a playable demo will make the game easier to sell to a publisher or a green-light committee. Nothing proves to the financiers that your game is moving in the right direction better than a compelling prototype.