Bringing Engineering Discipline to 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 |
Lack of management buy-in was not a problem we had, but it might be one that you will encounter. Without the commitment of upper management to instituting engineering discipline through process improvement, it's almost impossible to accomplish any real changes. The process of making significant changes to production methods takes the commitment of everyone involved, and if management changes directions in mid-stream, all benefits can be lost. Our management and our developers devoted the time and effort that it required.
Our first significant problem was coming up with a vocabulary for everyone to use. Common terms meant different things to different people. This problem was primarily a training problem, and sending the majority of our people to SEI CMM training, combined with in-house project management training, largely overcame this problem. However, due to the complexity of the processes involved with developing games, and the number of departments involved outside of development who don't share our special vocabulary, we still find the vocabulary of disciplined engineering problematic.
The next large problem that we encountered was the team's impatience to start working (programming) on a new project. Planning a new game down to the final details before writing a line of code (other than necessary "proof of concept" prototyping) is very counterintuitive to most game programmers. Discipline came into play here, as both management and the development staff kept focused on the new processes even when tempted to follow old patterns of development.
Getting all other departments - such as our publishing, product testing, marketing, and operations departments - to cooperate with our new processes was also a challenge. We overcame many of these problems by including these departments in the creation of our processes. A grassroots, organization-wide commitment to process improvement really made a difference for us in this area, but there are always holdouts who prefer the traditional methods despite potential benefits. You need to have the key people in the departments you work with educated and on-board with your planned improvements.
The sheer amount of paperwork and process involved is daunting, particularly for groups used to a seat-of-the-pants development process. I'm sure many people reading this article wonder how any "real" work gets done with all the paperwork involved. We discovered that all this paperwork inevitably gets done, either by a predefined plan or as an emergency later in the project. In our experience, most slippage in schedules is driven by elements that weren't explicitly defined at the beginning of a project. Our process improvement effort simply acknowledged all the known requirements at the beginning of a project rather than in the midst of development when it adds to both schedule and cost.
Benefits Accrued to Date
T he biggest benefit that we've realized so far has been improved morale. Our development staff is excited to be involved in a process that is progressive and has the opportunity to take our group to a high level of effectiveness. There has been unanimous participation in the creation of and compliance with the new processes. The process changes are showing results, and developers feel more in control of the project. Mid-stream changes in projects still occur, but because projects are now less chaotic, dealing with these changes is much more manageable.
Getting the project baseline requirements written down and agreed to by all departments was a major benefit. When requirements change (as they often do), it puts you in a position to document the change and inform all parties of the effect it will have on the schedule. It allows cost and schedule trade-offs to be done rationally and reduces needless feature creep. Thinking about and documenting these requirements has headed off innumerable future problems.
Having a full design, a technical design, prototyping technology, and solid estimates of programming tasks at our disposal allows us to plan the creation of the art, sound, and editorial resources better. This has helped reduce the false starts and rework of these elements, in comparison to previous projects.
Management has a much higher confidence in the schedules of the products, and a much better idea of where the product is relative to the projected completion date. The actual schedule exists only after the technical design is completed and approved. We only use broad ranges of time prior to the completion of this phase, which requires a high degree of trust between management and development teams.
Future Expectations
We expect that as our personnel gain more familiarity with the processes, we will see further improvements in productivity. We also believe that we'll reap benefits in our maintenance efforts once our products move to that stage. Our standards will dramatically reduce the time that it takes to train new programmers to maintain legacy products. The time that it takes to find bugs and make additions to these legacy games will be significantly reduced. As we move our current set of products into production, we expect the quantity and severity of found bugs to be much lower than was previously the case. The combination of completely planning the product prior to implementation, peer reviews of key software modules, and test plans created by the team should continue to raise the quality of our software. Finally, our time-to-market should decrease as our software development process improves and our teams become accustomed to the new procedures.
It has been exciting to move towards building game software under our new model. Our new procedures allow our developers to be more effective in a normal workday, and although the occasional crunch still occurs, we no longer face grueling, continuous 16-hour days during a project death march. We have already seen a difference in our shop, with people rising to new levels of contribution and productivity simply because the environment allows it. The standard sweatshop atmosphere of game development only allowed the "coding cowboys" to be heroes. Now, we have teams entirely staffed with heroes, doing great work without having to resort to heroics. Being involved with fostering this move to engineering discipline is the most significant effort that I've been involved with in my 20 years of creating games. I believe it has the potential to take much of the chaos and uncertainty out of development and let us focus on creating great game play in our future titles.
| For Further Info... |
|
Gordon Walton has been authoring games and managing game development since 1977. He is currently senior vice president of Kesmai Corporation and general manager of Kesmai Studios, the leading developer and distributor of multiplayer online games. He has been a speaker at every CGDC since its inception, is a founder and current officer of the IGDN and speaks at other industry gatherings. He can be reached at gordon@kesmai.com
