The Indie Expedition
Stage 2 - Building an MVP
Stage 1 is complete, and that means you’re ready to build something.
This is a scary and an exciting time all at once. This is the time your idea starts to come to life. It moves off the page into a product. Your ideas? They mean something now. “Oh wow wouldn’t it be cool if I had 12 types of hero to play as” suddenly means building not only 12 types of hero, but a way to switch between them. There’s a lot of work in some of those ideas and you’re going to make big decisions.
You need to think about whether you build a specific component or system at all. And if you do, how deep is it. You need to get incredibly specific. What does “combat” mean? Is it melee, is it ranged? Is it dots or single damage on impact? Does Line of sight need to matter? Do bullets and projectiles need travel time? And once you settle on those, what does it really need right now? Do you need animations? Can the same half crouch animation precede a fireball and a sword swing?
But it’s also the most magical time. Now it’s time to create. You’re making a game. Remember that.
So, let’s dig in and build you an MVP.
Congratulate yourself
The Indie Expedition is all about milestones. And accountability. But we’re also here for celebration. So, you’ve earned a new badge. Your planning is completed.
You’re building an MVP.
Feel free to post your new announcement on your own socials, or in the Indie Expedition chat. Grab your badge to the left.
“I’ve finished my game planning from the #IndieExpedition and now I’m building an MVP. I’m releasing a game this year.”
Section 1: What is an MVP?
An MVP is the minimum viable product for your game. In short it’s the simplest version of your game. But it needs to be YOUR game. If you’re building an RPG set on the dark side of the moon, it’s not much good to start with an MVP filled with wild west props a template came with. So let’s break down the pieces and get you building.
Minimum: It's not just a word, it's a philosophy
Everything in your MVP needs to be reduced. DOWN. Down further. Have you got it in mind? Good, reduce it.
We’re talking about the minimum, the bare minimum required to count. You’re going for depth, and systems foundations, and as many of them as possible.
If your game hinges around a weapon switching mechanic. Make two. Two is the minimum number of things needed to be able to switch.
If you’re focused on procedural maps and variety? Make a map that’s 3 tiles long and switch the pieces between straight hallways and crossroads. Randomly generated maps entirely? Build a 3×3 grid and move the end room to a new place.
Two guns doesn’t mean two gun models and two different shooting methods. You can tweak scatter, range, projectile size later. A red shotgun and a blue shotgun.
You can finish some of these systems in your MVP. If you have time. Your focus for 5 weeks is to build the foundation of all of your systems.
Viable: It's functional, not fancy. Finish the game loop.
Your end result needs to be viable. It needs to work. It needs to get me into the right groove for your game and no one elses.
If it’s a shooter, let me aim, let me shoot, let me pick targets. If it’s a puzzle game, then give me clues and let me solve a puzzle.
The simplest question to ask at this stage is whether someone can play your game? But not a random stranger. Someone under your direction.
Your MVP doesn’t have beginner levels, there’s no tutorials, NPCs repeat themselves, every vehicle probably makes the same noise, the map is undecorated.
Spend your time and your focus on the pieces that matter. But the pieces you focus on need to work.
The original Tomb Raider for Playstation had a gymnastics room in the mansion. Which let Lara jump, dive, climb, swim in a tiny pool, shoot at a target.
Product: It does it's job, and it does it well
Remember that you are building a product. A product has users. A user has needs.
As you build your MVP, think of your users. Complete the user document below.
We’re not digging deep into anything like demographics, or personas. You don’t need to think about different playstyles (and likely should not during the Expedition). But you should think about the end user who is playing your game.
What does your user need? How do they launch the game? How do they save progress? How do they exit? Can they mute it? Is there music they need to disable? Do they have subtitles to turn on and off? Are there points in your game that need an exact thing to happen? Is there any way a player can get trapped and stuck?
Make your product work. Make it meet your users needs.
And that’s the basics. That’s how I want you to think while you build your MVP.
You need to move fast, you’ve only got 5 weeks. And you’re going to build the foundation of all of your systems.
Ideally, you will build in stages. Build the bare minimum for your first system. Move onto building a level. When it’s the bare minimum, build the basics of a quest log. Then a single NPC with one function. Now start over. Expand the first system. Etc
If you keep your game viable at each phase of the MVP stage you’ll get yourself in a fantastic position to finish it.
You’re bound to run into issues in your MVP. Maybe some of your plan is harder than imagined, maybe some of it doesn’t seem fun. Maybe it seemed simple and will now take significantly longer. So it’s time to make tough decisions. Is this critical to your game? Do you cut other things to make this happen? Or change this to save the rest?
MVP Basics
Focus on the core loop
Identify the core mechanics from your Game Summary and focus on those. Build the essentials first before considering other elements.
For Overwatch? A single map, push the payload.
Reduce Scope
Cut out the flashy extras. Trim your content list down to what is needed. And really think about what’s needed. Every room in the dungeon could award a chest with a single red gem in it.
For Angry Birds? Just two bird types.
Ensure Functionality
If it’s in, it needs to be in. Anything you include must be functional. Crafting system made it in for MVP? Then let me craft. If there’s a lock system, it had better let me open doors with it.
For Pitfall? Vines work. Gators kill me.
Test and Play
No one else’s hands are going to be on this but yours. But you need to make sure yours are. You need to drive, shoot, swipe, gather gems, hammer boards together.
For space invaders? Go invade some space.
Usable Menus
You need to let people launch, save, choose, and exit again. Build those foundational menus and have them in place ready to fill with more.
For… Look Im not explaining what a menu is.
Save and Resume
Think of both sides of the coin. If you save data, then you need to retrieve it. If you’re letting people save their progress, make it happen. Store which levels are solved.
For Candy Crush? Have I finished level 6 or not?
Polish the feel
Feelings, not visuals. Focus on how it plays. How quickly does something pop up when I click it. How tight can I turn corners, how well can I control where jumps land? Does shooting a gun have a little kickback, or is it impossible to control?
For Quake 3: Can I snipe someone mid jump?
Balance Simplicity with depth
Your MVP is pretty trimmed down, so balance your short list to hint at the full potential. Include variety wherever you can.
If you only have time for 2 enemies? Don’t make them both “snow guys”.
For WC3: Goblin Zeppelins and Human Knights.
Prioritize clarity
The player should know what to do at all times. Your MVP is short and sharp, you don’t add depth by hiding the content away where someone can’t see it. Make it easy for people to know what to do, so they can get in and do it.
For Resident Evil: Red key goes in red door.
Example - RPG MVP
So you’re making an RPG (a role playing game, not a rocket propelled grenade. Although an RPG with and RPG in it would make for something unique) for your Indie Expedition and have decided not to use a large template. But you will be using a movement controller, and an inventory system.
First pass for your MVP is making a terrain. You keep it simple and small, 512x512m. You apply a stamp to add some little tiny hills and bumps. You add a mountain in one corner for visual interest. And a river with the “set height” brush. 20 mins work. Then you drop down 4 towns to visit. Prefabbed houses. The same 3 houses for every town. Quickly paint in some roads. And it’s done. You’ve got locations to visit. You palette swap the houses so each town is a different colour.
Now you can bring in your movement controller. A quick import, assign the inputs. And it feels good. Default movement speed, camera follow all suits your world. It’s done.
Time to grab that inventory system. A quick read of the docs. Some config to manage. Bank, personal inventory, house. Looks like they all live on the same InventoryManager. You think a little and check your docs. It’s a single player game. It doesn’t matter where the Bank Inventory lives. The player can only open it when you call OpenInventory[2]. So there’s no issue. You set up some basic sizes. Maybe they need to get balanced now. But you settle on 12 slots for you, 30 for your bank, and 100 for home. The home inventory only opens in a single place, so its more generous to allow for those limits.
Now you need a simple quest system. So you start coding it. A master list of quests in one location. And a list of ints on the players quest log to track what they have.
Whoops, you collected the same quest twice. Better add in a way to prevent that. And while you’re writing that method, you decide to add a date time on the master quest list, and a boolean for completed.
There’s a lot of way to issue quests to players, so you decide a button will do for now. You build a small helper for quests in worldspace. Buttons on signs, bulletin boards, floating in front of NPCs. It works. Easy done.
Because you still need to build a way to complete quests. To check priorities. You need some basic combat, ways to pick up loot (the inventory system brings this for you).
You’re focused on your MVP being viable. So you move on to the next task. Nothing is completed. But everything works. You’re making an RPG. You’re launching on December 1st.
Example 2 - Puzzle MVP
You’re making a puzzle game for your Indie Expedition. You’ve decided you don’t want to use a template or kit, no prebuilt assets. You’ve got some specific things in mind. You’ve made up your mind. The way these things work is more important to your vision than the amount of content.
You’ve come up with a brand new game concept, and it’s go time.
You realise there’s no time or need for a level editor at this point in time. You can manually build a few levels. You get started on the basic mechanics. You build a framework to support the game field. An update method to check on “change” for dirty cells and updating them. You’re not building everything for MVP, but you realise from the start efficiency matters a lot. If you only check cells that need change, you can build bigger maps. The actual size? Who knows. You’ll decipher that later when you do more testing.
Maybe performance will set the size limit. Maybe it’s gameplay. Do 300 cells of a puzzle game make it more exciting, or too hard to follow? Hexic uses bigger fields than Candy Crush. But operates at a larger scale as you make moves.
You finish your core system and build a single mechanic. It works. It flows. You set up some simple variants. Finish X count to win. Destroy all the blue blocks. Finish before a timer is up. It’s all variations of the mechanic, just measured in a different way.
Oh wow, you have an idea, what if the timer levels were slowly filling up with water? You add it to your notes and park it. That’s just a visualisation of a clock. What if it fills up and you can remove some water? That’s just a clock that lets you add or remove time. You make some diagrams. And get back to your MVP.
You clone the first level, make 3 copies. Change things up a little.
Next up you make clones of all 4 levels. Change them up a little more. But basically it’s the same 4 levels over and over 20 levels. It gives you 20 levels though. You work on the map system to let people level select.
You’re halfway through your MVP window. It’s time to add more.
Do you add a second mechanic? If you do, will it need more levels specific to it?
Can you add more levels instead using the original mechanic? You decide not to edit the existing levels. They work just fine. Why spend time redoing that work. You decide to work on gate mechanics. You hide part of the map. You create a simple animation system to play animations and expose the rest of the map. You’ve just added excitement, milestones and progression to your MVP.
Sound would be nice, but it doesn’t change things that much. You decide visual appeal matters more. You build a UI particle system to play over your puzzle game when combos are made. There’s a dozen things it needs to do better, differently. But instead you focus on matching the colours. It’s the simplest win with the most impact.
You get to the finish line of your MVP with working menus, a full progression system and 40 levels for people to play. You’re all set to build level design tools and new mechanics later, but you’ve proven the core of the game. It’s your game. It’s ready to expand.
So go build it.
It’s time to begin. So let’s go.
Share your announcement in the Discord and jump in with your peers.
Think about what you’re doing, and focus on the MVP plan in your game summary.