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

Because our company is in a business where products must be maintained for several years, we felt we had to make a radical change to compete successfully. We first examined the various training opportunities available. We looked at several software development methodologies used by other industries, including the SEI Capability Maturity Model (CMM), ISO 9000, SPICE (Software Process Improvement Capability and dEtermination), and others. We found that all these methodologies contained elements useful to our goal of instituting engineering discipline. They also contained elements that could stifle creativity and ignored the importance of having fun software in favor of schedule predictability.

Because no current methodology that we investigated suited our needs completely, we decided to invest in training our personnel in the SEI's CMM methodology, with the proviso that we didn't want to follow their developmental model exactly. We sent 80 percent of our development and QA personnel to this training. We also investigated several project-management training programs. After one course given by the Learning Tree Company, two of our producers came back very excited and charged up. They really liked the particular instructor, so we contracted that instructor to give a one week class on project management to our entire development staff.

At this point, we had most of our personnel "speaking the same language" and interested in improving our software development methodologies. This was a key step. This kind of change in mindset cannot be mandated from management; it must be a joint effort between developers and management to work. We started our process of instituting an engineering discipline with three initiatives: programming standards, the peer review process, and the software process working group.

Programming standards. We quickly devised a good set of programming standards that the entire development staff could buy into, although there was some debate as to how these standards would be instituted. These standards were created in reaction to the difficulty we experienced in maintaining our legacy code. While these new standards didn't help us maintain our old code, they made sure we wouldn't perpetuate poor coding practices in our new games. Thus, our payoff will come when we hire new people to maintain games in the future. The products that our developers will maintain in the future will have a defined coding style and methods. The table of contents for our programming standards, which illustrates the elements that we believed were important to standardize, are shown in Figure 1.

Peer review process. The definition of the term "peer review" is encapsulated in this quote from the SEI Capability Maturity Model: "The purpose of peer reviews is to remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented." Peer reviews, in this context, have no impact on personnel evaluation at all; they're simply a method of process improvement - never a methodology for placing blame. This peer review process only took a few weeks to hammer out, and is now embraced by our developers. Reviews go on almost every week in our studio. The primary value of peer reviews is in finding problems and potential problems long before they would normally be found in the testing stage. A less obvious but equally powerful benefit is that all participants in the peer review process learn to avoid both common and subtle errors in their own work. We encountered some resistance to peer reviews, because there was concern that management would use these reviews to rate our developers. Once it was clear that this was not the case though, our developers embraced the process.

Our first peer reviews found significant problems that had defied other debugging methods, and every peer review we've conducted so far has found and corrected problems. As our people gain more experience with peer reviews, they're uncovering problems earlier in the development process - bugs might otherwise have taken weeks of debugging had they still existed when the game was in beta testing.

When used effectively, peer reviews are a powerful tool to improve both the quality and the effectiveness of your development staff. The relative cost of finding and correcting errors early in the development of a title is incredibly low compared to trying to correct bugs when you're about to ship. If you don't already conduct peer reviews, I recommend starting today.

Software Process Working Group. The Software Process Working Group was responsible for creating and delivering a number of items, which are consolidated into a document called the Kesmai Studios Software Process Guide. The Kesmai Studios life cycle has five phases:

1. Concept
2. Requirements Definition
3. Design
4. Implementation
5. Maintenance

This list is just one of many ways to define a product life cycle. Your company may have different phases and terminology. There is no one true way, as each company must define its life cycle to match its business and market requirements. We picked some new projects to test these processes as we created them. I will use a fictional product called Bazooka Bunny to illustrate some of these phases.

Concept. We created a document to describe what made up a valid game concept for our product life cycle. It's used to select what products are built in our studio. Because our development focus is massively multiplayer games, this quality is heavily emphasized within the concept document guideline, shown in Figure 2.

This is a 1,500 word product covering only the following issues:

High Concept: The overall game concept. Game Play: The core game mechanics. Conflict: What creates the tension that motivates players? Multiplayer Aspects: What makes this a massively multiplayer game? Spend your 1500 words however you wish to cover those four core issues. In many cases, Conflict and Multiplayer Aspects will be evident in the description of Game Play. If the game itself is evident, as well as its qualities as a multiplayer game and its ability to motivate folks to play, your proposal will have met the requirement, and done so in able fashion. For further details regarding Game Play, Conflict, and Multiplayer Aspects, read CONCEPT_GUIDE.DOC. Submission "Help Desk" Help is available from the Editorial Committee for all submitters who wish it, prior to their proposal submissions. This way, you can get feedback prior to sending it in. If you want someone on the committee to go over your proposal with you, just send a request via internal e-mail to Jonathan. He will, in turn, match you up with someone suited to the type of game you wish to create. Deadline and Delivery All submissions are due by 5:00PM on Friday, _________.

Figure 2. Concept document guideline.

For the purposes of our development life cycle and internal selection processes, we wanted our concepts to be very compact; other companies might want much more volume and detail. A committee made up of members of the studio approves concepts for further development.

[zoom]

Figure 3. Requirements Baseline initiation and revision process.

Requirements definition. The requirements definition phase is embodied by two documents, the Requirements Baseline and The Plan (see the sidebar, "The Requirements Baseline"). Our Requirements Baseline initiation and revision process is shown in Figure 3. Notice that there is a defined process for creating a Requirements Baseline, as well as for modifying the process of creating the Requirements Baseline (in the event that we decide that the process isn't optimal). All processes used must have feedback mechanisms so that they can continuously improve based on the input from the teams that use the process. A simplified example of a Requirements Baseline for our fictional Bazooka Bunny product is shown in Figure 4.

You may have noticed the large number of departments that are referenced in the Requirements Baseline. Involving so many people at this step is initially time consuming, but it gets all the key departments involved and gives them the ability to give their input about the product. It also secures their agreement that these are their requirements for the product. Any future changes result in the creation of a new agreement, and all the parties must re-approve the changes. While this applies friction to the process of making changes to the project, it does discourage people from suggesting frivolous changes. Additionally, important changes are allowed to move forward with a consensus from the key parties involved. Once these requirements are formalized for the first product, most of these requirements are reused for follow-on products.

The Plan document, alluded to in Figure 3, outlines the general path that development will follow and describes additional elements beyond the key requirements listed in the Requirements Baseline. It also outlines all project deliverables, such as a terrain editor, mission editor, manuals, and so on. The Plan is a living document that changes as the product moves from the requirements phase through the design and implementation phases. The Plan demonstrates to management that the team knows what they are doing and how they will go about getting it done. Specifically, The Plan includes the following items :