Gamasutra - Features - "Budgeting and Scheduling Your Game" [05.04.01]

Start your schedule by breaking out the tasks to be done. If your programmers will be using an existing engine and set of editing tools, then that will decrease your development time and may even decrease your cost of development. Keep in mind that no matter what the tool set, there will still be a significant amount of programming to do if you are to develop a game that stands out. A game that is simply another game with assets swapped will have much against it in the publisher's "potential title" arena.

If your team does not have enough experience in developing projects, you may have to complete a running demo just so you and your team will be intimately familiar with the tools and code base used. Only this way can you know if there are any supplemental tools needed and what is involved in writing the additional code your game will require. Also, you need to be well aware of what the technology you licensed has been used for; it's amount of support, upgrades forthcoming, and the strengths and weaknesses of your technology.

What must be done? Having your game defined and experience with the technology to be used is imperative. You simply need to know how many levels you will have, sound effects, menu screens, code libraries, and every aspect of your game. What must be done also includes equipment purchases, office rental, hooking up phone lines, and so on.
Who will do it? You can decide who will do what based on what needs to be done. If your game is art-heavy, you need to have the right number of artists on hand.
What resources are needed to do the job? With every person you add to the team, you must add office space and furniture, computers and equipment, software and salaries. This may also include added legal expense for each contract that must be negotiated. Of course, this also includes game development software each team member will need such as programming technology and the 3D/2D tools the artist may need.
When must it be done? Each person needs detailed schedules for their work and an understanding of how their work affects the whole of the project. When deadlines are set, they must be met. The effects of one team member missing a deadline can have drastic effects team-wide.

How do you break the work down into a schedule? You use a Work Breakdown Structure, or WBS. With the WBS you take a complex task and break it down into smaller tasks. You keep breaking the tasks down until you can estimate, with accuracy, how long each of the individual tasks will take in terms of time, talent, and money.

You should break each of the tasks down into units using days as the smallest unit of time. A task should not exceed a week or two in length. If "building eight character models" is a task that the artist estimates will take eight weeks, then that task is not broken down far enough. That task should be broken down into eight tasks that each takes one week to complete, each model being a task. This will be easier to track and control during development. If the task were left as one eight-week task then it could be two months before anyone knows that the artist is behind schedule. At a weekly status meeting a one-week task can be checked and verified.

For example: If you were to break down the simple task of creating a menu screen you would have something like this:

The artist working this out will suddenly have a long list of questions for several people after doing this, for instance: How many options will there be in this game? The more you have, the smaller my font will be or the more menus I will have to design. Will I be using a prepackaged font, or creating a custom font for the game, which will take a lot more time? Speaking of fonts, will I have to create each menu option or will the programmer blit fonts over the menu? What resolution will this menu be displayed at, and will I have to create versions of the font in different resolutions or will the programmer resize the images on the fly?

You get the idea. Things such as resolution, number of colors, and file sizes will come out of this process. Also note that this example, a menu screen, may be quite simple for a 3D shooter, but highly complex and involve many artists for a game such as an RPG that may have a great deal of menus and options. Also note that a task as simple as a menu screen suddenly becomes a task that may take a week or more seeing that the artist has to get input from other people and consider a great many options.

This also illustrates the importance of having the people who are going to do the work participate in these exercises. It is really easy to underestimate the amount of time any given task will take when not considering the whole of the project and the interdependencies of other members' tasks. Needs and tasks will evolve from each other's breakdowns. The above artist breakdown of one simple task illustrates how the artist will need input from the designer, programmer, and maybe even the accountant who will want to know, "What's cheaper, buying a font package or spending days creating a font?"

It is critical that everyone see and sign off on the WBS. It is impossible to sit and schedule a game without the input of all involved. This is also the process where potential problems are uncovered and ingenious solutions are devised.

For example, an artist may request an application to simulate the menu so he or she can run art through it and see how it looks in operation. The programmer will dread adding this to his or her workload and may immediately resist the idea. Another team member may suggest using a drag-and-drop web layout program to load the screens and see aspects of the menu in operation, such as the menu rollover buttons and screen changes. An added benefit to the game team is that they will have an artist that knows a web layout program.

