How long a game takes: prototype to gold

The phases

Two of those are commonly misunderstood. Alpha is feature complete, not playable-and-nice. Beta is content complete, not bug free. Teams that treat alpha as "nearly done" discover in beta that the remaining work was the majority of it.

Why elapsed time is roughly double working time

The same arithmetic that catches interface schedules catches whole projects, and for the same reasons.

• Reviews and sign-off. Work stops while somebody decides. Two days per review round, several rounds per milestone.
• Dependencies. The UI cannot be finished before the system it displays. The audio cannot be mixed before the levels are final.
• Rework. Playtesting finds problems, and acting on them is the point of finding them.
• Everything that is not the game. Meetings, hiring, admin, contracts, store paperwork, tax forms.
• Illness, holidays and life, which will happen to somebody on a three-year project.
• Bugs found late cost multiples of bugs found early, particularly across platforms.

How long, in practice

The most reliable predictor within those bands is not team size, it is how much content the game needs. A twenty-hour narrative game and a two-hour roguelike with the same team size are not comparable projects.

The dates that cannot move

Most internal dates are negotiable. These are not, and they are the ones to build the plan around.

1. Certification submission. Console platforms have queues and approval windows, and a failure means resubmitting. Build in weeks, not days, and assume one failure.
2. Publisher or funding milestones. Money arrives against these, and slipping one has consequences beyond the schedule.
3. Event and festival deadlines. A build for a showcase is a hard date with a fixed quality bar.
4. Store page and pre-launch windows. Wishlists accumulate over months, so the page has to be live long before launch. See the last eight weeks.
5. Seasonal windows. Launching next to a major release is a marketing decision with schedule consequences.

Building the schedule backwards

Forwards from today produces a date nobody believes. Backwards from the fixed date produces a plan you can cut against, which is the only useful kind.

1. Start at the launch date and subtract the certification and submission window.
2. Subtract the polish and fix phase, which is 15 to 20 percent of the project and is the phase most often eaten.
3. Subtract content complete, working back through the content list.
4. Subtract feature complete, which is when the last new system can be added. Everything after this date is finishing, not building.
5. Whatever is left is production time. If that number is smaller than the content list requires, you have found the problem now rather than in month twenty.
6. Then cut, on purpose, using scope control.

Where interface sits in the schedule

As the person who is usually one of the dependencies, this is the pattern that works and the one that does not.

• Too early: before the core loop is playable, since a HUD cannot be judged without motion and the systems will change.
• Right: once the loop is playable and the systems are roughly known, during late prototype or the vertical slice.
• Also right: a second pass in production, once the content list is stable and the screen count is real.
• Too late: after the systems are built and the placeholder UI has become load-bearing, which turns design into rework.
• The detail is in how long does it take to design a game's UI, and the milestone structure that keeps it honest is in running milestones.

A schedule is not a prediction. It is a list of the things you will cut, in the order you will cut them, written before you are panicking.

Signs the schedule is already lost

• Feature complete keeps moving, which means new systems are still arriving during finishing.
• Nobody can name what is being cut. A plan with no cut list is a plan that will cut quality instead.
• Polish is a week. It is 15 to 20 percent of the project.
• The bug count is rising, not falling, within two months of a milestone.
• Certification is not on the plan at all, which is common and expensive.
• Marketing has no dates, which means the store page will go up too late for wishlists to accumulate.

A schedule check you can run today

1. Write your launch date at the right of a page.
2. Mark certification, four to eight weeks before it.
3. Mark content complete, and polish between the two.
4. Mark feature complete before that. Is it in the past?
5. Count the content still to build between now and content complete.
6. Divide by the weeks available. Is the rate plausible against the last three months?
7. Multiply your remaining working-day estimate by two and check it still fits.
8. List the three things you would cut first, in order.
9. Check every external date: cert, publisher, festivals, store page.
10. Ask whoever is most pessimistic on the team what they think. Write that number down too.