Imagine an extremely creative game developer sitting in his room, sipping on a nice hot cup of coffee while trying to come up with the concept for a revolutionary new shooter. He sees the market, examines the existing products and comes up with the idea for a new arena shooter. An FPS that combines the fast-paced nature of Quake with the strategic aspect of Rainbow 6 Siege. Characters with unique abilities that provide tactical advantages, a map that encourages fast-paced action, and awesome gunplay. In the developer’s mind, it is going to be a revolutionary FPS, changing the way people look at this genre. He approaches a publisher; they spend a ton of time and money developing this project and filling it up with literally every feature they can think of. They over-engineer the game, trying to make it as forward-looking as possible. In an effort to match the creator’s vision, the team decides to shoot past the initial launch date. They believe that the end result will be worth the wait.
Fast forward to launch week. Everyone in the team is looking forward to seeing sales rise through the roof. However, the game is a total flop because players don’t like what it has to offer. The developers spent a ton of time and money creating the solution to a problem that nobody cared about. What went wrong here? Our imaginary team of developers made a few assumptions. They assumed the new game would stand out from the rest of the shooters by delivering unique gameplay. They assumed that there is a need for such a shooter, and people will want to play it. They assumed that their game was better designed than the competition. Prior to launching the game, they had no way to objectively prove that these assumptions are true. Instead, what they could have done is come up with a testbed for their ideas prior to launching the fully-featured version. Or in other words, they could’ve designed a Minimum Viable Product to prove/disprove their theories.
Top 20 MS-DOS Games That You Must Play
- It must have a minimum amount of value required for people to buy it in the beginning.
- It must promise buyers that it has enough future benefits, so they don’t walk away (this part is important to retain early adopters).
- It must have a feedback system built in to provide user data for future refinement of the product.
What Are The Benefits Of Creating An MVP?
You get to test the game in a real-world scenario. No matter how much internal testing you do within the company, a real market involves many things different factors such as competition, trending genres, and economy. These cannot be replicated through testing, so you must put a build of the game in the market to evaluate its performance with actual players. The MVP system helps build an iterative cycle wherein the product is released, tested, and then improved through future developmental phases.
Another benefit of having a minimum viable product is that you get to focus on what is truly important, i.e. the key features of your game. We would all like to stuff in as many features as we possibly can, but that wouldn’t make the game better or more playable. Instead, it might even make your game bloated and undesirable at the cost of more development time and higher budgets. A minimum viable product will allow you to focus on the features that a player truly needs, and create a nice base on top of which you can build further incremental improvements over time depending on the feedback received from players. It allows your team to understand where the true value of a game lies, and focus on improving that instead of chasing after features that nobody wants.
Talking of teams chasing after unnecessary features, by creating a minimum viable product you’re also going reduce the time it takes to create your game. And the costs as well. Why spend so much time and money on something whose market success you can’t even prove just yet? Sure, you might think it is the best invention since sliced bread, but actual players might not feel as excited about it. And if the game bombs early on release, you at least have a choice. You can either spend more resources on further development or kill the project right then and there. Finally, by using a minimum viable product model you can shift your development team from using a linear process to a more agile development process. First, you think of a new feature, then you prototype it by releasing a minimum viable version, then you collect feedback to fuel some more thinking. Think > Prototype > Test, collect feedback, and repeat. The more you repeat this iterative loop, the better your game will become over time.
Know What Your Players Need
Whenever we create a new game, there should be a designated market segment we’re trying to connect with. For example, if you’re building just another 2D platformer there is no reason for it to perform any better than hundreds of similar games that already exist. But if you read reviews on forums and survey potential players on social media about what they want, you’ll be able to build something unique. Not just unique, but serving a segment of players who want to play a game such as yours. Releasing a new product into an oversaturated market won’t work unless there is a demand for it. So first things first, do your homework and make sure you’re building something that people need.
Analyze The Competition
Does anyone remember the disaster that was Lawbreakers? The creators for that game were completely convinced that their product is unique, and claimed it delivers a shooter experience like no other. They promised a gravity-defying, adrenaline pumping, fast-paced arena shooter. With highly stylized artwork and unique characters for you to control. Except… Overwatch had already done that. And it came first. And it was a much more refined game with lots of content to keep players attracted. Lawbreakers were simply another overhyped drop in the bucket, a game that nobody wanted. If only they researched better and saw what Blizzard was cooking up with Overwatch, maybe they could have avoided this disaster. Analyze your competitors by checking search traffic, download figures, monthly active users, etc. and compare the core features of their game with that of yours. See too much similarity between the two? In that case, you need to make radical changes. As a startup, you don’t have the media presence or budget to compete in the same space with a much larger dev.
Build A Priority List
The goal with a Minimum Viable Product is to focus on delivering a game experience that contains all the core features of your game without any extras. Developing a horror survival game? Your MVP should be the first level, set in one small part of the ghost town. Maybe an abandoned mental hospital, the character just has a night vision camera and a pistol. Sure, your full game will explore other parts of the city like the police station, community park, burial grounds, etc. But for now, this is enough. The player will unlock more weapons in the finished game, like a shotgun, a chainsaw, a sniper rifle, etc. But those things only add to the feature set of your game. They don’t fundamentally change the core gameplay loop or the rules by which the game is played.
As a developer, you need to know when to say “NO”. Keep the MVP short and simple, to reduce production costs and development time. We need to focus on the “V” in MVP- Viable. It has to be viable for your company to produce, and that’s what we’re trying to test by analyzing player feedback. There is a great technique used by developers to set up a priority list or descending hierarchy of features. It is called the “MoSCoW” method. Short for “Must-Haves, Should Haves, Could Haves, Would Haves”. Must > Should > Could > Would. When building an MVP, all you need is the “Must Have” features.
What Problem Does Your Game Solve?
Often times we notice developers going into a game project with a certain idea in mind, then losing focus midway. Let’s take an imaginary game company, “Nimbus Studio”. The lead designer at Nimbus came up with a new concept for an arcade-style racing game based around old Need For Speed titles like Most Wanted and Underground. He wants to create an underground themed racing game where you take regular street cars and mod them into monstrous racing machines. They did the market research and concluded that there is a demand for such a game based on polls and surveys. Halfway through the creation of their very first prototype, chaos breaks out within the team. One guy decides that vehicle customization should be more comprehensive and realistic, like racing simulation games. Another guy demands that they should focus on racing, and cut back on the story as much as possible. And then there is another dev who wants to see 50 cars in the prototype, but this would significantly increase development expenditure and time.
You see, everyone got caught up in their own ideas of how the game should be designed. They all forgot about the problem they were trying to solve in the beginning. To create a good MVP, you don’t go with what you want to build. Instead, you go with what the people NEED. And what the people need isn’t based on your personal opinions, but derived from reviews, social media polls, customer interest, market trends, etc. Sometimes, the product you initially envisioned isn’t the most viable solution from an economic standpoint. Remember- statistics over emotions, player data over personal preferences. Your new game is designed to solve a certain problem, to fill a specific void in the market.
Simplicity Is Key
Once you’ve identified a problem to solve with your game, you need to go about it in the most efficient manner possible. Creating an MVP should be a swift task, but sometimes devs will complicate the process far too much and end up with a convoluted mess. You might enjoy adding in little details here and there, mapping out elaborate storylines and creating complex characters. But to be honest, all that is unnecessary at this point in your game’s development stage.
Sure, it is really cool from the player’s perspective as they get to enjoy a well-rounded, immersive experience. But you see, developing a game takes time and money when you are doing it professionally. And most companies have limited amounts of those resources. Even if you manage to build the perfect game that matches your creative vision, people may not play it. You can’t predict how the general population will react to a certain idea, even if you think it is super cool. So you identify the problem you’re trying to solve, the segment of the market your game is targeted at. And you ask yourself “what do the players really need?”. Launch your MVP with just enough functionality to test out three things- does a demand exist, is it significant enough to commit resources, and can we solve this demand?
Efficiency Isn’t Needed (For Now)
Any successful game needs to be efficient and scalable so it can grow into the future. However, you’re building a minimum viable product to test the waters right now. Not a finished game, so you can throw efficiency out of the window in favor of core functionality and reduced development time. Test out your fundamental assumptions, see if a certain theory is viable. Collect feedback from early players and decide exactly how much potential there is for a fully fleshed-out version of your prototype game.
Build, Measure, And Learn
The MVP is not one single step, rather a continuous process. You are not trying to generate massive profits just yet, and don’t intend to scale your business at the moment. Instead, what this MVP allows you to do is learn about demand. Once you’ve got the core feature set planned, you can start work. But remember that the MVP is only part of an iterative loop, which is split into three parts- Build, Measure, and Learn.
First, you accumulate a player base. Run an open beta, advertise your playable trailer on social media, and create a landing page. Early adopters will provide you valuable data for analysis. Use this data to MEASURE the viability of your game. Focus on the “V” in MVP, so use services like Mixpanel and Intercom to collect user data. Track game retention, churn rate, etc. Integrate feedback and bug reporting into the game, so early adopters and enthusiasts can communicate easily with you. Finally, you use the data collected during the measure phase to LEARN about necessary changes. Which aspects of your game are good? What are the weaknesses? Is the UI going to need work? Maybe the animations are choppy? Do you need social features within the game? Decide what features are missing and BUILD them into the next iteration of your game. Repeat the build, measure, learn loop over and over, until you have a polished product that everyone appreciates.
You Don’t Always Need A Game
The whole point of creating a minimum viable product is so you can test market viability by committing the least amount of resources possible. And believe it or not, there are ways to do it without even writing a single line of code. Don’t believe us? We are going to provide you with examples of three successful companies that came up with innovate ways of testing user reception. Sure, these aren’t games. But the concept carries over to gaming.
First, we’ve got Dropbox who released a simple 4- minute video explaining their concept and got over 70,000 signups for a product that didn’t even exist. Next, is the example of Buffer which is a service that lets you plan and schedule social media posts. They initially created a landing page with pricing for each one of their plans. Not only did they get data on how many people are interested, but exactly how many are willing to pay. Finally, we’ve got the famous VR headset manufacturer Oculus who is now owned by Facebook. They too created a landing page for their product, collecting feedback and raising money at the same time.
Don’t Spread Yourself Across Multiple Platforms
If you’re working on a concept for a new game and aren’t quite sure about its viability, you don’t have to release 10 different versions of the MVP. In order to validate your theory, consider who your core audience will be for a game. Do surveys and polls to find out who is interested in your game, and what platform they use. Instead of releasing it on iOS, Android, PC, Mac, Linux, etc. all at the same time, do a release on one platform and scale predictions based on initial results. This way you will cut down on costs and also speed up your iterative loop of build, measure, and learn.
Don’t Skip Marketing
Game devs believe in their creative vision. Sometimes, a little too much. A lot of startups make the blunder of thinking that a good concept for a game will market itself. A unique idea isn’t worth a penny if nobody knows it even exists. Setup a proper marketing strategy and app launch plan even before you start coding the MVP. Use landing pages, social media marketing, influencers, etc. to promote your MVP. It doesn’t have to be a finished product for people to give feedback.
Use Existing Code
Let’s say you’re creating a 2D space shooter game. The code for many of the basic space shooter games is similar in what it does, so there is plenty of overlap. You can use GitHub and open source games to assemble the basic structure of your game for free and in very little time. This will not affect gameplay in any negative way, you simply get more time and budget to spend on designing important features like sound, story, artwork, etc. This will also give you a perspective on which sections of the game you have to code yourself in later phases of development.
Apart from open source game code, you can also pick up “game kits” like the Unity Asset Store. These are basically like templates, and let you prototype games without having to write a single line of code. You can simply swap graphics, import assets, and deploy on the platform of your choice. Game kits contain a bunch of stuff like terrain art, character art, gameplay scripts, input device scripts, etc. You can find free game kits as well as paid game kits. The unreal engine has its own marketplace, and you can find some pretty cool game kits over there, like this one.
Use Basic Art And Sound
There’s plenty of free resources on the internet. Use Freesound.org and Textures.com to obtain backgrounds, sprites, audio, etc. for your MVP. Remember, you aren’t releasing a finished product. It is more like a proof of concept, a testbed to measure user response. You can get away with free assets for now, until you validate market demand for the game.
Now that you know what a minimum viable product can do for you, and how to create one, the next logical step is to measure your success. There are plenty of methods to evaluate the future success of your game, and we’ve got some of the most common ones to share with you. These evaluation techniques are proven to be effective in measuring video game success during the MVP phase. First of all, you need to monitor the traffic. Word of mouth is a powerful tool for making a game successful, and higher rates of traffic indicate that more people are talking about your game. You can also interview potential customers and show them a list of issues that you think they might face. By asking them what they think, you’ll get a better understanding of how to fix the problems that truly matter.
Next, you want to evaluate user engagement for your game. This is a great way to know both the current value of your game and its future value. The more user engagement there is, the more feedback is generated for your game. More feedback equals a better experience for the average user. A better experience drives even further engagement, and the cycle repeats itself. Monitor signups for your game, and use the results you got from measuring user interest to calculate how many of these signups can turn into paying customers.
One way to find user interest in your game is by looking at the download numbers and launch rates. Use game retention data to know the number of active users still playing your game. Another way to keep track of your game’s success is by monitoring the number of paying users. If you want to know the future viability of your game, you can calculate Client Lifetime Value or CLV. The CLV = (Profit from a user throughout their entire lifetime in the game – acquisition cost).