The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
This time I would like to write about the concept of Minimum Viable Product and what it means in the context of Epic Owl’s game production. This topic was inspired by my recent debate in Twitter with Game Design Guru Warren Spector who read Risto’s latest design article (Part 6
) and commented that he thinks releasing MVPs show contempt for the audience. Needless to say, I had to comment on that and explain why I think MVP is an important tool for any game developer and has nothing to do with contempt.
More than anything, I see MVP as a mindset, a way to recognise what is important in the game and what is not, a way to tighten the focus. If you’re not focused, you are more likely to end up with a game that tries to do too much and face the danger of doing nothing very well.
I can clearly see the Warren’s point on how MVP can be done wrong and Minimum Viable Product is an excuse for the earliest possible mess that can be called a game. I think the biggest difference between the way Warren thinks and the way I think is that I define myself what the MVP means for me. If I respect the player, so will the MVP be respectful. Every release for us at Epic Owl is a complete high-quality package and we define it by the feature set in the scope, not by cutting the quality.
In addition to keeping the scope tighter, I also believe any piece of software, be it a game or something else, should be put into real use as soon as possible to get the real feedback from the real users and have the possibility to revise the design and see what is not working. By getting feedback and iterating we end up with the game the players want. Everybody wins.
How to go about defining your MVP:
As mentioned in one of my earlier articles, at Epic Owl it’s me and Risto (CCO of Epic Owl) who balance the design, the scope and the schedule together. Risto is responsible for the design, I’m responsible for the schedule and we meet at the scope. Our discussion is often around MVP – A version of the game that we can get out as early as possible, fulfilling its purpose as a game, i.e. fun and entertaining, engaging and retaining.
Defining your MVP comes down to prioritization, as always. Identify all of the must-have features you haven’t implemented yet. Then identify the nice-to-have features. The rest – just put them in the backlog, you won’t be having time for them. Prioritize the features within each category and put them in order. Estimate roughly how long each task takes.
Then start fighting with your designer (or producer, depending on which one you are yourself) on where you should draw the line. See yourself as the player playing the game with the features above the line. See also the feasible time-frame you have for the implementation. Try to form a logical package. Use your common sense. Use your common sense again. Tell your designer (or producer, depending on which one you are yourself) to use his/her common sense. Tell him/her you are running out of time and you just need to release it at some point. Take a break. Continue the next day.
At the end, you will have your Minimum (Producer) Viable (Designer) Product (Game) defined.
Let’s take a look at our first game which is at soft launch as we speak:
First version we released was little more than the core game, fun in itself for us and our testers but we needed to see if it was fun also for the general public. Wouldn’t have made any sense developing the game further if the core didn’t work so we soft-launched the Core in Canada and Indonesia. As it happened, our analytics showed that the core was enjoyed very much by the audience and it made total sense to move forward.
After a few weeks we launched the first update. From the initial launch we had identified some pain points and we already fixed the biggest ones here. This version was much better than the first one but wouldn’t have been unless we had launched the first version and gotten the data.
The second update we are about to submit any day now. It is a significant update, adding a couple of major features, half-a-dozen-or-so smaller ones and lots of fixes. The difference between the first version and the third one is huge. But without launching the earlier ones, we couldn’t have identified the holes in the design and couldn’t possibly have made the great version we’re now about to submit.
We still have one update to go before our global launch. Each update is taking us closer to the perfect game. We could have taken all this time without making any soft launch releases, just working the existing feature backlog. We would have a game, yes, but what kind of a game? Possibly a good one. But very less likely a great game that we already can see ours to be.
And hey, it doesn’t end in global launch. We will continue the development, iterating, getting feedback from the players, implementing features that are requested. Update by update, MVP by MVP.
MVP is a useful tool to have in your game development tool case but as always, you need to bear in mind what you want to achieve with it. As a rule, it’s always makes sense to review your processes from time to time and verify they serve their purpose. Otherwise you face the danger of spending your time doing things that take you further from your goal (The Perfect Game) rather than taking you closer to it. MVP is no different – make sure you do it to take you to your goal, not as an excuse to release crap.
I’d like to thank Warren Spector for taking the time to read and respond to our blog and for the inspiration for this piece of writing. It’s always good to be challenged and have the opportunity to see your processes from the eyes of another and reflect upon them. Thanks a lot! And thanks everybody for reading, as always, comments and feedback are very welcome.
P.S. If you happen to be in Canada
, the game I’m talking about is available HERE