Game Development Reference
In-Depth Information
Keep the game code clean for launch right from the early stages of development by
ensuring that any comments placed in the code or any functions that are introduced
for testing (infinite life, invulnerability, hooks for automatic test scripts, and so on)
can be easily and reliably removed. Nothing can be more embarrassing than to let
code ship with comments like “remember to remove this prior to shipping!�? These
comments suggest that the code was not in a true release state when it went to retail,
which is hardly the image most companies want to project. Where possible, consider
whether such code or hooks can be placed in separate DLL files. Clearly label test files
separately from the release version of the same files to reduce the risk that the com-
mercial code will enable people to cheat or flood the game servers with simulated
players just as you did in your stress test phase of automated testing. Although all of
this may sound obvious, a book could be written on code and comments that have
been left in games when they were never meant to be there at retail!
Manage Builds
Test procedure automation will be substantially impeded if your company does not
have good build management procedures in place. Once you set up scripts to test cer-
tain parts of the game code with each new build, any builds that slip through with
those parts of the code omitted will throw your automated system into disarray. Your
tests will generate a sizable amount of false data in the belief they have found errors.
As mentioned earlier, if you have a good filter in place, this need not disrupt your
entire project. Nonetheless, it will introduce unnecessary headaches for the person
responsible for filtering the automated test output.
Poor build management can also lead to immense confusion with automated scripts
if the changes made in a given build should have been accompanied by revised test
hooks written into the new game code or revised test programs and tools written to
accommodate the new changes in the code. Continue implementing your best config-
uration management practices in conjunction with automated testing and also consider
how they might be impacted by the introduction of automation.
Test Game Code Prior to Committing
In the rush to get a title completed, programmers can be tempted to commit code that
is not tested. This can bring the entire project to a grinding halt. Here is one area where
test automation can flourish and become integral to the build-management system
upon which the rest of the test automation program relies. Building into your system
the requirement that every programmer must submit his or her new code for testing
before it can be committed is just good sense. This is also something that can be highly
