📜 See all articles: Sitemap
⬅️ Previous Article: Intro to Pitch Prep
➡️ Next Article: Estimating Content
As you approach the end of vertical slice development, you're faced with a hell of a challenge: draw the rest of the f*cking owl.
To create an accurate budget, you'll need to map out your game's development and figure out how long it will take to make. Mess this part up, and you'll run out of funds before you're 75% of the way through. No pressure, though.
It all starts with a long-term production schedule. A long-term production schedule is your game’s roadmap. It details what you’ll work on, who will work on it, and how long it will all take. It's often in the form of a Gantt chart. It's a bear to assemble, but it pays enormous dividends.
Game development tasks are divided into content and features. To illustrate the difference, let's first think about them as knowns and unknowns.
Knowns and Unknowns
There are two types of tasks you need to plan for in game development (and, probably, life):
Knowns
Unknowns
Knowns are copies of things you’ve made before. Pretend you're an experienced carpenter tasked with making a custom furniture set. Even though the pieces are unique, since you’ve made furniture before, you can figure out how long the set will take to make.
Unknowns are new tasks or projects not tackled before. Pretend you're an experienced carpenter tasked with making a flying carpet. You can't rely on your training here--it's a whole new world.
To put this in video game context, pretend you've made a vertical slice of Mario Kart. In your vertical slice, you’ve created a couple of karts, a couple of characters, AI racers, a racetrack, and a few items. 1-2 people can compete in a classic Mario Kart race.
Your knowns are the characters, courses, karts, and items. While you’re sure to run into challenges balancing turtle shells, bullet bills, and mushrooms, you know what it takes to create items and can roughly estimate how long it will take you to implement each one. The same goes for new characters, karts, wheels, etc.
Your unknowns are expanding Kart to support four players, adding in new modes, creating Grand Prixs, creating and testing different race speeds, and creating the menu system (among many other things I’m glossing over).
A great vertical slice leaves you with more knowns than unknowns because it’s a true representative of your final game. You can multiply it out several times, add complexity, and arrive at a facsimile of your final game.
For games with multiple heavyweight game modes, you’ll end up with quite a few unknowns. Consider the original StarCraft: a real-time strategy game featuring three playable races, a single-player campaign, LAN/online multiplayer, a custom game maker, and online, customizable lobbies. Its vertical slice might only include two-race LAN multiplayer, so there will be plenty of unknowns when it comes to mission design, Battle.net, and the map editor. There’s also a lot of balancing concerns to consider when it comes to implementing the third race.
My guess is that your small team isn’t developing a game as complex as StarCraft (if so, I’ll look forward to playing it in 2045), so you should fall squarely on the side of more knowns than unknowns. Ultimately, it’s better for your pitch if you have more of the knowns figured out. Publishers can easily see where your game is going when the core gameplay loop defines long-term gameplay.
Content and Features
In game development, knowns and unknowns are best described as content and features. Knowns are pieces of content that add variety, depth and substance into your game: another kart, another course, another power-up. Unknowns are features that fundamentally alter or add gameplay elements: an upgrade system, a double-jump, a handbrake.
Let's take a look at an example: a parasail. A parasail feels like content--after all, it's an equippable item for your Kart, and there are plenty to choose from. But whether it's content or feature depends wholly on whether you've built one before:
If it's your first parasail, you have to design a bunch of logic around it, design the first parasail model, and implement it in game. There's a lot to figure out, and it might impact other elements of your game.
If it's your second or later parasail you're simply introducing variety into pre-existing content. There's not as much to figure out, and you should be able to churn out new parasails at a predictable rate.
Once a system is designed, its content becomes, well, content. The system design is the feature.
Content and features have different estimating challenges, so I've broken them into separate articles. Access them here, in this order:
📜 See all articles: Sitemap
Comments