Controlling Chaos in the Development Process

Author: by Tim Ryan

The chaos of game development is a roller coaster of ups and downs, stimulating passions and causing agony on an almost regular basis. But there are common-sense solutions to the prevailing sources of chaos, and it is possible to be successful in this competitive market while managing an evolving game design.

The upheaval inherent to game development projects comes from many sources, and here's a few you might recognize from past experience:

Manage Turnover Risk through Documentation

Employee turnover cannot always be helped. While you can do your best to keep your employees happy, they may elect to leave or prove incapable of performing their jobs. To reduce the amount of chaos their departure creates, make sure they are documenting their work while they work. This means that artists should record what they've done and where it is. A simple checklist will do. Programmers need to comment their code and adhere to coding standards to make it easier for people to pick up where they left off. Managers should be sticklers for updating the progress of tasks on a schedule and for documenting the management decisions and communications. Designers should also record what they've done and where it is and document any design decisions and proprietary knowledge they have. The risk is made clear by the "Bus Principle". If a bus hits an employee or two, how much of an impact will their absence have on the schedule? When your eyes start to roll contemplating the impact, that's when you should start demanding that these employees document their work.

A Commander of Different Stripes

No one can just pick up the producer reigns and not make any impact to the design or the schedule. Besides, projects with new producers usually have had problems and require changes. If you are one of these producers, take the time to evaluate the current design and schedule before promising any dates. You may need to reassert the vision with a whole new round of documentation. You may have to hire new people and restructure your team. You may have to alter or compile a new schedule. Then give some well thought out dates to your managers or publishers. Don't let the desire to please your superiors by trying to meet the original ship date burn out your team and reduce the quality of the game. It takes time to turn a project around smoothly.

Substance and Pride

Games and the people making them have to radiate a perceivable integrity and pride. This should come from reliable, definable and measurable substance rather than unsupported hype. Developers of all skill levels want to make first-class titles, but they're often so blind to their own abilities and to what developing a first-class takes that they don't even know when they are full of it. They promise the world but don't deliver. To eliminate this problem, strict documentation guidelines should be adhered to, the project should be subjected to regular "proof of concept" reviews throughout the design and implementation process, and employees should also receive regular reviews.

Documentation Guidelines

Documentation guidelines should require the details that define the substance. Too many design documents written are too short or so full of fluff that they lack the specifics on what the player does and sees. Design documents need to define game flow and a functional description of game mechanics and gameplay objects. They need to define the player interaction and GUI requirements and include lists of objects, art, musical scores, sound effects, screens and menus, as well as short descriptions of each game level that specifies requirements and introduced objects. Documentation should also include a technical specification. This forces the programmers to define the nuts & bolts and thoroughly think through how it's going to be implemented before development begins. While it may seem like a lot of wasted time, a month of planning and documentation can save the project months of bug fixing, rewriting code and module integration. It helps delineate program areas and responsibilities, and lets you define the tasks for the project schedule. Most importantly, it turns the ethereal substance dreamed up in the design document into a blueprint for how it can actually be accomplished. It may force the design to be scaled back a little, as often what is imagined just cannot be accomplished in the time provided, or because of technical restrictions of the platform and tools. Often, however, early technical reviews of the concept and design document can eliminate the need to scale back later.

"Proof of Concept" Reviews

"Proof of concept" reviews should occur after the design documentation and again after the technical specification and schedule are created. They should also occur after a milestone that offers some measurable (i.e. visible) validation of the project, like the first playable mission. Reviews should also happen at the Alpha and Beta stages to ensure the project meets its goals. Some companies review projects every month or so. Senior staff and experts (sometimes outside consultants) conduct these reviews. These reviews serve as a reality check for the project and a clearing house for problems interfering with the quality or timely shipping of the game. The reviewers can potentially kill a project or put it on "probation", which is sort of a warning to deliver better results by a set deadline or else.

Employee Reviews

