Potential Pitfalls

Beware the Quick Fix

Treat the problem, not the symptom. Your process change may have unintended side effects.

For example, there is a general Configuration Management guideline that build and automation engineers will tell you: Try to keep your local build environment as close as possible to, if not identical to, your build farm environment.

The pipeline installed on your local machine should be the same as it is on the build farm. The process by which the game and tool code is compiled should be identical on your local machine and the build farm. If those things diverge, you lose the ability to perform the "Find" step above effectively.

These days, distributed build systems are a very well-regarded optimization. They seem quite reasonable on the surface. However, those systems do break down periodically, so they may not be the best variable to introduce into a build farm, which needs reliability and repeatability above all.

Also, they don't produce exactly the same executable that a standard compile and link would. That means that if you introduce them into a local desktop build, and you don't introduce them into your build farm, you have now broken the Configuration Management guideline mentioned above.

There is the potential to run across some doozy of a bug found in the build produced by the build farm, and find out that you have trouble reproducing it because your executable is built differently.

So, use your best judgment here. There is no absolute right answer.

Beware Inserting Complex Process into Local Iteration

In Part 1, we mentioned the complex check-in "gates" that a developer might have to work through to get his or her change into the game. In many cases, teams will apply the build and test farms to this problem. You can do this, but make sure that your build farm is ready to scale to be part of every engineers workflow.

You need to plan for the heavy usage that you'll undoubtedly experience near major project milestones. If you don't plan for peak usage, you will iterate the slowest when you want to iterate the fastest, because everyone will be checking in at the same time and efficiency will plummet.

Don't Let One Person Cripple the Team

This one seems obvious. But this situation can occur a lot if you don't plan ahead. If it's not possible for someone to check in a mistake and fix it without taking down the team, you are asking for this problem. Everyone will have to wait while this person fixes his or her mistake.

WYSIWYG is Great, But Don't Try to Do Too Much

The closer you get to WYSIWYG across your entire range of tools, pipeline and runtime combined, the better off you'll be. That is for sure.

However, some teams have introduced workflows that have created an untenable situation, resulting in loss of productivity rather than gain.

For instance, in some cases, to shorten iteration time, teams have tried to recreate much of the look of the game in an environment outside the game, typically some sort of viewer application.

They do this for what seems like a good reason: the time to load the game and advance to a place where the content can be seen is dreadful, especially during development.

But there will be no way they will be able to keep up -- the game will introduce a new feature, and that same feature will be missing from the viewer application. It will always lag, and will always be a source of frustration and pain. (See Plan for Team-Wide Change above)

Build your tools, pipeline, and engine so that they can work together to carry the change into the target environment as quickly as possible, in a form useful for the person making the change, following all the principles above.

Each tool and each person on the team is a potential contributor to -- or improvement of -- the overall project iteration rate. By focusing on the factors that add time to your pipeline, you can increase your efficiency and more quickly and reliably produce a fun game.