Computer game software development is an expensive business when undertaken on a commercial basis. Publishers will pay anything from $300,000 for PSN and XBLA games all the way up to $50 million for a game like Skate or Burnout Paradise. Given the huge costs involved it is hardly surprising that the need for a firm financial base for a project probably has the largest single impact on the development process at all stages.
If a development company has the financial resources to self fund a project then they are in the enviable position of being able to follow the process as described in the previous article Computer Game Development (an overview). However, many developers receive funding from the publisher on completion of milestones and it is thus important that they continue to complete the work as defined in their milestone schedules in order to ensure that sufficient money flows in to the company. This financial pressure, coupled with the standard need to keep prices within accepted norms, means that developers are not always in the position of having the necessary time to complete each stage of development correctly. Publishers, hoping for timely completion of a project, are often eager for development to start, while the development team, enthusiastic about getting to grips with a new and exciting project, are often straining to get started. The following details a few of the dangers that publishers and developers should watch out for during the development process.
1. A team that is busy completing a project may not have the time to commence design work for the next project or to complete the design if they do manage to start it. Starting work on a game that does not have a completed design means that code written/assets created may not be able to support elements of the game that are added to the design at a later date. This can result in work needing to be redone or good game ideas having to be dropped as they can not be easily supported.
2. Along with the documentation the publisher will require a working code demo (the prototype). As with the design this demo is often created quickly as a representation of the game, not as detailed research to evaluate certain aspects of the development process. This “far from perfect” code that should be scrapped is sometimes incorporated into the game and may cause problems at a later date.
3. The developer has a large team of people coming off a project that is in its final stages. Salaries must be paid so these people need to be working on a new project. This means there is often pressure to get everyone working on a project from the outset, even though there is no design or proper prototyping done. This can lead to wasted work and worse still the project moving immediately into full development, effectively skipping the design and prototype stages.
4. Documentation – Publishers often require the paperwork that would normally be completed at the end of the research phase to be in place before a contract will be signed. This means that task lists and schedules are often produced based on incomplete information. While these documents can be reworked at a later date the publisher will often adopt the completion date given in this paperwork. When the developer comes back with revised information they are often seen by the publisher (that pressured them for the information in the first place) as being unprofessional for changing the completion date so early in the project.
5. Team leaders/development managers often face a difficult staff balancing act during project start up. Key staff who are tied up finishing one project are often the people most needed to kick start a new project. In addition new additions to the company may be required for a new project and it can be difficult to get the right people at exactly the right time. This means that development is seldom proceeding at its optimal efficiency, especially at project start up. As most schedules are created based on the ideal team structure these documents can quickly fall out of sync with the real world development.
6. Research phase – There is a danger that this phase will be missed out completely. Publishers assume that the demo is a proper working prototype, with code written to address key issues, rather than to make a good looking demo. The development team, for their part, are eager to get on with the new project and it is often difficult to restrain the team and ensure that they revisit the design and research stages thoroughly. By failing to identify potential problems and plan for them the team are simply storing them up for later. All the research shows that solving a problem during development takes longer and is up to ten times more expensive than avoiding it through planning or solving it early in the research process.
7. Milestones – payment is often dependent on developers meeting predefined milestones. This puts pressure on them to produce demonstrable results which often means departing from best development practices. It is usually best to create and test code before creating the assets (art/sound) that will go with it. However, pressure to show that work is proceeding often means that art must be created in parallel and included in order to show that the code is working and elements of code often need to be mocked up to get these milestone demos looking good. This means the team are wasting time creating fake code simply to make a demo look good. This work will then be discarded and replaced with the final code.
8. Lack of documentation can result in mistakes because not all members of the team fully understand the ultimate aim of the project or the requirements of the elements they are working on. Each element of the projects development should have its own objectives so that the team member working on it understands how to focus their efforts. It is a waste of time to develop the fastest 3D rendering routines (at the cost of visual quality) if the project actually requires the highest visual quality in order to meet the projects overall goals. Likewise it may seem like a good idea to continue work on an element in order to improve performance, when in fact the resources would be better invested elsewhere because that particular game element already exceeds its target requirements while others are failing and jeopardizing the overall performance of the game engine.
9. Great ideas that were not put forward during the (nonexistent) design phase may surface later in development. The team may be unable to include these features because the game engine has not been written to incorporate them. It is obviously possible to rework the engine to include them but it is more expensive to redo work and will again result in delays.
10. Ideas that worked well on paper simply do not work well once implemented. Game development is a creative business and design ideas can never be fully proven until implemented. Those that fail may incur extra development time as they are reworked or may have to be removed completely. New elements may even need to be designed and implemented in order to replace them. This almost always leads to project slippage unless a large amount of “blank space” is inserted into the schedule to allow for this.
11. Bad communication between Publisher and Developer. – This can lead to a host of problems. For example a publisher’s marketing department often require marketing materials well in advance of project completion. Failure to warn the developer may means these are not available when needed.
12. Slow payment. Publisher’s often have to empty their bank accounts to fund the production of expensive cartridge based games as payment is usually required by the hardware company well in advance (by letter of credit). This can cause cash flow problems which result in developers not being paid promptly. This can often cause severe problems for those smaller developers whose sole income may be derived from one publisher.
13. Bad relationships – There may well be creative or personal differences of opinion, either within the development team or between the Publisher and Developer. This can cause real problems when it comes to getting work approved and payments made and can jeopardize the development process.
14. During the final testing phase there is often extreme pressure from the publisher to complete the project. This results in game play issues not being fully addressed because the game is rushed off for duplication as soon as all the bugs are fixed, but before proper game play balancing can take place. It is difficult to accurately balance game play when a game keeps crashing. The games learning curve can not be evaluated properly if the game can not be played from start to finish and the pace and difficulty of individual elements can not be properly set because the effect of previous sections can not be taken into account. It is a brave (or rich) developer who will fix all the bugs in a game and then say to the publisher that further work needs to be done on the game play balancing.
Conclusion
The preceding list is just a small selection of the problems that can occur during the development process. Out of all the problems, bad planning has probably the biggest negative impact on the development cycle. That is not to say that unplanned development is impossible, just that it is less efficient. By extending the development phase and reworking elements of the code it is possible to “design” game elements as the coding is being done and discard those that do not work. In fact there will always be an element of this, even in a well planned project. Ideas that sound great during the design phase and work in prototype form can still fail during development or implementation. Unfortunately this is often taken as a reason not bother with these planning stages and to proceed directly to full development, with a full team.
The burden of supporting this approach usually falls on the publisher’s wallet. Most are unwilling to cancel a project once a significant portion of the budget has been spent and so more funds have to be allocated to pay for the unplanned work and the release date may need to be delayed, often more than once. In some cases the publisher can layoff some of the burden onto the developer, making them pay the additional cost directly or by penalizing them through re-negotiated financial terms. However there is often a limit to the additional financial burden that a small developer can support, without getting into serious financial difficulties that result in the collapse of the company and the project.