Employee reviews should occur at the end of projects as well as on a periodic schedule to evaluate their skills, progress and contributions. This keeps employees grounded in reality and recognized for their achievements. It is an opportunity to hear their complaints or desires and address issues that may be interfering with their performance or their goals. Reviews serve as a reminder to both the employer and the employee about their value to the team. Raises for good performance, even small ones, go a long way to boost self-esteem and company pride and reduce employee turnover. Reviews are also a good way to weed out the undesirable employees or whip them into shape. The old saying "one bad apple spoils a bunch" is very applicable to employees on small development teams, so frequent reviews can identify these bad apples before they spoil the project. Invite them to speak their mind and you may be surprised to hear about some festering gripes or feelings. You may be able resolve them before they spoil the employee or spread, or you may have to give the "shape up or ship out" speech.

Handling the Learning Curve

We are a young, growing industry with a high demand for people, and unfortunately we have relatively few applicable degree or certification programs. This means we get flooded with inexperienced or unskilled people who just want to make games for a living. While this keeps the salaries relatively low, it does cost the company a lot of time and money to train them, and that can create chaos during their learning curve. Keep a developer's learning curve in mind when scheduling his or her tasks and listening to opinions, and try to provide younger developers with a mentor to help them avoid beginner's mistakes. Give them more frequent reviews, especially if they appear to be struggling. They may just need to be utilized differently or get better instructions. They may surprise you and become your star performer, or you may come to realize that they are marching to the beat of a different drum and decide to send them marching on their merry way.

Plan on Change

There is some chaos you cannot avoid, like inherent problems in the game design that only become obvious when a feature is implemented or the game played, or when competitive games come to market that put your design to shame. While this doesn't always occur, the industry's move towards quality as opposed to quantity is making developers more aggressive in pursuing "AAA" titles. This requires evolving the game design to meet higher expectations that can change during the course of development. So what is a producer to do? Develop the game with the knowledge that the process will change as you go. There are two commonly used approaches to the game design process. They are:

Most people who have experienced the chaos of design-on-the-fly projects have become advocates for the first approach of documentation and planning. However, despite their best intentions, many projects still slip into a design-on-the-fly mode as the design evolves to meet a changing vision or a competitive market. The problem is that you never really know how good the design is until you experience it. The vision can change when what was envisioned in the documentation is implemented, and it turns out to be not very fun or impressive to the developers or focus groups. Drastic changes are needed to improve the quality of the game. Sometimes a competitive game will come out that puts your design to shame or inspires you to make improvements, and you have to make changes to compete with it. But if your project plan doesn't anticipate changes on the fly, changes will likely be implemented in a hurry with little or no documentation, with the team working many late nights and weekends to make it happen. Even so, the schedule in these cases usually slips, you experience cost overruns and you miss ship dates.

The Solution

The solution is a balance between both approaches to design - controlling chaos by planning on change. Preliminary documentation should be complete enough to plan the project but not bother with details that cannot possibly be definitive until it's actually seen or experienced. The amount of time you give tasks in a schedule should be based on risks of failure and the time to experiment and make improvements. The components of the game should be modular and distinct enough to allow evolution or replacement without impacting other components. Balancing factors should be more accessible to the designers, and their tools should be powerful enough for them to develop and experiment with gameplay. The final few months of the project should be spent with each member of the team honing their portion of the game to perfection and putting in the finer details that turn a good game into a great one.

First, anything that's experimental, untried or unproven should be given extra time for exploration, tuning and possibly replacing. This includes new graphics engines, experimental perspectives and GUIs, original gameplay, new art motifs, new AI schemes and new tools. If this requires you to dedicate six months to R&D, so be it. That's what it takes to make ground breaking titles.

Second, the documentation should not all be planned out up front. It's pointless for a designer to create specifications for arbitrary details that are not pertinent to the overall vision, especially those that are likely to change, such as GUI design and level layouts. So much of GUI and level design is elusive until the first mock-ups are done and the first level is playable. The design specification should only describe the basic requirements and include enough diagrams or drawings to convey the intent and function.

