     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Game Production Handbook: The following is a selected excerpt from The Game Production Handbook (ISBN 1-58450-416-1) published by Charles River Media. -- Introduction It is important to have a process in place for creating builds on a regular basis so that features and assets can be checked in-game. If regular builds are not created, the development team cannot do proper checks of the game's functionality or ensure that the assets are displaying correctly in-game. There is a noticeable visual difference in how art assets for a console game display on a PC and how they display in-game on a television. There are numerous settings on televisions—some with lighter displays and some with darker displays—all of which can affect how something looks in-game. The developer will not see these differences unless he creates a build and looks at the assets directly in-game. If there is difficulty creating a build, it can also indicate that there are bugs in the game that are preventing the code from compiling. The developers might not realize these bugs are there until they try to create a build. If a long time elapses without creating a build, critical bugs will remain undiscovered in the code and will be more difficult to deal with as development progresses. Build Process Every development team will have a different build process, which is usually determined by the lead engineer. The important thing is making sure that this process gets defined during pre-production and implemented as soon as assets are available for creating a build. Waiting too long to establish a build process will cause development delays during critical milestones; the engineers will spend precious production time trying to work out kinks in the build process instead of coding features and fixing bugs. The process must be flexible so that it can be modified to create builds with special requests. For example, marketing might request a stable build they can demo at a conference, which has only a certain area of the game available to play. Access to the other game levels can be prevented by locking out UI functionality or by removing items completely from the game. The process must also have a way to track what has been added to the build. This is helpful if an artist is waiting for a certain tool to be finished or if a designer is waiting on a level to be finished so he can begin scripting it. One simple way to do this is to set up a “New in Build” mailing list for what's been added to the build. This way, if an engineer checks in updated vehicle AI code, he sends an email to this list stating what new code he just checked in. An artist would send an email to the “New in Build” list every time an art asset was checked into the build, and so on. This helps the team as a whole track what's being added to the build, and it alsogives QA a better idea of what to expect in each build that is delivered to them for testing. The “New in Build” emails also provide a good foundation for creating build notes, which are discussed later in this chapter. Although a primary person will oversee the build process, several people needto know how the process works. This is useful if an unplanned build needs to becreated, and the primary person is not available to do it. Build Schedule After production starts, the initial build must be made as soon as possible—well before a first playable build. This provides a benchmark for measuring the progress of future builds. It provides proof of concept and technology to the development team and studio management. By the time the game is at a first playable stage, builds should be made two to three times a week. By alpha, it is ideal to be in the habit of making daily builds. At the point when daily builds are being made, the QA department will work with the team to decide how often builds will be submitted for testing. It is counterproductive to give QA a new build to test every day. They need to spend several days with a single build to make sure they have tested all aspects of the game thoroughly. QA will probably only want to look at a new build every three to four days during alpha. The frequency of builds submitted to the QA department will increase as the game gets closer to code release. The build schedule will keep production progressing on the game. People can check in their assets and know when the build will be ready and submitted to QA. Build Checklist Creating a build checklist is helpful for remembering all the steps that are necessary when creating builds. Figure 18.1 is a build checklist for creating builds of Shanghai: Second Dynasty . This game was a PC/Macintosh hybrid and had several technical steps in the build process. In addition, several other steps were required to ensure that the correct set of assets was used and that any assets not included in the build were removed, such as development cheats and saved game files. The checklist also tracked which version of the build was being made and what files had changed since the last build. The build steps for Shanghai: Second Dynasty are difficult to understand out of context, but the checklist gives a good idea of complexities involved in making a build. This build checklist can also be given to QA so they can double-check the modifications during the code release process. Refer to Chapter 22, “Code Releasing,” for more information code releasing builds. Automated Builds An automated build process is usually simple to set up and saves a lot of development time. If the process is automated, the person responsible for making the build does not have to take time to manually complete all the steps in the build checklist. If the build process for Shanghai: Second Dynasty were automated, the build would take less time, and fewer mistakes would be made. The checklist can provide the framework for what tasks can be automated. All of these tasks can be automated by setting up a separate “build” machine, which has programming script that will instruct the machine to pull out all the updated code and assets from the version control system and compile them. When compiled, it will generate the latest build and copy it to an appropriate place on the computer network. This programming script can be set to run on a regular basis. For example, the build script can be set to run at midnight each night, so there is a new build waiting for the team in the morning.
The automation process can be taken a step further in reducing time in other areas of development. For example, on certain days the build script could be instructed to copy the latest build to all the QA machines, so that when the QA testers reported to work in the morning, the latest build was ready for testing. The process can also include scripts that check the build for errors, such as misnamed files, missing assets, or incorrect file formatting. The error log can be automatically emailed to the team so that people can begin fixing the errors before the next build is created. The lead engineer can work with the development team to set up the best way to automate the build process. A publicly visible indicator can be added to show when the build is not working. Clinton Keith of High Moon Studios has integrated lava lamps into the build process: “when an asset is checked into the game, there is an automated test suite that tests everything that is committed art- and code-wise to pipeline. If the tests determine that an asset has produced a fault, a red lava lamp is triggered to indicate that the build is broken. If the tests determine the asset is working correctly, a green lava lamp is triggered. The lamp is visible to the whole team and is a fun way to remind people to double-check the correctness of their work before checking it into the build.”
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|