Having identified a suitable product the game will then need to be developed (unless the publisher is buying in a completed game). The development process is complex. Each game is different, each programmer will approach a problem in a different way and each new machine released by the hardware manufacturers will be different from those that preceded it. This means that each time a game is created or an existing game transferred to a new system a large percentage of the research & development work is taken up with research. New code must be developed and new methods found to solve problems, which makes accurate planning and scheduling difficult during the early stages. As well as the changing hardware there are the changes in games themselves to contend with. Developers will often create one game and then move on to develop a completely different style of game. This will often require a whole new approach and, while all experience is valuable, will create a new set of challenges.
To keep track of this complex development process publishers employ Producers (or Project Managers) who are responsible for planning and monitoring the ongoing development on a day-to-day basis. At each stage of development the Producers role will change as detailed on the following pages.
Design phase – The Producer must ensure that the developer has produced a detailed design which matches the original proposal that the publisher signed up. The design must have sufficient detail to allow the developer to produce a meaningful task list and schedule. If the design is incomplete there is a risk that the developer may not come up with sufficient ideas for later parts of the game, or the development may be delayed while they do so. Failure to include sufficient detail will result in missed/forgotten tasks needing to be added to the task list/schedule during development. The additional time needed to complete these tasks will delay the completion of the project (the infamous product slippage).
Research phase – Once the design is complete and has been reviewed and edited the team start prototyping/researching those areas of the project that are likely to cause problems. The Producer needs to ensure that the team have identified all the possible “problem areas” that will require research/proto-typing A major cause of slippage is that teams do not undertake proto-typing or research. They start “full development” without solving possible problems through research. This means that elements of the games development will not be properly understood and may well take longer to develop than the schedule shows.
Development - With the results of the prototyping and research the Producer should be able to create a comprehensive task list and schedule. The development team will now start to write the game code and create the assets for the project, including all the art, sound effects and music. During this process the Producer should monitor the speed of development and feed this information back into the schedule in order to update it. They must also keep the various departments within the publisher (development, sales, marketing and PR) aware of the projects progress.
Implementation - This phase can overlap with the development phase. The team are starting to combine the code and assets to implement the various game levels/sections. Pre-beta testing can also start on the features implemented so far in order to ensure they function correctly. This testing should be restricted to debugging, rather than game play testing as it is meaningless to test the game play until all of the planned features are implemented. Having said that, the game play mechanics (as opposed to the overall balance of play) can be checked.
Delays can occur at this stage of development if game play mechanics prove not to work as well in reality as they did while still on the drawing board. Changes may need to be made ranging from a minor adjustment of the control system, through to the complete redesign/rewriting of a section of the game. In addition to managing this process the Producer must continue to communicate the progress of the project to everyone within the publishers and ensure that they receive the necessary information and assets (screen shots, demos etc.) needed to do their jobs.
Testing and tuning. – Once the game code is complete the game can be tested for bugs (errors) and for game play. This testing can start as soon as the first sections of the game are implemented and can continue as each new section is implemented. Errors in the code or problems in the game play will be corrected at this stage of the game. The end result of this process should be a “master” version of the game ready for duplication onto its target media.
Unfortunately this is the stage where many games fail to fulfil their potential. Projects that are late often have their testing and tuning time squeezed until only testing can be included. The result is that games are debugged but the game play is not adequately reviewed and adjusted. This results in an un-playable game which fails to meet its sales potential.
There is also the issue of hardware manufacturer approval to be handled as part of the testing stage. Games that are developed and published on proprietary console systems (such as Sony Playstation 3, Microsoft Xbox360 and Nintendo Wii) must be submitted to the respective hardware company to undergo their own compatibility testing. This process can only be started once the game is free of bugs (the hardware companies will stop compatibility testing as soon as they find one fault) and the game will not be passed for manufacturing until it has received the hardware companies approval. (See the industry overview article Hardware manufacturers for more details of their involvement in the development and publishing processes).
Following the successful completion of the testing/approvals process the game is considered to be ready for manufacture (the game is said to have “gone gold” – a reference to the gold disks that are sent to duplicators for manufacturing).
