Game Development Reference
In-Depth Information
The Patch Build or the Product Demo
It
s not crazy to start working on a patch build or downloadable demo immediately
after the project signs off. The patch build is fairly common on almost every plat-
form. If you know you need to build one, there
'
s no reason to wait. A downloadable
demo or trial version of your game is always a good idea.
I suggest you leave the patch build in your main line of development in your source
code repository. The patch build should simply be the next minor version of your
game and is exactly what you
'
ve been doing since your zero bug date. You can release
the thumbscrews a little and consider some slightly more radical solutions to pro-
blems that you wouldn ' t have considered just a few days ago it all depends on
your schedule for the patch.
It wouldn
'
t be uncommon to wait for initial customer feedback for finalizing the fea-
tures and fixes that you
'
ll include in your patch. Your customer base will likely find
something your testers missed, or you may discover that a known problem is a much
bigger deal than anyone expected.
The downloadable demo should exist in a separate branch in your source code repos-
itory. This is especially true if you code the demo with #ifdef_DEMO blocks or some
such mechanism to cut your game down to a tiny version of itself. It wouldn
'
tbe
crazy for some programmers to work on the demo and the patch simultaneously,
and a separate code branch will help keep everything organized.
'
The Postmortem
A good postmortem should be held a few weeks after you sign off your game. There
are tons of ways to handle it, but there are a few common goals. Every project is a
chance to learn about game development, and the postmortem is a mechanism that
formalizes those lessons, which will ultimately change the way you work. It isn ' ta
forum to complain about things that went wrong and leave it at that. Instead, your
postmortem should identify opportunities to improve your craft. It is a forum to rec-
ognize a job well done, whether on the part of individuals or as a group.
In postmortems, it
s really easy to get off track because everyone on the team wants
to say his piece about nearly everything. That
'
'
s good, but it can degenerate into
a chaotic meeting. It
s also not a crazy idea to split the team into their areas of
expertise and have them conduct mini-postmortems in detail. For example, the pro-
grammers might get together to talk about aspects of the technology or their meth-
odologies, surely stuff that will bore the artists to the point of chewing their own
limbs off
'
to escape the meeting. Each group
programmers, artists, designers,
 
 
 
Search WWH ::




Custom Search