That quote says it all. If you are one of the brave souls approaching a publisher with a game proposal, hopefully you have a budget and a schedule as part of that complete proposal. Usually, a publisher asks you to create a detailed budget and schedule, if they don't you still need to create a budget and schedule for your own uses during development.

Be advised that a the schedule and the budget is not only for you to use as you develop the game; a well-done schedule will help the publisher, investor, or banker see the scope of your project and, more importantly, it will be the biggest illustration as to whether you can actually produce the proposed title. A well-developed schedule is yet another factor a publisher will look at when determining whether you can do the game you propose and if you understand what you are trying to get into.

An all too common misconception of scheduling is that writing a schedule is simply filling in the blanks on the fly. Trying to write a schedule with out proper planning and research is a waste of time at best and potentially a great danger to your business. Schedules (like budgets, design documents, and all important documents) come from research and prior planning. If you write a business plan or proposal and gloss over (or make up) the answers, then you doom yourself and your proposal. When a publisher looks at your schedules and budgets, they will spot inconsistencies and errors right away.

Schedule Before Budget

You must take several steps in order to gather the information you will need to properly schedule your game. This information includes, but is definitely not limited to the following steps:

To generate budgets and schedules properly you have to understand project management to some degree. Project management for a game project entails the following:

A good project manager will also do a thorough postmortem of the project for future reference.

Plan Your Dream Scenario

To begin with, you should plan your game title assuming you have the best possible resources at your disposal, whether they will actually be available or not. The time for compromise is later. Start by assuming you have the money to buy the necessary equipment, rent the best office, and pay the best people to do the work. The initial game design should be done this way as well; design the best game possible. You will juggle numbers and make compromises later—right now define the best possible solutions with no limits, working toward the highest possible ideal.

Working toward the highest ideal possible initially is good project management. This approach opens up opportunities to achieve goals previously assumed impossible or improbable. By aiming high, you may make it halfway to your goal, but by aiming low you will never get above the low standard set from the beginning of the project. If an ideal goal is never examined, then it does not have a chance of being reached. We'll look at an example of this later.

Put It on Paper

You should already have at least a rough version of your design document done at this point, the basics of what your game will be. At this point the seemingly simple notes you are jotting about you title, genre, technology, and scope of the game are almost an encoded version of your schedule and budget. After the actual treatment is written a publisher can read it and have a very good idea what it will take to develop the title you propose. They can then check your supporting documentation to see if it is in line with what they think to be true.

Warning: I must repeat that your statements of performance in your cover letter, design documents, and other selling documents tells the publisher what you are proposing, and your budgets and schedules tell them whether you know what you are talking about.

Once you start putting the schedule on paper you will begin to notice relationships you could not have seen otherwise and a million questions will pop up. Not until you actually list everything that has to be done and everything that you want to do on paper in an organized fashion will you start to see what you really have ahead of you. And once you start assigning responsibilities to the tasks, you start to see overlap in schedules and work flow.

Also, don't forget holidays, conventions, and other milestones and dates in your schedule. These days, even one-day events will be critical if they fall on a milestone day. If you set a milestone on a religious or national holiday when a key worker is needed, there may be conflict if they expect that day off. Holidays and days off are part of employee hiring and management as well.

Following are some common scheduling mistakes made by beginners:

Starting the Process

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.

There are four basic steps to scheduling your game development. They are:

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.

Estimating

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.

Scheduling Your Game with a WBS

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.

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 Most Effective Solution

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.

The Budget

Now that we've defined our project and scheduled it, budgeting should be an easy task, right? Well, actually you still have several decisions to make regarding a few factors, and you still have a good deal of research to do.

Let's look at the factors that are involved in the budgeting of a game.

Performance = the quality of the job to be done.

Time = the amount of time needed to do the job.

Scope = the extent of the work being done, or the size of the project.

Cost = the overall resource that is needed to do the job. Please note that cost is not simply a final dollar figure.

Performance + Time + Scope = Cost

If, for example, you plan a Triple-A title (performance and scope) that you plan to take two years to develop (time) the cost will fall into a certain range. Changing any of these factors will effect at least one of the others, and will usually affect the cost. If, for instance, you decide to use fewer people and take four years to develop your game title assuming you will save money, then look at the big picture. Your costs actually go up in this scenario, as you have to pay for two more years of development overhead and expenses. This also applies to morale, cash flow, and other areas of the project. Think of the effect a four year long development cycle may have on an individual. Four years is generally too long to work on a game from all points, marketing, technology, and morale. You will lose people to boredom; your technology and the market will change so you will be faced with more delays and costs in trying to "develop on the fly."

Likewise, if you try to do the title in half the time, costs will go up as well. In order to meet a deadline in half the time you will need to pay personnel extra money to do the game that much faster, or pay premiums for more qualified individuals to do the work on an accelerated schedule. Think of the effect an intense non-stop one year development schedule may have on a team. The stress of trying to do a two year job in one year may kill the project altogether.

