Estimating Features

📜 See all articles: Sitemap

⬅️ Previous Article: Estimating Content

➡️ Next Article: Assembling Your Production Schedule

It’s much harder to size new features than it is new content. New features are frontiers, and developing them requires thought, research, and experimentation. They also tend to add complexity to the whole project, requiring you to adjust code you once thought was complete.

To explore feature estimation, let's return to Mario Kart, this time to develop a new game mode: Balloon Battle.

Starting Simple: Balloon Battle

For those of you who haven't dabbled in extracurricular Mario Kart modes, Balloon Battle is a competitive mode where players aim to pop their opponents’ balloons by hitting them with items. Balloon Battle requires a lot of content work (knowns) and a digestible amount of feature work (unknowns), so it’s a good starting example.

What can we draw from our vertical slice experience, where we created a typical Mario Kart racetrack?

• We know how to create maps, items, boosts, karts, and racers.

• We've setup basic UI to track items held and a minimap.

• We can handle collision between karts.

What’s new?

• We need to treat balloons as player lives and eliminate players when all balloons are popped.

• We have different goals for map design, so we’ll need to spend a bit of time on map design philosophy.

• We have to create this mode and implement it into the game.

From Estimating Content, we know how to size the first three bullet points. To size the next three, let’s ask some questions:

• What feature have we worked on in the vertical slice that’s comparable to balloons as lives? What can we compare game mode implementation to?

• How much time did we spend tinkering with map design for our vertical slice, and how much time do we want to allow for experimentation here?

Based on the answers to these questions and input from your team, you decide a life system is pretty straightforward to implement—you call it an 8 to be safe. Since this is a brand new mode, and we want it to be impactful, we’re going to dedicate a full sprint’s work of design work (21 points) to designing and testing the first Balloon Battle map (this includes work like identifying and setting up spawn points). Finally, it took our UI developer about a month to create the menu system and coding logic to navigate the game and load our racetrack. They’re reusing a lot of those menus and scripts for Balloon Battle, so they think they can do it in about half the time—call it two weeks, or one sprint.

So in order to create a working prototype of Balloon Battle, we’ll need to do the following new work:

Task	Discipline	Size
Implement balloon lives	Coding	13
Design/test initial map	Design	21
Add Balloon Battle into game	UI	21

On top of that, we’ll need to do some content work (these line items are pulled directly from Estimating Content):

Task	Discipline	Size	Instances
Create world (sky, lighting, ground)	3D Art	13	1
Create large 3D structures	3D Art	21	1
Generate each environmental prop (note: we’ll also say the balloons are a 3)	3D Art	3	6
Create obstacle	3D Art	3	6
Add item boxes/boosters	Coding	13	1
Generate minimap	UI	5	1

Add it all up, and you get the total amount of work it will take to generate your Balloon Battle prototype.

Getting More Advanced: Drifting

Balloon Battle is actually pretty simple as far as features goes. It’s a standalone game mode, and while you might balance some items differently in it, it’s unlikely to affect the racing mode you’ve already spun up. Not all features get packaged so neatly.

Now imagine that you haven’t implemented drifting into Mario Kart yet. Drifting’s a thorny feature, because it heavily impacts map design. It allows for very tight turns, and if you want to reward your players for their skill, you’ll create maps that complement exceptional drifting skill. Drifting also differs between bikes and karts, so you might find its implementation changes the way you handle acceleration and weight for both types of karts.

We can look at drifting and immediately see the art work that needs to be done: VFX particles that indicate the level of drift, and sound effects for when the drift starts and ends. The coding work is less clear, because the degree of work depends heavily on how easy it will be to slot a new turning mechanic into your existing code architecture. It may be easy to create a drifting method that changes a few variables, or it may be a complete pain in the ass, requiring you to check and manipulate variables across a bunch of different scripts.

If you didn’t write the to-be-affected code, your first step is to talk to the person that did. Spend time talking through what changes will need to be made to support a drifting mechanic. Be exhaustive in your conversation. This is a vital planning stage, where a mistake can lead to missed deadlines, a project setback, and a disruption to overall production. Don’t let it happen. Be thorough.

By the end of this conversation, you need to come up with a number, whether it’s time or points (size). How long will it take to implement the feature, and how much time do you want to allot for testing and bug fixing?

As always, the more you can break down the feature, the more accurate your estimate will be. This breakdown, research, and estimation often requires sprint work. Rather than reiterating estimation tactics for challenging problems, I'll point you to Estimating (scroll down to Tackling Advanced Ambiguity).

Now that you're familiar with estimating both features and content, it's time to put it all together and discover your game's full scope. Read on here: Assembling Your Production Schedule.

📜 See all articles: Sitemap