Building a Mindset for Rapid Iteration Part 2: Some Patterns to Follow and Pitfalls to Avoid By David Gregory

[Following his initial take, EA veteran and Emergent VP Gregory completes his look at rapid iteration by examining patterns that can help development teams rapidly make game changes and see them reflected in the playable product.]

In Part 1 of this series, we discussed the reasons why rapid iteration is so critical to your chances of success in building fun into your game, and some of the contributors to increasing iteration rates as teams, projects and toolsets grow ever larger.

Content transformation "expense" was defined as time elapsed before the change can be seen in the appropriate medium, usually a game engine or an engine-derived viewer.

With the goal of increasing efficiency on a game project, we started by looking at content transformations as the first optimization point. Now let's dive into the details of where you can squeeze significant time out of your processes: the development team's tools and practices.

Patterns to Follow

If the whole is equal to the sum of the parts, then the iteration rate for each individual developer on the team makes a big difference in your overall iteration rate. Make sure that each developer is working in the most optimal environment possible. Get a Handle on Your Development Workspace(s)

Maximizing productivity is a lot about the details of a developer's day. Minimizing disruptions is important, be they attendance at unnecessary meetings, or just interruptions that break the flow of concentration in the middle of a task.

For example, you need to be able to Context Switch between development workspaces quickly, on the same machine. You may be asked to work on a feature, and at a moment's notice, fix a bug you aren't set up for. How do you minimize the interruption?

The development workspace is the collection of data, software, tools and utilities that achieve a number of transformations on data. For instance, your compile workspace includes source code, compiler, linker, environment variables, registry entries, project files, solution files, etc.

Your artist workspace includes digital content creation tools, the last known good pipeline tools for your game team, and the last known good target environment for you to check out your work in.

A lot of workspaces are set up as global singletons, making it impossible to switch workspaces on a single machine. This makes it very hard to set up your machine to debug a problem from another branch, and it makes it very hard to keep your build process the same on both your local machine and the build farm.

Notorious "problem child" software includes anything requiring an installation procedure, or anything setting up registry entries or global environment variables. This includes anything installing itself in the global assembly cache. Any configuration with hardcoded drive letters, or absolute paths, is generally a no-no.

The best configurations are usually file-based and script-based, and can easily be moved around from base directory to base directory, and can be distributed simply by syncing from a source or content control repository, or from another distribution mechanism if required. Plan for Team-Wide Change

Game development is all about dealing with change. Development teams will often customize anything they can to achieve the desired result. There are some things you can do to try to limit the risk of making those changes.

For one, you should reduce your variables when introducing new functionality in the pipeline. Change as few things at a time as possible. That means staging your changes and lining up test plans for each change.

For example, you should not introduce a new texture compression method to your texture packing tool at the same time you're adding cube maps. Let one get tested and introduced to the team before the other is rolled out.

You should also set up a way of reliably testing new pipeline tools without affecting the entire team. Your content build farm should be able to run with last known good tools, or with untested tools. Results of an untested tool content build should not be released to anyone other than the person(s) testing the results.

Remember that not everyone is using the same versions of data and code. You should introduce data versioning and serialization capability into your non-shipping application.

Train your engineering staff to maintain version compatibility at least one version back from the last known good build, or whatever range you are comfortable with. This can be achieved without affecting the performance of the shipping application. Follow Good Configuration Management Practices