     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Game Production Handbook: Multilingual Builds Multilingual masters save money on the replication process and are easier for operations to track. If a single disc contains English, French, and Italian versions of the game, there is only one master to keep track of, instead of three. Ultimately, this saves money, because a great number of copies can be made from the single multilingual master that can be distributed in three countries. If planning to make multilingual masters, consider the following issues:
Build Notes Build notes should accompany any build that is submitted to QA or sent to someone outside the team. Build notes describe pertinent information about the build, such as what is working, what isn't working, and what bugs have been addressed since the last build. Depending on who the audience is, the build notes will be different. All the build notes must provide basic details on the date the build was made and the version number of the build so they can be matched to the correct build. As development progresses, not everyone will receive every build, so noting the date and version number will allow people to see how long it has been since they last saw a working build. For the Development Team Build notes for the development team should focus on what is new in the build. This includes any crash bug fixes, any new features implemented, any changes to existing features, and any art assets that have been added or changed. This type of information is especially useful to the QA department, because it lets them know which bugs have been fixed. They can regress these bugs by confirming these fixes in the current build and marking them closed in the bug-tracking database. If QA does not receive build notes, they might spend time regressing bugs that have not been fixed by the development team. For Management Build notes for management do not need to detail the specific bug numbers addressed since the last build reviewed, as they are more interested in seeing the progression of the game. Instead, focus on what features are implemented, what features aren't implemented, and any feature changes that have occurred since the last build they reviewed. Also note why the change was made: was this a specific request from management, or was it something that the team changed? If the feature change was requested by management, it is good to note this because it might affect future milestone deliverables, especially if another feature was dropped to accommodate this request. Build notes can provide a good record of all the project milestones and can track the history of the game's progress. If an independent developer is working with a publisher, the publisher might have a specific format for the build notes, which might be based on the milestone definitions defined in schedule. This makes it easier for the publisher to check the accuracy and completeness of the deliverable. Other important information to include in the management build notes are instructions on how to install and run the build. This is especially important during the development process, as the PC builds will not have installers, and the console builds will need to be copied to a development kit in order to be properly viewed. This information should be basic and written in layman's terms so that anyone can copy the build and get it to work. If special software is needed in addition to the build, this needs to be included in the build, along with instructions on how to install it. For Marketing and PR Build notes for marketing and PR should definitely not mention specific bug numbers that have been addressed. Instead, the notes should focus on what key features are working and what percentage complete they are. These notes will be sent directly to journalists, along with preview and review builds, so make sure that the wording is positive, even when discussing visible bugs that appear in the game. Include specific instructions for installing and running the game. Also include basic gameplay information—the controller scheme, the main gameplay mechanics, the goal of the missions, and so on. This is a good chance for the development team to communicate what areas of the game look good and are really fun to play. If there is time, hints and tips for playing the game can also be included. Journalists often play builds that are still in development, so they will forgive anything that is listed in the build notes as being incomplete or having a bug. If the game only has 5 levels out of 10 that are playable, list which levels should be looked at in the build notes. Make sure to note which levels are not yet finished and the major things that are still being worked on in the level. Any placeholder assets also should also be mentioned in the notes. Preventing Piracy Piracy, the act of selling illegal copies of game software, is an ongoing problem for game publishers, and they are always looking for ways to minimize the impact on the profitability of a game. According to the Entertainment Software Association (ESA), piracy costs the U.S. entertainment software industry several billion dollars each year. This number increases when adding the losses for the games distributed in international markets. Piracy includes acts such as making and selling illegal copies of the game and offering the game for free download on the Internet (often referred to as “warez”). In some cases, the games made available through these illegal channels are not even the final versions. Although these games are copyrighted and the copyright is enforceable under law, it is fairly easy for software pirates to create and sell copies of the game. Since piracy is an ongoing problem, software developers and publishers are taking steps to make this practice more difficult. The most common methods for deterring this behavior are copy protection schemes and lock-out schemes. Copy Protection Schemes A copy protection scheme prevents the user from making an illegal copy of the software. Such schemes include the following:
These types of copy protection schemes are effective in preventing the casual user from making a copy or two of a game and giving it to a friend, but are not as effective against professionals. Piracy networks have the tools to crack these protection schemes and create massive numbers of software copies that are then sold on the black market. As a whole, the software industry is still finding ways to fight against this practice. Lock-Out Schemes Lock-out schemes are also used by publishers on PC games to cut down on gray market imports. Gray market imports are official versions of the game that are “unofficially” available in territories where the product was not distributed. The full U.S. version of a game in the original packaging will often show up for sale in Korea, China, or other countries. One way to cut down on this practice is to lock out certain operating systems (OSs). For example, the U.S. version can lock out Korean, Chinese, or any other non-U.S. OS in the installer. The installer will check the OS before installing the game to make sure that it is a valid OS for the game. If not, the game will not install. These schemes are easy for hackers to work around, but they do provide a small level of security and will deter a casual user. Summary A well-organized build process makes game development go more smoothly, and it is not difficult to set up an automated process that is even more effective. This chapter discussed how to set up and automate the build process and why this is important. It also includes a brief discussion of various copy protection schemes that help prevent piracy.
_____________________________________________________ |
||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|