The schedule should allow time for the 2D artist and programmer to make multiple passes on the GUI until its look and feel is perfect. Except for meeting the basic requirements described in the spec, artists should have complete freedom to apply their graphic design sense in developing a quality GUI.

When making the first playable level, the game designer should observe what works and what might be possible. Give the level designers time to learn the tools and the design palette, and to experiment with them, before they begin designing their first level. Then have them draft a detailed paper version of the level before they begin each level to make sure that everyone is on the same page. This avoids wasted effort at the beginning, such as antiquated level design documents, and it makes the delayed versions much more credible.

I've seen file drawers full of GUI specs and mission documents that were never implemented, while meanwhile pinned to corkboards and sitting open on desks are the few documents made during implementation that proved much more valuable. These documents are more valuable because they were made after everyone had time to experiment and observe what worked or looked best.

Use modular implementation methods to keep each substantial portion of the game programmatically distinct. This way each can evolve to meet quality and market expectations without causing setbacks in other modules.

Put all balancing or other arbitrary design factors into .INI files or similar text data files that are read at run time so designers and producers can experiment and balance at their leisure.

Create tools that allow the designers to experiment with gameplay without getting programming staff involved. This way the design can evolve without impacting other areas of the game.

The Schedule as Sword and Shield

It's not uncommon for someone on the development team to come up with a great idea to implement in the game, only to find that the schedule doesn't allow the necessary time to implement it. Even if you allow time for experimentation and evolution, the game may be so near Alpha that taking the time to build in the feature would jeopardize the milestone and stability going into testing. Handling feature creep, requires a definitive schedule. Without such a schedule, nobody can decisively say whether the schedule can spare the few days or weeks necessary. However, if your schedule is honed enough, it can make the correct decision for you. Do you or don't you have time to properly implement and test this feature? With the decisiveness of a slashing sword, your schedule will decide what ideas survive or must be killed, without causing chaos or loss of creativity.

Has this ever happened to you: Your superiors have this "excellent" idea for improving your game, but you know it's going to throw off your schedule or require some serious, sanity-burning overtime effort by your team. The catch is that you're not ready to burn up their reserve fuel. What do you do?

Well, since you are ultimately responsible for the schedule, it's your job to point it out to your superiors who may not be as familiar with it as you are. If you can tell them what impact it will have on the schedule and the budget, you're passing off the decision and the responsibility off to them. They don't often want to be responsible for changes that effect the bottom line, so they'll likely drop the idea. This effectively shields your project from disruption, but only if you are maintaining a schedule well enough to project the impact.

Trust Feelings, Consult Experts

There are times when perfectly reasonable decisions, opinions, estimates, designs or approaches can feel wrong. As a manager, it's your duty to explore those feelings before they prove right and problems erupt. These feelings come from instincts you have gained from your education and experience. You cannot always put a finger on what is wrong, but it's important not to dismiss your intuition. The problem may be in an area that you are less familiar, so you may want to get an expert involved and ask them to explore the issue with you. If after careful deliberation you can explain exactly what is wrong, then it's your responsibility to voice it and make corrections. If you cannot figure out exactly what is wrong, then closely monitor the issue and allow some time in the schedule to fix a problem if one should arise.

A perfect example is the time estimate for a programming task. It may seem too aggressive or too bloated. Some people are not very good at estimating time for a task or have ulterior motives to make a task take longer than it should take. If you're not technical, talk to the lead programmer or technical director about it. If it is the lead programmer giving you the estimate, find an outside source such as your publisher or fellow managers for their opinion. They may tell you that the time estimate was way off, and give you a better one. By trusting your feelings enough to explore the issues, and by having a group of experts available to you, you can resolve issues before they become problems.

Tim Ryan is a freelance game developer and software consultant. He has produced and designed computer games since 1992. His recent work can be seen in the PC game MechCommander: The First MechWarrior Game of Tactical Command. Please send your feedback, questions and business inquiries to [email protected].