Game Development Reference
In-Depth Information
either project hits code lockdown, meaning that only a few high-priority changes are
being made to the code, the project stays in the Gold branch until it ships.
All this work assumes the two teams are motivated to share the game engine and
continually contribute to its improvement. There might be a case for one project per-
manently branching the shared code, in which case it should get its own code line
apart from the Trunk branch of the original shared code. If the changes are minor,
and they should be, it
s trivial to merge any two arbitrary code lines, as long as they
originated from an original source. Even if you got unlucky and the changes were
overhauls, the difficulty of the merge is preferable to making huge changes in your
Trunk while trying to satisfy a milestone. Best to leave this activity in its own
branch.
'
This chapter has likely shown you that there is a lot of drudgery on any software
project, and games are no exception. Back in the dark ages, I built game projects by
typing in commands at the command prompt and checking boxes on a sheet of
paper. Since most of this work happened way after midnight, I made tons of mis-
takes. Some of these mistakes wasted time in heroic amounts
mostly because the
test team had a broken build on their hands, courtesy of a decaffeinated or just
exhausted Mike McShaffry.
Without using branching techniques, the whole development team had to tiptoe
around their changes during a build. Moving targets are much harder to hit. Every
game developer takes a long time to get in a good zone. If you break anyone
—
'
s con-
centration by halting progress to do a build, you lose valuable time.
My parting advice: Always automate the monkey work, give the test team a good
build every time, and never ever get in the way of a developer in the zone.
