Minimum Viable Product and You

Fairly often when I am either working alone or with a team, well after designing all of the mechanics and gameplay content. We slowly develop and chip away at the mountain without doing something very important… playing the game! Over the couple years of game development I have been involved with, the one thing I wish I learned to do sooner was bashing broken systems together to get an idea of how the game is meant to play.

Some of you might be asking, “What’s the point of that? The systems aren’t fully finished and they will break at some point.” and I hear you loud and clear. I even used to think that way until one day my team and I had to have a presentable product by the end of the week. So naturally with a sudden deadline, we cared a lot less of how well the systems worked and more about how the game played. The things we learned about our level design ideologies, game mechanics, and possible user experience issues can not be put into words. This moment converted me from someone who wanted to have the perfect lego piece done to it’s going to be broken and ugly anyway, let us see what we got!

Now, some of you might be doubting me here still. So let me bring in a bigger example of why this is so important. I’m sure most of you have heard or played Ori and the Blind Forest. A wonderful platformer that combined fluid movement mechanics, beautiful art, and a memorizing soundtrack. I could write a full analysis of the game (and thinking about it, I just might in the future), however let us bring it back to those fluid mechanics.

Above you can see just how fluid the movements of the player are. The controls of the game are incredibly well polished and naturally it didn’t start that way. This is after hundreds and hundreds of hours to polish and create the experience. The next video, is a sample of how it looked well before that.

Your minimum viable product doesn’t have to look nice. It doesn’t have to have the most fluid of movement. It just needs to provide a platform for you to test weaknesses in your design in order to improve it. If you wait till all the systems are made and then put all the pieces together, you’re going to painfully find out that sometimes systems don’t like each other. It might result in gameplay being incredibly dull because your in-game mechanics sound very different on paper, but turn out they do the exact same thing in game.

Another reason why I like rushing to that early prototype of my game is it becomes something that you can show off immediately. Doing that means you’re leagues ahead of other people who will often make something and not show it off or not even finish it.

I hope this provided a good understanding of why it’s important to get that sample of how your gameplay will work. As brought up a couple weeks ago, it might mean you fail but as long as you improve from it, that is all that matters. Go forth, create, and then break those creations to make them stronger.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s