Obviously, this not to say that every project should take two years to complete these examples are simply to illustrate a point. An add-on pack may take six months to a year. A creative development team may in fact come up with a way to cut a two-year development cycle down. Using a licensed engine is an option that may cut six months or more off your schedule.

When scheduling you will start to see sweet spots in the process, where you get the most optimal effect. Looking at other factors, we can see the same sweet spot pattern (a sweet spot actually being the peak of a bell curve of effectiveness). The peak of maximum effectiveness, that is, the point at which you begin to lose effectiveness if you go too far in either direction.

An example being, hiring an inexperienced programmer for the job who may take longer to learn the tools and not work as fast, or hiring an overpowered, high priced, or even celebrity status programmer when he is not needed (figure).

Another example is buying the cheapest computer equipment to save money. If a game developer's computers all have small monitors, slower chips, and overall terrible performance and usability, then you are going to loose effectiveness in many ways and negate any savings made in the budget. Top performing computer equipment is one area that is a bit hard to overdo - in this industry at least. The better the equipment a game developer uses, the faster and better they can work. Systems that take a long time to render, crash a lot, or cause eyestrain cut down on production. You will end up wasting more time and money on repairs, lost data, upgrades, and employee breaks. It is still advisable to make sure the equipment or software is needed and will be used, but if it is buying the best often is the most economical decision.

Statements of Performance

This aspect of the proposal goes back to the importance of proper design, research, and product development. If you state in your proposal, "We will make the best 3D shooter ever!" this is a Statement of Performance. If this phrase is your goal and what guides the expectations of the team that has adopted it as the vision for the title, and you then move unconsciously into development without the tools, talent, knowledge, and know-how to make that statement of performance a reality, than you are doomed for frustration and failure.

Making unattainable statements of performance unconsciously is what often happens to a great many start-ups and new developers. They fail before they even get started because they are unaware of the fact that the equation (Performance + Time + Scope = Cost) is in effect. As this equation makes itself apparent after the fact, they quickly become frustrated and stall in their efforts.

Budget Research

Researching a budget is not simply finding the cheapest possible solution. Once again, we return to the bell curve of effectiveness. The goal here is to weigh the choices and brainstorm new ones to get to the best solution for the problem.

A few examples:

Say you have several long cut scene movies in your game that are being produced by a 3D animator. The movies must be rendered on a computer frame by frame, which takes computer time to do. You are faced with a few decisions; Do you buy the extra, high end, computer system that can handle the rendering, budget time to render on all the computers overnight or on weekends, or maybe send your files to a company with a render farm (a large computer network specifically designed to render 3D animation) and pay the fee for no hassle rendering? Other options may also arise which may include redesigning the game to have reduced, or no cut scenes, or outsourcing the 3D animation completely.

Another example: If you are developing a title that is not a cutting edge shooter, but requires a simple 3d walk through of an environment by the end user, do you write the code from the ground up or license an engine? This, like all budgetary questions, goes back to your game design and earlier research, and is affected by other factors. To make this decision you need to know your intended audience and the technology base they are using, and you need to look into the technology you are considering licensing (can it do the job? Is it well supported by the vendor and stable?) Finally, depending on whether you choose to write the code from the ground up or license the technology dramatically affects the programmer hiring decision. Does the programmer hired need to code an entire engine with complex AI and physics, or is the walk through a simple development task that requires a programmer with a different skill set?

One of the largest wastes of time and money is to mindlessly go for the cheapest solution. When looking at two choices; A) getting inexperienced individuals to do a job because they will work for less money, or B) getting the experienced, reputable, and more expensive person, it is usually a safe bet that choice B will be the best choice. The more inexperienced individual will most likely take longer to do the job, may not do it as well, and could possibly ask for tools and money during the task that they did foresee needing.

Writing Down the Numbers

A game budget usually breaks down into two parts, 'one-time costs' and 'recurring costs'. One time costs are for equipment, software, certain contractors, and down payments. Recurring costs are salaries, taxes, insurance, and rents.

Once you have defined the following, you can start the spreadsheet.

The level of performance you wish to achieve (level of technology, art, licensed property)

The amount of time you need based on market movement and other factors.

The scope of the Project (Add on pack, demo, cutting edge game)

And the cost (Artists, programmers, designers, computers, software, offices, etc.)

Below is a sample budget spreadsheet based on a 24-month development cycle. The sample is not meant to represent any real type of game or development situation.

Warning! Employees and Personnel!

You need to know whether your team members will be full time, part time, or freelance, what their salary and benefits will be, and other expenses not covered here. This is where you should have a good accountant help you determine the actual cost of having an employee. In America, after you pay your employee x amount of dollars, there are still many other expenses involved such as taxes, insurance, benefits, and other items. Having an employee will most likely may add up to be the largest portion of your budget.

If you want more in-depth information on some of the topics covered in this article, you can consult my book, Designing 3D Games That Sell, published by Charles River Media. In that book I try to cover everything an aspiring game developer needs to know to develop a game that will "really" be published.