Game Development
by
Gordon Walton
Gamasutra
December 18, 1998
Vol. 2: Issue 49
Originally
Published in Game Developer Magazine, December, 1998.
| Bringing Engineering
Discipline to Game Development |
Introduction
How
We Approached an Engineering Discipline
Design,
Implementation & Maintenance
Problems,
Benefits and Future Expectations |
A year ago, we decided to change radically our methods of developing games. We were dissatisfied with our maintenance costs, the effort required to achieve our desired level of quality, and our inability to predict production schedules. This article is a description of what we did to achieve this change, although you should view what you're about to read as an "after-action report" - our development processes are continuously evolving to meet our objectives.
What Is This "Engineering Discipline" Thing?
Are you sick of not being able to predict when the development of your game will be complete? Are you tired of creating bug patches for a game that shipped months ago? Are you having trouble adding a feature that the new vice president of marketing demanded halfway through development? If any of these scenarios sound familiar, let me offer you a way of dealing with them.
Engineering discipline, as I define it, is determining and applying processes to the development of game software with the goal of improving the quality, maintainability, extensibility, and schedule visibility of the software. Being able to deliver these particular elements consistently in game software is unprecedented, in my experience.
What Is the Reality of Current Game Software Development?
While both the team and management share a desire for the elements of quality, maintainability, extensibility, and schedule visibility in their software products, the primary mission of most game developers is to ship a fun game by Christmas. The desirable ship dates for most products are dictated by the realities of the retail market. With the majority of all software sales occurring between the months of September and January, the pressure to ship before Christmas is incredible. The final ship date for Christmas is about two weeks before Thanksgiving, given the normal retail distribution delays and processes. Some products succeed when shipping outside of this narrow window, but typically this success is limited to about ten highly promoted and anticipated titles. Odds are that you are not working on one of these titles.
Almost everyone with experience in game development has had to work on someone's legacy code. Most experienced programmers have had to fix an incompatibility or bug for a product developed by someone else, or have had to start a sequel from a previous product code base. In general, game software isn't written to be maintainable. Rather, the primary goal is getting the code "finished enough" to ship it as a commercial product. As such, many game developers believe that any documentation and coding standards come at the expense of getting the game done sooner. This lack of documentation and standards worked for most game developers for a time, as teams used to be relatively small and time to market was the most important issue. But times have changed.
Why Consider An Engineering Discipline?
The main reason that we at Kesmai considered a new way to develop software was that the methods commonly used in the game development business weren't working well. Our products' life cycles were longer than those of most game companies, and our maintenance costs were prohibitive. We also noticed that most products in the games business aren't financially successful, most miss their intended ship dates, and most have significant bugs and require a patch (or three). Within a viciously competitive environment, as an industry we must find a way to lower some of the risks involved with building game software.
Not all risks are controllable while developing game software. You can never be sure if consumers will like what you offer (though there are methodologies for reducing this risk, too). You never know when Microsoft might change the operating system components. Sometimes, a competitive product is unexpectedly introduced, and you must react to it. Management often will dictate large numbers of unexpected changes.
Given this chaotic environment, it's important to acknowledge and manage the risks that are under your control. For risks that you don't control, but are within your sphere of influence, you must make agreements with all parties so that no surprises occur without renegotiation. This gives you a manageable baseline with which to start, so that you can react with more clarity and confidence to the truly uncontrollable risks.
