** Originally published on the 12th of January 2016 **
This post is aimed at game development, but its concepts are relevant to every type of development, in every environment.
The first stages in the development of any software are hard. Very hard, actually. So hard, in fact, that a lot of great ideas fail to go beyond the first few stages. You have to conceptualize your idea, write it down on a design document, design the architecture, develop the product, test, deploy... the list goes on. It's no wonder that a lot of products fail to reach the last stage - become a real product, available on the market.
In order to reduce risk, ensure viability of a certain concept or idea, or as a way to see an abstract idea become "real", several best practices have emerged, namely - Minimum Viable Product (MVP), Prototyping and Proof of Concept (PoC). As anyone with any experience in development can attest, these best practices are often used interchangeably, without a clear idea what the differences are between them.
While it may be harmless to be unaware of each practice, it's certainly a good idea to get to know each one, the pros and cons of each one - and most importantly - the goal of each practice.
Let's start by defining each one.
Proof of Concept (PoC)
Wikipedia: "A proof of concept or a proof of principle is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be completed."
Basically, a PoC is the a method used to prove that a feature is feasible. That means - making sure an idea you had in your head, can actually be produced.
In game development terms it means that once you have a concept of a game in your head - your PoC is the first implementation of that idea. A PoC needs to be quick to develop (usually no more than a week or two), short, and doesn't need to include all the features of the final product - you can use placeholders (basic geometry) for graphics, you can completely ignore sounds and special effects (unless those are part of the concept), and so on.
Some of you may be startled by that. How can you create a proof of concept of a working game in a week or two?
By being creative, and working quick and dirty.
Let's say we want to create a 2D platformer that allows the player to turn back time and undo deadly mistakes. A dedicated developer can use this tutorial to create a basic 2D platformer in a day, while also learning something in the process. Now all that developer needs to do for the rest of the week is implement the turn-back-time functionality. And it doesn't need to be pretty - it just needs to work.
A more experienced developer can simply download the source-code for the previous project, and start from there.
Suddenly, it sounds feasible, huh?
Remember - a PoC is meant to prove that something is feasible and the goal is to reach that conclusion as soon as possible: if the concept is not feasible - it's time to abandon it, or rethink it, and move on; if the concept has been proven to be feasible, it's time to abandon the PoC, go back to the drawing board, and start designing the actual product.
Minimum Viable Product (MVP)
According to Wikipedia an MVP is "the product with the highest return on investment versus risk." While it is a nice-looking definition, it requires some explanation to be fully understood. Let's break it down.
The first important word in that definition is the word "product". An MVP is a product. It is not a single feature, or an idea. It is a full-fledged, bug-free (as much as possible), shippable, marketable product.
Reading that last statement you might ask "then what's the difference between an MVP and the final product?" The main difference is the MVP is a subset of the final product. It achieves the products main goal, but gets rid of all the "extra" features that can be added later.
Let's look at a game example. Let's say we're trying to develop a new version of Candy Crush Saga. While the game has a lot of features, it has just one basic feature that MUST exist: the ability to load up a board, and play it by matching 3 tiles together. All of the other features - the map between levels, the interaction with Facebook and friends, the waiting for lives to accumulate, the ability to buy power-ups and so on - are all "extras" - they can be added later.
So, how do you build an MVP?
An MVP is not created by chance. It is created by following a very specific design process - understanding the core features of your product, and writing the code to implement only those features. Once you have those features in place - you can release your product. Sure, it may not be the final version you envisioned, but it's a step towards it.
Prototype
Again, lets start with Wikipedia: "A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from."
A prototype is a stable build of the final product, with the goal of testing or demoing the product. So, if we're trying to build a game - it should be an almost full game. The word "almost" is key here, since we'll be using it in every part of the prototype: the game should have almost all levels; it should have almost all sound effects and music; it should have almost all graphics and graphical effects; the list goes on.
Sure, a prototype is not a finished product, but it should be close enough to the finished product so that other people viewing it can understand what the final product will look like.
When and where to use?
So, now that we know what each concept is, let's see when is best to use each one.
The first stage in (almost) every development is figure out whether your concept is viable. Can your amazing idea actually be realized? Especially - as is the case with many indie developers - when trying a new, innovative idea. That's where PoC comes in.
The first goal: figure out if the idea is viable. Build a quick and dirty PoC, and see if it is. If it is - move to the next step. If not - it's back to the drawing board...
OK, so your amazing concept is viable - now what? The next stage is is your MVP. Your MVP is the heart of your product. It's not a finished product, but it's the gist of it. Your second goal is to figure out what should enter your MVP, and what should be left out, and of course - to actually build it!
There is no actual time-frame for an MVP. It depends on the scale and complexity of the project, but I have yet to see a project where the words "as soon as possible" did not apply.
Once you have your MVP, you've reached a major milestone - you have a product! Yeah, it's not perfect, and it misses some features - but it's there. It can be used.
Now that the product has shipped (and has been accepted by the users, or beta testers), it's time to add more features. It's going to be hard to do that, as now users have started reporting bugs, crashes, and unforeseen problem have risen. Nevertheless, even while working on maintenance for the product - those additional features you've originally designed should be developed.
Your last goal is to get to the prototype stage - to have an almost complete version of your product. It needs to have most of its features, it should be almost bug free, and it should deliver on the intended user experience.
Once that is done - you're in the home stretch. Now is the time to polish the product, add those nagging features you deemed not critical, and be done with the product.
Congratulations - you have shipped a game!
A few last words...
Those best practices are just some of the practices used in software development. We haven't talked about alpha and beta versions, various releases, and much, much more.
However, those 3 practices are a very good basis for good software development, whether in game development, or otherwise.
At this point, it should also be quiet clear that not every piece of code needs to go through every one of these 3 stages. For example, if you're developing a new Mario game - you probably don't need to go through a PoC since Nintendo already did that for you years ago. You know it can be done - just go ahead and do it.
Same with MVP. In some cases, it may be wise to skip the MVP stage and go directly to prototype, or finished product, before shipping. That may depend on business needs, the scale of the project, and - most likely - the amount of money you have in the bank.
I hope this article has clearly defined the difference between these 3 practices, and when to use each one. If you have any questions or anything to add - please comment below, or email me at: shay@newretrostudio.com.
Cheers,
-Shay