Adventures Of An Accidental Indie Games Developer – 1 – The Minimum Viable Product

Minimum Viable Product is a term that gets banded around a lot, especially in ‘Lean Startup’ circles. It’s not a difficult concept to grasp, and being able to understand, plan and work towards an MVP can make planning and coding your product a much less stressful endeavor.

In this article, I’m going to talk about using MVPs to plan development, and why they rock.


Borrowed from Pando Daily.

Minimally Viable

So, let’s imagine a hypothetical scenario. Let’s imagine that it’s the early 20th century and there’s been a fire in the offices of Henry Ford in Dearborn, Michigan. It couldn’t have come at a worse time. Henry was about to demonstrate his Model T car to the world, which would revolutionize motoring. Sadly, the fire consumed his only prototype and all his blueprints. He’ll have to start from scratch.

What Makes A Car?

So, let’s pretend you’re in Henry Ford’s shoes. You need to reinvent the car that would ultimately shake up manufacturing and transport and you decide to create a minimum viable product. This contains all the features you need to sell, market and demonstrate your product, and no more. So, what do you need?

  • The ability to increase and decrease speed as required, and to traverse obstacles and roads. 
  • A chassis, to keep out rain and to protect the internal components.
  • Somewhere for the driver and any passengers to sit.

This is the minimum viable product of an automobile. All the other cool stuff like heated seats, bluetooth and iPod docking can come later. For now, this is all he needs for him to call his product a car. 

How Does This Relate To Games Development? 

As someone getting into games development for the first time, I’m constantly aware of the need to have an MVP, and to work towards it.

Having a pre-defined minimum viable product is actually the cornerstone of all my planning, as it keeps me conscious of essential features, and allows me to ignore that pesky little voice in my head that asks ‘what if?’. The pesky little voice that, when obeyed, results in distraction from your main objectives, and adding lots of non-core features before you’ve completed the essential facets of the game. 

In retrospect, someone ought to have told the developers of Duke Nukem Forever about this fabulous concept.

What I’m Working Towards

So, I’m working on a game right now. Here’s what my MVP is.

  • My application will be able to parse a JSON file. 
  • That JSON file will then be rendered in the game as a room.
  • The JSON file will contain information relating to a character, and that character will be able to traverse the room.
  • The JSON file will contain information about events, which will be interpreted by the program. These events will be predefined.

And you know what? That’s all I’m going to do. At least initially. I can add the sparkles later. I can make it look prettier once I’ve got core functionality down.

You can’t build a house without foundations.


If I’ve piqued your curiosity and you want to read more about lean concepts, I can’t recommend The Lean Startup enough. It’s a fabulous read.

Enjoy This Blog Post?

You should subscribe. Pop your email in the box in the sidebar and you’ll get an email whenever I write a new post.

About Matthew Hughes

Matthew Hughes is a software developer, student and freelance writer from Liverpool, England. He is seldom found without a cup of strong black coffee in his hand and absolutely adores his Macbook Pro and his camera. You should follow him at @matthewhughes.


  1. I have tried to stress this when working on software projects, but too frequently the client will get wrapped up in “what would be neat is…” software creep. Thanks for the post and the reading suggestion. Perhaps I can steer future clients here or at least use the Henry Ford example to steer the ship that is software development.

  2. MVP is important.

    One thing I’d say to beware of in terms of scope creep is “traverse the room”. Nail that specification DOWN!

    – How is the camera attached to the avatar? 1st person? 3rd? Is changing camera position MVP, or can you just view the room from a stationary camera?

    – Do you wish to stop walking when you come against a wall? Is collision detection against walls MVP?

    – Do you wish to have differing floor levels? Are ramps (=floor collision), steps (=max-step-height complexity to collision detection), jumpable obstacles (=gravity, fall rate, a jump key, etc) MVP?

    – Do you wish to have differing ceiling levels lower than the height of the player? Are sloping ceilings (= collision detection with head, auto-crouch), air ducts (=crouching), MVP?

    – Avoiding the previous two means much simpler 2D map collision, where any wall is considered collidable.

    Full mouse+WASD+jump+crouch control is non-trivial. I’d recommend stationary top-down camera, flat floors, vertical full-height walls, no jump or crouch as MVP, but that’s just me.

  3. Hey Matthew, I think an MVP is a great place to start; I wish more people started there.

    Having said that, thinking about your case specifically, I’d reiterate that the purpose of an MVP is to gain feedback from your customer.

    In your instance, your customer is the University/your tutor.

    Your customer has already told you what they want. And, correct me if Im wrong, but the “feedback” you’ll get will be when they mark your finished project, correct? So it may be that you can actually stretch what your MVP will contain because you haven’t really got a feedback loop (in the truest sense) – you’ve only got one chance to impress, so it’s probably in your best interests to deliver more than a true MVP would so that you can get a better grade!

    Having said that, if there are multiple times throughout the course when feedback will be given on what you’re building, then keep on the course you’re on and build new stuff based on your customer’s actual feedback rather than what you think they’ll want.

    Bon chance!

Leave a Reply