It is important to be sure that you know you are operating on schedules and budgets that are estimates. No one can predict a budget or schedule with 100 percent accuracy. When the project manager's priority becomes the 100 percent accuracy of his budget or schedule, you are in danger of making (or having made for you) bad decisions. While staying on budget or schedule is of course not bad, making decisions for the sole purpose of "hitting the mark" can be. This is also not to say that you don't have to have a great degree of accuracy in your estimations, you will have to.

The purpose of estimating is not to protect you from huge mistakes or your own incompetence, but rather to show a realistic amount of variation in a schedule. This is usually expressed in a fluctuating percentage of some resources: time, money, or other resources. Explain how your estimates were made based on experience or research and give a "freshness date" for the estimate. Some of your estimates may be based on factors where time will affect the accuracy of the budget or schedule.

For the purposes of this article, we will look at the basic Gantt chart (see Figure 1), a simple bar chart that will effectively let you plan and document the proposed development and communicate to your team. Professional project managers often use the CPM (Critical Path Method) or PERT (Performance Evaluation and Review Technique). These methods are more complex and thorough and are what you eventually will need to use for the actual development of the game.



	FIGURE 1. The basic Gantt chart.

If a team member fails to complete a task or is late in completing it, the project will hit a standstill if no one can move on toward a goal or milestone because of the slip. A noncritical slip will not slow down the project as much as something like the failure to implement a new font in the menu or other change. A critical task would be one that prevented a major milestone to be met.

The danger of slippage during development must be watched, and this can be a hard task. Every day that a milestone slips is another day that has to be either made up or added to the completion date, forcing completion being pushed off a day later. All too often it is easy to think you will burn the midnight oil, or somehow make it up at the end, but this usually never works, and slippage begins to snowball. The effects are both real and psychological.

It is extremely important for the team to always assess and update their project schedules. It is hard to be honest with yourself and especially so with the publisher, but it is better to admit you are a week or two behind up front than wait until the end of development and announce that you will be having a three-month delay. The mental effects on the team and the project leader will be enormous if you let this happen. Most everyone knows the feeling of being overwhelmed by a task that feels impossible or out of control, and no one likes it. Few can function at their best under such circumstances. When the publisher finally does find out about the delay, they will not be happy about it, to say the least. Since there will most likely be no options to complete the game on time, they may simply drop you and sue you for the advance and lost revenue as well. That's right, if the publisher projected that they would make a million dollars off the title, and you don't deliver, then there is a chance they may sue you for that amount if you are the cause of them losing that projected revenue.

To prevent this, it is a good idea to have weekly status meetings, quick meetings that bring everyone up to speed on the status of each other's work. Grievances can be aired, suggestions made, and any slippage corrected. It is often the case that no matter how hard you work at communicating among a team things are not understood and wires get crossed.

An example is the discrepancy in communication that exists between individuals with different areas of expertise. When a programmer says "a small file", he or she may mean, for example, a 256x256 indexed-color image, about 66KB in size. When an artist hears "a small file" he or she may come back with a 6MB file, which is small compared to the 60MB files the artist may have dealt with in the past.

The primary concern of project management should not be solely focused on the scheduling, but picking the right solution to the completion of the project. As I've said, scheduling is a by-product of project management. The right person for the job and the right tools -- in short the most effective approach -- is your main goal in project management.

A great real-world example of this is Third Law Interactive's use of the Lithtech engine for Kiss Psycho Circus. Even though they had access to any game engine or technology they could want (Unreal, Quake, and so on), they chose the platform that would work on a wide range of computers. They realized that the best thing to do would be to create a game that would please both the hardcore gamers and the not-so-hardcore gamers. Kiss has a substantial following and not all of them are hard-core computer gamers with the fastest computer with the latest technology driving it. Not many developers would walk away from using Unreal or an id technology for the right reason, and it may have also been hard for the publisher to pass up an opportunity to use one of those big-name technologies in the marketing of the game.


				\|\|\|\|

________________________________________________________