📜 See all articles: Sitemap
⬅️ Previous Article: Estimating Features
➡️ Next Article: Budgeting Overview
There are two sides to building a production schedule:
Before: Oh my god, this is going to be so much work, and I don't know where to start.
After: Oh my god, I can see exactly how I'm going to make my game.
I promise you this: the feeling of seeing your game's roadmap laid out before you makes all the hard work worth it.
Now that you know how to break down both content and features, we can finally tackle this beast. The process will take you a couple of weeks, and it will command a decent chunk of your sprint workload--be prepared.
Heavy-duty production planning becomes work for your team members, too (a lot of meetings and conversations), so when you get to this stage, I recommend lightening each team member’s workload by 2-3 points of sprint work for their trouble.
Your first step? Open a new spreadsheet.
A quick formatting tip: while you'll ultimately create a Gantt chart to house your production schedule, I recommend starting with a big table in Excel/Google Sheets. This is a pretty messy project at the start, and I find that Gantt charts don't make for great sandboxes.
At this stage, you want to track the following:
Description
Discipline
Category (Note: this refers to the aspect of the game each task applies to. It's helpful to organize. Create a system that's intuitive.)
Who? (Note: you won't always have an assignee, but if you're running a small team, you often know who does what kind of work.)
Size (Note: this can be expressed in terms of points or time.)
To refresh your memory on any of the above, see Backlog Management.
To populate the spreadsheet, first use the tips from Estimating Content to multiply your vertical slice. Make a list of everything you'll need to develop. Size it, and add each item to the table. Generally, the more granular the better. While you'll be able to combine some of these tasks down the road, granularity ensures accuracy.
Next, make a list of all the features you still want to add to your game. Use the tips from Estimating Features to estimate their size, and add them to the table.
It can be hard to think of everything that goes into a polished game, and you're bound to forget something. This is a great time to return to your comps.
Using Comps
You’ll benefit from looking at comps (see Market Research) to inform your game’s scale when it comes to both content and features.
Let’s start with content. If you’re building an RTS/builder game, how many buildings and unit types do your comps have? If it’s a roguelike, how many customization options are you presented with throughout a run?
Now let's look at features. Comps help ensure that you don’t forget to plan for a critical feature. When you’re playing through a comp, pay attention to all the quality-of-life features you enjoy as you navigate the ecosystem—menus, hotkeys, accessibility settings, voice chat options, a tutorial, pings… the list goes on and on. What have you accounted for? What haven't you accounted for? If you don’t have it, do you need it? This process, and these questions, help you ensure that you don't miss critical steps in game development.
Once you’ve created a complete list of content and features and sized those tasks by discipline*, you can finally see how long your game will take to make (I’ll hit this later and often, but add 20% to whatever number you come up with).
*I just used sixteen words to describe a hellish, complicated, and imperfect process. Consider yourself warned.
A Quick Budgeting Break
Once you get to this stage, you should take a step back from production planning to get a sense of your game’s overall budget requirements. We’re going to do this the quick and dirty way. Here are the steps:
List out each team member’s weekly pay (salary, hourly rate, however you have it structured). Hopefully you’ve discussed compensation with everyone on your team by this point—if not, do it now! I talk pay philosophy in Estimating Your Costs.
Multiply their weekly pay by the number of weeks it’ll take them to complete their share of work on your game. Add 20% to the weekly total if you haven’t already. Note that some disciplines, like art and sound, can start several months into the project.
Add $10-25k for legal, accounting, and platform costs, assuming you haven’t already done things like setup an LLC, created employee contracts, hired an accountant, etc. (I know, it’s frustrating—Wwise alone can cost you $10k!).
This process generates quite a rough ballpark figure. You'll need to tighten up your math, but this is a great place to start.
Here’s the most likely outcome of all of your hard work:
Your game will take longer to make than you expected.
Your game will therefore be more expensive to make than you expected.
I hope, earnestly, that this isn’t the case. If it isn’t, you nailed it. But it’s more likely that you overscoped, so it’s important at this stage to talk about cuts.
Cuts
Cuts are the worst. Your game is your baby, and you don’t want to deny it all the bells and whistles that it deserves. You uniquely understand its potential, and you know that cutting too much means it won’t live up to that potential. It won’t be one of the greats. Nevertheless, cuts come. Only you can decide what should stay and what should go.
“But Zach, you had me play comps to fill out my feature list!” I did, and I’d do it again. A lot of those features are vital. They’ll displace content you want to include but know you can live without. It’s very important to create a complete list before you start pruning.
Content tends to get cut before features. I think that’s the right choice—it’s usually better to have one fewer character and two fewer weapons than to forego your shiny new upgrade system. Features are heavyweights, though, and cutting one can open a ton of breathing room for your game. It’s a personal decision, and it’s hard for me to weigh in as all games are different.
Sometimes one discipline balloons your schedule. If that’s the case, it becomes a little easier to make cuts. If it’s art, can you simplify your environment, or reuse assets? If it’s sound (it probably isn’t), can you simplify your soundscape, or reuse assets? If it’s UI, can you simplify tooltips and menus, or leave out certain customization options?
In the current funding environment, I wouldn’t want to pitch an amateur studio for more than $300k unless you’ve got serious firepower. Feel free to use that as a baseline for budgeting. There are a lot more publishers that can afford you at $100k than $300k though, so seriously, seriously consider if you can make your game for less.
Once you’re done here, you can finally organize your production.
Organizing Production
When organizing your production, you'll want to put features before content. The drifting example from Estimating Features highlights the importance of this decision.
Consider again the way that drifting impacts map and kart design. Do you want to design sixteen courses without drifting, only to find that drifting trivializes them? Do you want to set weight, acceleration, and speed parameters for each kart and bike, only to find that drifting makes bikes irrelevant? You don’t—mainly because you don’t want to have to go back and redesign finished work. To create the best content for your driving mechanics, you’ll finish the mechanics first.
If you add in features early, you don’t have to go through every piece of content to ensure it plays nicely with new features. If you add content before features, you’ll need to double back to everything you’ve worked on and make sure that your new features aren’t disrupting the balance of your characters, maps, and enemies.
In game development, you’ll often hear the terms Alpha and Beta. These are classic development milestones that occur between a game’s inception and its launch. For many studios, Alpha refers to a game that’s “feature-complete,” meaning you’ve knocked out all the unknowns and are now populating the game with new maps, characters, weapons, etc. Beta refers to a game that’s “content-complete” and needs testing, refinement, and bug squashing. There’s a reason this format is industry-standard: it’s important to work on your features before tackling your content.
Prioritizing Features
You know you want to prioritize features before content. But how do you know which features to work on first?
To start, ask yourself these questions:
How does this feature impact my core gameplay?
How much will this feature drive changes to code architecture?
How much work is this feature blocking?
How much will this feature benefit from testing?
In the two examples we’ve looked at so far, you’d want to work on drifting (a mechanic) before Balloon Battle (a game mode). It has a much more substantial impact on core gameplay (Balloon Battle is an auxiliary mode), and it has the potential to drive changes to your code architecture. Balloon Battle is unlikely to be blocking much outstanding work, while drifting is holding up map design.
You can use this logic to drive content prioritization decisions too. If you’re trying to decide whether to design the fifth racetrack or implement bananas as an item, choose bananas. They have a bigger impact on core gameplay, and they’ll really benefit from testing and balancing.
Tackling Dependencies
Some features and content have natural predecessors. They’re “blocked” until their preceding tasks are completed.
I split blockers into two categories: hard and soft blockers.
Hard blockers completely prevent work on a successive task. Consider 3D modeling—you can’t shade and texture a 3D model before you form it.
Soft blockers don’t completely prevent work on successive tasks, but they do make them less efficient. Consider sound design—you can ask your sound designer to create the roar of an alien beast sight unseen, but I guarantee that you’ll get better results if they can see the model in action.
The best production removes as many soft blockers as possible through smart prioritization. Downstream disciplines like art and sound benefit from design and coding work being done first, so try to create patterns in your production schedule where artists follow engineering. It’s not always possible—particularly if you have a ton of heavy-duty features to code—but when you can achieve it, everyone works more efficiently.
Balancing Feature-First Development with Content Needs
You're not always able to cleanly go from features to content if you want to operate an efficient studio. Sometimes you'll need to do some ping-ponging between feature and content work in order to open up opportunities for artists to contribute earlier. Here are the steps I'd take to determine whether I need to bring content work forward in the production plan:
First, figure out how much longer it would take if engineering did all of their big feature work before starting on tasks that unblock art and sound.
Once you’ve isolated heavy-duty feature work, line up the content work by contributor/discipline. Who takes the longest to finish their work?
If it's engineering, then you can safely leave the features-to-content chain intact. Sound/art/VFX will wait for feature work to complete and start building their assets when they're fully unblocked. They'll have a delayed start on your project, which is common--just don't get greedy and start them too late.
If it's someone else, then you need to make sure they get unblocked sooner. This might involve prioritizing level design work that enables artists to work on the models they need for future levels. Engineering can then return to the feature work that you want at the start of a project. Once no one ends later than engineering, you’re in good shape.
Doing the Damn Thing
By this point, you're well-organized and ready to create a polished version of your production schedule. It's time for a Gantt chart.
You’ll benefit from using a project management software to house your production schedule. There are plenty of options. I use Microsoft Project, but you could use something like Trello, Smartsheets, or ClickUp.
If you've followed the steps so far, this part should just be data entry--though with a data set this large, you're bound to uncover new wrinkles as you translate your work into a new app. Follow a tutorial to create a basic Gantt chart in any of these softwares (and really, any of them will do).
When you’re done, your production schedule will look something like this:
You don’t need to submit a Gantt chart alongside your publisher materials, but it’s quite handy to have in your back pocket. Publishers fear that new developers aren’t prepared to create a full game and haven’t thought through their production path. Ease their concerns, and you’ll have a better seat at the table.
This whole process was a prerequisite to budgeting, which is one of the most important steps of post-production. Let's get to that now: Budgeting Overview.
📜 See all articles: Sitemap
Comments