📜 See all articles: Sitemap
⬅️ Previous Article: Prepping for Full Production
➡️ Next Article: Estimating Features
In the previous article, we talked about the difference between content and features. Content is the easier of the two to estimate, so let's start there.
Content is based on knowns. A task is content if you've already created a similar type of asset at least once. After your vertical slice, you have a baseline understanding of what it takes to develop a new piece of content, whether it's a level, a boss, a weapon, or a character.
A large portion of game development is content generation, because your full game is in many ways a multiple of your vertical slice. If you have one level, you might need to build four more. If you have three enemy types, you might need to design seven more. You can therefore start with your vertical slice and multiply it in order to figure out your content needs.
Multiplying Your Vertical Slice
Let’s stick with the Mario Kart example from the last article as we go from vertical slice to full game. I’m going to list out the content included in your vertical slice alongside the content expected in the full game.
Content | Vertical Slice | Full Game |
|---|---|---|
Characters | 2 (Mario, Peach) | 12 |
Courses | 1 (Dry Dry Desert) | 16 |
Items | 4 (Mushroom, Green Shell, Red Shell, Banana) | 6 (Bullet Bill, Fake Item Box, Star, Blue Shell, Lightning, Golden Mushroom) |
Karts | 4 | 20 |
Wheels | 2 | 12 |
This is an easy way to visualize how much content work we'll need to do before the game is complete. Next, let's drill into one of the categories.
Breaking Down a Category
Let’s pick a course as our example. For each course, we might come up with the following list of requirements:
Task | Discipline | Size | Instances |
|---|---|---|---|
Design course layout | Design | 8 | 1 |
Create world (sky, lighting, ground) | 3D Art | 13 | 1 |
Create large 3D structures | 3D Art | 21 | 1 |
Create racetrack | 3D Art | 13 | 1 |
Generate each environmental prop | 3D Art | 3 | 12 |
Create obstacle | 3D Art | 3 | 8 |
Add item boxes/boosters | Coding | 13 | 1 |
Game implementation | Coding | 13 | 1 |
Generate minimap | UI | 5 | 1 |
Others | All--consider sound |
To size these tasks, it can be beneficial to return to past sprints. If you've kept good records (typically via the backlog) and kept notes from your sprint retrospectives, you'll be able to estimate these tasks with some accuracy. If not, you should be able to break down each task (remember: you've done this before) and size it accordingly.
Estimating Total Time
We can now determine how much effort it will take each discipline to construct a new course:
Discipline | Size per course | Total Courses | Effort points spent working on courses |
|---|---|---|---|
Design | 8 | 16 | 128 |
3D Art | 53 | 16 | 848 |
Coding | 26 | 16 | 416 |
UI | 5 | 16 | 80 |
The numbers in the fourth column don’t tell me a lot on their own. 848 sounds like a lot, but how much is it really? We can break this down pretty easily. We just need to know:
How many points of work can someone pick up each sprint? (Example: 21)
How many team members do we have in each discipline? (Example: 3 artists, 2 coders, 1 designer, 1 UI dev)
Now we can work out how long it will take to develop each stage:
Discipline | Contributors | Total Points of Work | Work per sprint | Total Sprints | Total Time (mths) |
|---|---|---|---|---|---|
Design | 1 | 128 | 21 | 6 | 2.8 |
3D Art | 3 | 848 | 21 | 14 | 6.5 |
Coding | 2 | 416 | 21 | 10 | 4.6 |
UI | 1 | 80 | 21 | 4 | 1.8 |
You can alternatively skip sizing and approach estimating from a time standpoint. For example, your artist may be able to tell you that it will take them about half a day to generate each environmental prop and about two weeks to create a full racetrack.
This is an easier approach if your team isn’t used to talking in terms of sizes. And it’s a perfectly valid way to approach planning. Just be careful to create padding, because most people estimate a task with optimism. They believe they’ll get it right the first time. Your job, as the estimator, is to estimate with realism.
There’s a reason I’m not using pessimism here. I’m not saying you should assume everything will go wrong. I’m saying that you should assume that your team will learn and grow along the way, and that this will lead to revisions that make your game better—and ultimately that lengthen the production schedule. You also need to have built-in time for testing and bug fixing across all disciplines.
I like realism because it acknowledges that revision and bug fixing is part of the creative process, not a failure of the creative process.
Content is the easier of the two to estimate, because it's based on known factors. Features are a lot harder. Read about how to estimate them here: Estimating Features.
📜 See all articles: Sitemap
Comments