In This Chapter
• Determining Code Release
• Code Release Checklist
• Gold Masters
hen a game is code released, it means the content is final, the bugs are
addressed, and the master disc is ready to be replicated and packaged.
A code release process should be in place to ensure that everything
that needs to be done on the game has been completed correctly. This process
will involve daily meetings to discuss bugs, a code release checklist, procedures
for submitting to a third-party for approval, and information on where to send
the code for replication. A game doesn’t get code released overnight, the process
can take anywhere from five days to two months, depending on the complexity of
the game and who needs to approve it before it is code released.
23.2 DETERMINING CODE RELEASE
Define a code release process so that the development team and QA depart-
ment are in agreement about when a game is ready for code release or final
submission if it needs to be submitted to a third-party for approval. Treat
this as a separate phase in the testing process, and be sure to check the code
376 THE GAME PRODUCTION HANDBOOK, 2/E
release candidate against the entire test plan and, if necessary, the technical
requirements checklists for Sony, Microsoft, or Nintendo. In addition, this is an
ideal time to double-check that the copyright and other legal information is cor-
rect, that all the appropriate age ratings have been secured, and that the local-
ized versions of the game have been approved by the appropriate people.
The main purpose of the code release process is to fully verify that the actual
master disc of the game that is sent for replication and manufacturing contains
all the correct code and assets. The process should be able to uncover any major
issues that need to be addressed before the game ships. The process should plan
for enough time to run through the entire testing plan and technical require-
ments list at least three times, and include any additional time needed for Sony,
Microsoft, and Nintendo approvals (usually four to eight weeks). Additional time
in the code release schedule allows time to address any issues with potential gold
master candidates and prepare a new master that can then be verified.
A code release candidate (CRC) is a version of the game that has addressed
all the bugs, has all the final assets, and is deemed ready to ship by the develop-
ment team. A game may have several CRCs during the code release process in
order to address any major issues that are uncovered. When QA receives a CRC,
they will check the game against the test plan and other code release require-
ments. Depending on how large the test plan is, this could take anywhere from
five to seven days. You may want to staff up the QA department in order to get
through the process more quickly, as saving a day or two at the end of the testing
phase can make the difference between making or missing a ship date.
Note that any game appearing on proprietary hardware such as a console or
cell phone, must be submitted to a third-party for approval. Each hardware man-
ufacturer has different requirements to fulfill before the game is approved for
replication. More information on the third-party approval process is discussed
later in this chapter.
23.3 CODE RELEASE CHECKLIST
Create a code release checklist to ensure that code release requirements are
clearly defined and understood by everyone. Figure 23.1 is an example of code
release checklist. This only provides a general overview of the types of things to
include, add, or modify anything that relates specifically to your game.
In addition, you may want to include additional information about the fol-
lowing on the checklist, as all of these items should be double-checked on the
CRC as well:
Copyright information: Usually listed in the game and on the packaging.
This includes checking the placement of all logos from third parties, such as
middleware providers, developers, and third-party manufacturers.