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

Your pipeline should have a good Audit Trail, with logs, metrics and content lineage. You must be able to easily tell the difference between the data you build locally and the data you get from a build system. Don't commingle. Compartmentalize your data.

Reduce Compiling and Linking Times Where Possible

Compiling and linking times are huge on projects the size of a modern game development effort. Do what you can to shorten these times.

There are lots of tools available to engineers to make things go quicker; pre-compiled headers, incremental linking, and distributed build systems, to name a few. (Note the pitfalls below.)

Perform the Smallest Number of Transformations Possible

Understand the roles on your team, and what build results each person MUST see to determine if their change worked. For example, do you need animators to run your lighting build?

Transform Only What You Change

Transform the minimum amount of data that you can get away with. If you edit a texture, transform the texture, and nothing else. In fact, if you only need to change the alpha channel of the texture, make sure your pipeline supports outputting only the alpha channel (assuming you store it separately).

Do the minimum amount of data transformation (measured by time elapsed) that will still put the data in a form that the target application can read. Decide what's important that you see on the target. Is real lighting important for every change made? If you eliminate some steps, can you still do your work?

Don't do dependency-based content builds during host-target iteration. It will not scale. Large amounts of content will take forever to check. It's better to intelligently build only what has changed. Your "do nothing" build should literally be, do nothing.

Note that you likely want a dependency-based build in a build farm, where you are building lots of content, have all of the intermediate data (hopefully local to the machine that needs it), and when an iteration time measured in seconds is not required.