MVP vs Vertical Slice

I'd like to hear your thoughts on the different benefits one could get from making a barebones but "complete" minimum viable product of a game, compared to a vertical slice of a game that is just a tiny part of what the whole game would be, but polished to the best of your abilities. I definitely can see value in both. I don't think there's a clear answer to what is time better spend, without a context to relate it to.

I've moved the goalpost of what I'm working towards more often than I can count now. I've realized that I'm most likely more happy with just doing gamedev as a hobby and not commercially releasing games. And I started my current project in anticipation that I won't finish it most likely, but I'm having fun with it.

After thinking about it, I'm warming up to the idea of just doing a vertical slice of the game I have in mind, just focusing on providing ~5 minutes of gameplay, and make that as impressive as I possibly can. I could imagine to be happier with having made a tiny slice of something cool, than a complete but mediocre game that can be played start to finish, but lacks overall polish and quality. Let's just assume for the sake of the argument I'd spend the same amount of time on both alternatives. Like... a couple hundred hours max, is probably realistic.

What would you personally choose and why? I'm interested in hearing different perspectives, your answer doesn't need to relate to my situation.

 

Kinda depends on the project. Fact is, you can never get an MVP without getting a vertical slice first at some point.

But if you just mean lavishing attention on a single aspect of gameplay, or a small zone vs building out an entire game. I would go with the small zone to quality. If you can build it well enough that players really want to play more, it can motivate you to buckling down and building out the rest.

I've just completed the first vertical slice of my game today. This iteration has been in the works since January. It was worth doing right and I'm extremely proud of, and pleased with the result so far.

 

I'm struggling to see the distinction between the two... Care to throw some more words or examples at me?

 

That's not an MVP that's an horizontal slice

- prototype: bare bones functionality to test feasibility of features and if the idea works and make sense, generally ugly boxes or placeholder.

- MVP: basically a prettier prototype for presentation, still barebones but has minimum functionality (ie start screen, menu, etc ...) think student's game I like to call it diagonal slice lol

- Horizontal slice: the mvp extended to the whole game

- Vertical slice: one level made to the final target quality and all fonctionality, think what demo use to be, but with all features cram into a single level. Generally required to evaluate teh final cost of the game (basically VS cost * number of level = final cost). Sometimes shown to show floor to gauge interest.

 

I do proto, which means it's not MVP, because menus etc and all that aren't essential to gameplay. After prototype comes MVP which should be the basic game, followed by content and then polish.

 

MVP: the minimum needed for release. Full systems, full content. Maybe not ideal, but releasable.

Vertical Slice: essentially an alpha (system complete, but little to no content)

Horizontal Slice: a skeleton of the entire game, an "outline" in the creative writing sense. Or a single layer of game play - for example in multi layer games (strategy layer / tactical layer).

If the amount of time spent is a constant and you're debating between MVP and vertical slice, you're really asking if the game should (MVP) sacrifice quality or scale in favor of completeness or if you should (Vertical Slice) sacrifice completeness in favor of quality or scale.

 

I'm not aware if there are by-the-books hard definitions for these terms. What I'm talking about is :

VS making ~5 minutes worth of gameplay, with as much polish, bells and whistles as a solo dev is capable of. Doesn't need to have all the features of the final product in it, just what those ~5 minutes of polished gameplay need. No menus, no tutorial, no implementing systems that aren't needed to show what you wanna show. But everything else turned up to 11!

 

You've clearly already made up your mind. People don't say "turned up to 11!" unless that's what they've already decided on doing. ;D

 

Yeah, like I've had my mind made up to do some minimalist barebones MVP first, because "it's the smart thing to do" ^^. But I just can't do it... the polish virtually sucks me in. I don't pay attention and a day has gone by with me tweaking a worldmachine graph or something like that.
But yes, you're right. I'm leaning towards vertical slice. But I'd still like to hear other perspectives and I might change my mind again, either now or somewhere down the road.

That would certainly be a nice side effect. It would also be a good reality check if the concept/vision that I have is any good at all. Considering how much time there is to sink in things like UI, balancing, unlocking mechanics, procedural generation, content, designing progressions, tutorials etc., it would be nice to know where all of that is converging towards in the end.

 

Got ya. In that case I tend to start with a minimum proto slice. In other words it doesn't really fit nicely into any of the above.

 

Thinking on it further, it really depends on your objective. If you are going to Steam Greenlight or KickStarter, then a vertical slice is the way to go. If you are going to beta testers, a MVP is probably better off.

For internal purposes, I would still suggest neither.

 

I know some people interpret it in different way, but there was many games release as MVP and they were not that at all. That's not a requirement. By that I mean they only had the core done, acceptable graphics and everything else but only the core, not full system nor contents.

I would say a lot of game jam's games end up MVP as a point of reference. That's the target.

 

This is the entire purpose of the MVP. It is to start getting your product to consumer so you can objectively test hypotheses about what it is going to take to make your product successful. One aspect of that is not wasting your time putting a ton of effort into aspects of the game before you know they will help your game become successful. So the question that I'll ask you is: Why do you want to polish your game beyond what you think it will take for it to be successful?

I disagree with "Full systems, full content." It may include full systems and content but not necessarily. If your initial testing suggests that you will need more content for your game to be successful, then you need to consider adding more content. If you are missing an important feature, you need to consider implementing it.

 

I consider an MVP to be the minimum that can be used to receive initial feedback. It is certainly not release ready. My definition of MVP is based on "The Lean Startup". An MVP should not have full systems or full content.

A vertical slice is usually 1-2 levels polished about 80%. It is not release ready either.

An MVP would come first, and would be used to ask gamers "Is the core gameplay mechanic fun?" A vertical slice would come later, and would be used to show people a taste of what the eventual game will be.

Here is an Extra Credits about MVP:

 

Eric Ries definitely talks about the MVP being the first release. He doesn't say that it has to be but my take was that it was preferable that you were charging for the MVP but not necessary.

 

I guess do something really cool.

 

I really should have prevented semantic arguments about where to draw the line for MVPs, by asking the question in a different way. Like: "If you were to spend 300 hours on a game would you rather make a proper shippable game, or a demo, reduced in scope, but expanded in quality?"

I was having similar thoughts, that's why I said I don't think one can say which is better or worse without a context. Since I don't aim for a commercial release my choices are relatively simple and meaningless. I'm interested in what unique strategies other people may have in their situations. Looking to acquire funding on kickstarter would be a good example. I'd go for a super polished vertical slice that creates good video footage for that. I'd never hand out something actually playable to get a Kickstarter campaign funded.

Given the "What would you spend 300 hours of dev time on?" rephrasing of the question, what would you suggest for internal purposes?

For me, 48 hour gamejam games are prototypes, at best. I'm not aware of many that actually hit the market without a substantial amount of polish added to them post-jam.

Personally I believe that lots of polish is necessary for a game to be successful. The opinions on that seem to vary wildly within this community.
Considering the "not wasting my time aspect", I'd feel it's far more a waste of my time to implement menus, save/load functionality, a tutorial, and unlocking mechanics, than polish up a tiny slice of gameplay to the point where I can say "this is the best I can make it". All those things are really important if you actually want to get a game into the market and I'd be spending a lot of time on them if that was my goal. But ultimately that's the bare minimum of expected effort and not something that makes people care or get interested in a project.
I think it might have been @Master Frog who said "stop making games that no one wants to play", and that kind of stuck with me. When I think of "gamers" I don't think of other devs that might be interested in seeing how I'm starting out with the first thing I release, I'm thinking of jaded cynics (like myself), that see the game and compare it to market standards of quality.

 

Vertical slice. Everyone can produce an mvp that functions correctly given enough time (assuming my definition is the same as yours), but to make a vertical slice of a game that people would really want to play takes skill and time that most people don't even know they don't have. In fact I think that the difference between mvp and vertical slice is what kills most projects.

Speaking of which, I wish people would make vertical slices and sell them for a dollar or two on Steam. I couldn't be bothered to play most games but a 15-30 minute quickie every now and then would be right up my alley. And if it goes down really well, it's probably a winner!

 

That is kind of what I expected. You don't quite understand what an MVP is. YOU decide what your MVP is. If you think that you need a lot of polish to get people to play your game, then that is what you need to do. That is part of your MVP Just because a lot of people publish junk and call it an MVP, doesn't mean that is what you should do, or that it is the right thing to do. If you think that wasting time on menus is not important, then don't waste your time on menus. Menus are not part of your MVP.

Your MVP needs to be tailored to your goal. If your goal is to have a successful Kickstarter campaign, your MVP is going to be different than if you are going for Steam early access, which will be different than if you are going for a full release. It doesn't sound like your main goal is to release a game, so your MVP is likely going to be a lot different than someone who is planning on releasing.

The whole idea about the MVP is getting your product to your customers quickly so you can get useful information about what you need to develop. If you produce crap and no one wants to play it, you really haven't learned much. If you spend 3 years making a very polished game, but no one wants to play it, you will have learned a tiny bit more but wasted a lot of time learning it. You need to design your MVP to get the most valuable information you can, as quickly as you can. That takes a lot of skill.

 

When Eric is talking about "releasing" an MVP, he is often referring to a web application that would simply need to be available for people to use. The key to his concept of an MVP is the idea that you make it available so people can give you feedback. He is not talking about releasing an MVP for sale unless that is needed to get feedback.

 

Exactly. This an an excellent definition of MVP.

 

Whenever I looked at the phrase "MVP" I always tended to focus on the word "viable" as in: commercially viable. Terms like this always become hard to define, muddy and subjective. I just had a 2 hour argument with a buddy about what exactly "software as a service" was and how to define it. When he classified Chrome as a service because it auto updates I almost lost it.

A lot of software/management buzzwords have more similarity to slang ("it kind of means ...") than it does with proper, well defined terms. I think it's because the usage evolves rapidly and spreads just like slang does. In 5 years we will all use a new term for MVP that's way cooler. Terms like this also tend to expand in usage, since everyone wants to apply the new term to their own practices, so in a few years MVP will literally mean "a goal of some sort that might involve a tester".

At the end of the day, should @Martin_H build a very small prototype that's wider and more complete, or a very narrow slice of game play that is more polished? How would you approach a similar project?

I've taken both approaches on mid sized projects, and I think that putting the extra polish on each section feels far better and tends to lead to better results.

 

That's why I opened with the problem of interpretation, the line of minimally viable depend on context and anxiety of dev A prototype (by my definition) could be a mvp in the absolute sense of things.

But at least I can argue about where I draw the line. A game jam game strive to be complete, ie they have sound, effects, beginning and end, menu and control sheet. A prototype is way less, if you are having sound and sfx in your prototype that are beyond "blocky place holder" you are over designing your prototype.

And that's the point game jam games are released then they are polished to realize the potential post jam! The entire idea behind game jam is to release game for other to test, the short time frame enforce a MVP mentality, go for the minimally needed, and feedback are rolled into the polish phase.

Early access is also the same kind of mentality, except it can start at the prototype and is relying on devlog to manage expectation and the feedback loop. Thanks minecraft! Thanks Tigsource!

 

Wait what? I have been presented the same classification for years now!
It mean that a product is not finished after release in opposition of boxed retail product who had to have a final form and where update where rolled in paid numbered version ...

 

I think playing semantics with mvp, horizontal slice, prototype isn't really important. AFAIK The mvp definition really originated from web developers becoming game developers and social media games. And what can be attributed to this semantic problem is the release of mvp games that have become commercially successful. CURSE YOU FLAPPY BIRD!

Interesting - care to elaborate more about moving the goalpost? Have you changed your mind on public release or not on the same product? Have you changed development practices towards building for different final platforms on the same game?

What would you suggest for internal purposes? I think mvp for internal purposes is a great goal to build towards, though I think mvp should never be a public release candidate, not even for mobile. For closed door testing yes - but never public consumption.

I think this is the crux of his post. The fun of development lies in fine tuning and giving something an appealing visual flair, not just playing around / tuning one thing with primitives in a grey boxed environment. This is maybe where what is fun for us as developers contradicts what is best for the project and even what is best for the finished product - if it will be a commercial released product.

Prototype is what is most important imo and is what extra credit is really describing. Mario with only a walk, run and jump mechanic is only a prototype, not a viable product. It could be by adding 1-2 enemy types, but without these - it's only a prototype.
The video is a good example of prototype not mvp - however the example fails with the jrpg reference and I would assume a lot of other types of games that use art as part of the hooks. mvp fails with the jrpg example simply because there have been a ton of successful games using that combat system. So the theory of the combat system not working - is wrong. If it wasn't wrong those successful games that used the combat system would not have been successful.
mvp would fail with representing the summoning of bahamat or odin with words or a blinky dot. The tester or player would simply say - meh - not fun, and would lead the developer to think that those moments aren't good and maybe need to be cut.
Thank goodness - mvp wasn't used as a testing phase for those elements of the FF games - imo some of the coolest parts of those games.

Why? I would think providing a 5-10 minute demo of the game (vertical slice @75% quality) would improve the chance of getting more backers.

Yeah - I'd be down for this also. We should start making these - maybe we call them micro games or something.

Yes -

I understand this Martin_H I think, though doesn't planning help keep you away from the more fun stuff, the more interesting things to do?
Without having released one of my own finished game but have been in prototype land for eons, I've found - the anticipation of building towards reaching mvp and deciding to develop beyond that is really a great motivator for me to work on things that aren't as fun for me to work on. Though I do find enjoyment working on mvp especially when I finally solve something that I struggle with - maybe it's a simple jump mechanic - (example came from a recent revelation) when getting that locked down it just means I can send it out to my peoples to confirm I'm hopefully on the right track and can proceed with other areas I might find more engaging to me as a developer.

 

I've worked for a long time on a mobile game and totally feature creeped that thing. In the end I lost motivation because I realized I'm not having fun with the bulk of "actual gamdesign" work. Like, manual leveldesign most specifically in that case. I made an attempt to turn around the direction of the game to work with procedurally generated levels, but it was a bad fit between setting, mechanics and the idea of making it procedural. Bottom line the whole concept seemed flawed to me, I was frustrated with the mobile market as a whole, lost all motivation and beat myself up over not finishing it for a looong time. At that point it would have been likely that I switch plattform from iOS mobile to desktop PC, but being a too simple mobile game, reliant on touch controls, written in Objective-C, and entirely based on Cocos-2D and apple frameworks, it just wasn't an option. I decided it's time to cut my losses on that one and made one last attempt of getting it salvaged by offering to let someone else finish the project (it was at least ~80% done I'd say, but crucial content was missing, so no way to just release it) for a 50% revenue split once it's finished. That was a few years ago though, so I'm not keeping my hopes up his motivation is high enough to carry the thing over the finish line.

And the "mech game" I'm working on might as well be seen as one project, even though my goals for that changed a lot over the years. I'll just list what I can still remember as project goals:

- "Diablo with Mechs", 2D isometric prerendered sprites from 3D models, procedural levels, loot, meta progression, iOS

- Twinstick style Mech shooter, photorealistic 3D, no HUD, didn't really think about the mechanics, Windows

- 3D orthograpic, retro pixelated, Mech shooter, with Men-of-War-series style tank combat mechanics (different hit zones, armor penetration depends on angle of impact etc.), roguelike, Windows

- same, but dropped the idea to go for retro aesthetic

- thought I should prototype it out first with cubes only

- realized I can't bring myself to do that, targeting pixelated retro look again

- made a list of what the most minimal shippable form of that game could be and had best intention to actually finish something

- got sucked back into polish and thought I maybe just don't care enough for the simplistic approach to make progress there

- made a list of how long it would take me to make a "decent" version of that game, abandoned all hope of ever maintaining motivation for that amount of time

- lost faith in the fundamental game concept as a whole because a similar game on steam does rather poorly in spite of being very well executed, so I abandoned the concept

(Somewhere around here I made the realization that releasing games to the marketplace isn't a good fit for my personal goals and I'm likely better off just seeing gamedev as a Hobby.)

- had another idea how to shift aesthetic and gameplay in a more unique direction that makes me care again, sort of 1-unit-RTS with huge contrast in size between your mech/titan and other units (that actually was a core aspect of the original concept, that I dropped when switching the concept from 2D prerendered to full 3D, because I couldn't see how I'd be able to handle 3D animated Infantry well enough)

- scoped down the amount of content I was aiming for

- scoped down from procedural generation to maybe just do it all mostly by hand, because it no longer felt like I'd get good ROI from procedural at the lower scope

- contemplating to just cut off "front and back" of the game and polish a vertical slice as far as I can, this is where I'm now

The only thing I'm really sure of is, I want to target Windows PCs as a plattform, and likely nothing else, because that's where I feel "at home".

For me it does too, but I've realized that others here likely will have fun while prototyping gameplay with grey boxes, and in turn might find the polishing work that we enjoy to be super tedious. So, careful with generalizations here, we might be the exceptions.
I think over time I got a pretty good idea of what I enjoy during development: seeing something new, learning something new, making clear visual progress (polish that clearly makes it look better than before), solving hard (for me personally) problems, optimizing something in a way that can objectively be expressed in numbers (usually framerate improvements due to optimization), coding behaviour that makes something happen and generates interaction (e.g. explosions and fire mechanics). Note how none of that really is gamedesign. I'm aware that the gamedesign part of gamdev is one of my biggest weaknesses.

Let's just call it my personal opinion. I firmly believe that most gamedev related business is "selling dreams". The assetstore sells the dream that "Anyone can make great games!", Steam early access and Kickstarter sell the dream that "The game is gonna be great, once it's finished!". It is a lot easier imho to sell a dream based on carefully finetuned and directed video footage with proper pacing and music. Just look at basically every E3 AAA hypevideo ever. NO game looks as cool if you just sit a noob in front of it and let him have at it. People will suck at playing it, do things wrong, find new bugs, nitpick it to death, and overall I think seeing something actually for yourself will hamper "the dream" of the perect game. You should have something playable to lend credibility to your claims and nurture trust in your abilites, but I see actually handing it out to potential backers to play it only hurting your funding goal. I may very well be wrong, but I'd be surprised.

That would work if I had either actual motivation to follow through on plans I make, or pure stubborn willpower. But I seem to have neither, when I look at all the things I started without finishing them. By the way, my next "mid year's resolution" is to stay away from the forums on Monday, Tuesday and Friday and get some actual work done on those days. So... either I won't be back here till Wednesday 0:01 am., or I didn't even manage to stick to that for a single week ^^.

It's comforting to hear it from someone who has done both! I just feel like this could be a much better fit for my skillset and personality.

Very good points! If you put it like that, it almost sounds like the highly polished vertical slice is my personal MVP, that gives me the information I need to base future decisions upon. It's a lot different from the "typical MVP" because my personal goals are already a lot different from the usual. But let's not get tangled up in semantics again.
You're right about it being tough to make the right calls to get the best information out of your MVP. I guess this thread here is my way of trying to improve that skill.


I feel like I got the answers (or rather confirmation) that I needed. But if others got some more thoughts to share or questions to ask, I'm sure there's potential for some more interesting stories and discussions!

 

I would just make the game. As defined in this thread neither a MVP or a Vertical Slice are strictly needed for release. Nor is either on the direct path to a release.

So they are great for specific purposes, you need something for pax or steam or Kickstarter. But in the overall scheme or things they can be a distraction from actually making the game.

 

I think the lesson is, released as early as possible, which generally mean as soon as you are comfortable. Label and format are here to make you comfortable sooner than later.

They were design explicitly for that, game jam to show you just need to make a game and roll with consequence, mvp to check viability before it became unwieldy or suck cost fallacy, devlog to build community and feedback as early as possible as a cheap marketing tools, early access is basically the interactive devlog where prototype become mvp with set managed expectation.

 

For the purposes of my comment, an mvp is like a greybox level game that functions correctly, such as in that great video that @neoshaman linked to in some other thread by the Mass Effect devs. In their greybox level, the cutscenes for example were just a black screen with some writing saying what the cutscene was about, the architecture was just modelled geometry, etc.

This probably isn't exactly correct, or the same as other people's definitions, but it's definitely what stuck with me when I first heard the term. Basically a functional, conceptual plan of the game. I also think the mvp stage is the most important of all, but it takes more rational ability than artistic - and artistic ability (not just modelling but music, story etc) being the floaty idea that it is, I think a lot of people overestimate themselves on it and hit the reef while going from greybox to the real deal. That's why I think that while an mvp/greybox is a 100% necessary foundation, a vertical slice shows that you're actually going to pull in some players, and given what I've seen of the indie community, pulling players is the skill that is by far the most lacking.

 

Nitpicking but for all the semantics the MVP is still define by released, I'm not sure graybox are MVP, as in they are not shipable.

BUT that depend on what is the scope of release, it can be an internal MVP where the other department or the publisher (or any equivalent "client") evaluate the result before greenlighting production.

IMO grayboxing is closer to animatic in animation, it's the entire story functional and timed, it just don't have the final huzzah that makes it the polish final product. It do validate and kicked in the predictable ramping of resource to execute element to maximum polish. It's basically the phases where uncertainty is eliminated from the creation process.

A bit like that

 

@neoshaman yeah that's why I defined my idea of the term, and said that it's probably not correct. I guess it just stuck with me that viable meant 'playable', when it probably means 'commercially viable'.

That said, with the bar at a a relatively high level in terms of getting indie market success, I question what 'minimum commercially viable' actually means, it sounds like some kind of retroactive term that people pretend they understand to look like they know what they're doing. If any of us knew what something commercially viable actually looked like, we'd be rich!

 

"Commercially viable" and "success" isn't the same thing at all

You can have something commercially viable and still flop massively.

Sure MVP isn't an actual technical term, more like a paradigm of product commercialization. Ie it's based on the idea that most of feature added in a product are irrelevant to the success of the product and only sugar.

It's designed for fast moving market with uncertainty to avoid the titanic effect, ie big product that fail because either too late or too unwieldy at time of release. It's really a way to manage risk more than everything else. Effectively, better shot an idea when the cost are low rather than investing in something uncertain or unnecessary, that's validation by fire. And it allow the market to react to what matter for the product, maybe the direction you had planned was wrong and you need to cancel the bells and whistle that were irrelevant.

 

This is really a great discussion thanks to all who have given opinions and to Martin_H posing the question.
I enjoy and respect the differing points of view on an important topic - design/development stages which help us create successful games.

Interesting perspective I never considered. Thanks for elaborating.

 

That's exactly why the term is not useful. Only someone with a lot of experience in business can really tell if something is commercially viable even if it fails. For everyone else, the term is a useless distraction and merely pub talk.

I prefer a more practical approach. I like to call a minimum viable product a greybox game that you put in front of playtesters and when they finish playing they say "yeah that was a bit of fun, when are you going to fix the graphics?" ... for me, this is useful whereas paradigms are not really.

I understand what you mean though, and I'm sure your definition is correct, but I think it would be better for us to redefine all these 'textbook business terms' into something that we can actually use. Otherwise all we'll end up doing is putting on the suit and tie and throwing terms around while the ship is sinking.

 

The problem is not be right or correct or wrong, it's a term created to encourage publishing in a way that minimize risk (ie good enough), instead of the old way of maximizing feature. It's not really a business term, in fact I would classify it as a production tip, it's like YAGNI in programming.

One problem is that it originate from a domain with best practice about what constitute a MVP (ie web design) then translated in a fragmented domain where there is no definite best practice base on the term (game dev, ie it's not the same thing for an indie or a AAA, and game are really diverse anyway so not all genre have the same perception).

But rule of thumb of "commercially viable" is that it should have minimal function expected from a full game (such as a title screen, menu, maybe a save, controls, proper exit, etc ... ie the shell you get with something like rpgmk even when you only have just a scene). That's the difference with a graybox where you don't expect to have the title screen and control options etc ...

Your example with the graybox isn't really a release it's a playtest plain and simple, it's happening in a control environment with set expectation. Another thing is the beta, when your game is feature complete, send to test but still not ready for release. Those are not MVP.

 

To add more context:

MVP was historically popularize in webdesign when the giants of the domain appeared out of crappy website (from ebay to craiglist), something that did goes against the ergonomic mantra of design. People realized that these sites offered functionality to people they couldn't have anywhere else, that constituted the main value of the site.

Improving ergonomy was secondary to success when advantage of first mover created brand awareness, audiences and communities, things that are difficult to beat after the fact and long production process. It also allowed these site to be more agile by having shorten feedback to feature process they could improve over time.

 

The whole point of the Lean Startup philosophy and the MVP is to be practical. It is not about throwing terms around and putting on a tie while the ship was sinking. It is about using scientific principles to develop your product so it is successful. It came about because traditional business practices, geared towards big corporations, do not work for fast moving startups that don't have a set business plan or successful product.

 

hello I don't know when to quit, please forgive my multiple post.

I think I found a better way to frame the fundamental idea behind MVP without the buzzwordiness like what's a minimal set of features ready to released. I think this part is confusing if taken at face values, it create too much anxiety

The main idea of MVP is that NOBODY know what's the minimal set of features to success, nor you know the viability of your product. The idea is that making product is expensive, you don't want critical failure (ie titanic). MVP allow you to test thing safely by starting with the minimum and grow accordingly. What if your product really took off at the graybox phase? isn't that mean you didn't need those fancy graphics, so why investing in them?

Now there is anxiety by what it mean by minimum, how do I know? That's where you need to draw a line, but wisdom is as early as possible. That's why there is the whole devlog, released prototype, pre alpha, alpha, beta, whatever buzzword you want. The idea is still to show it as soon as possible. MVP or not. It goes hand in hand with the other production wisdom: fail fast, fail often.

example
Minecraft followed a MVP model, the game was released in a free version and paid version (infdev). Who knew that a game inspired by infiniminer, dwarf fortress, rogue like, with retro pixelated gfx, procedural landscape and voxel world ... all super nerdy and niche stuff ...would be the recipe for one of the biggest success of video games of the recent years? Making into mainstream all these niche and nerdy stuff? The game was build very early from the feedback of user and finance by the early MVP (~10$).
http://www.moddb.com/games/frozen-synapse/news/what-indie-developers-can-learn-from-minecraft/

 

On the contrary, the definition of a greybox to me is that it has the minimal functionality of a full game, but this functionality is present merely in a structural way. Whereas something that is commercially viable is far beyond mere functionality, it is what might be called 'orange box' (I think that's what they used in that vid you linked to).

A game is not simply a functional product the same way that some other product (e.g. an angle grinder) is. A commercially viable game has a lot of meat on the functional bone - art, story, sound, artistic design. You can't evaluate a commercially viable game on functionality. That's why I suggest that the term is, for most intents and purposes to us, useless. Probably what we would call a finished game is what more experienced devs would call a minimum viable product (if that). That's why for me, there are two stages - greybox to test concept, and a finished game that I try to keep from drowning, and that I update until I'm sick of it.

But again, I understand where you're coming from and you're certainly right in your definition, I guess my angle is that the whole idea of a minimum viable product is probably more applicable to studios and experienced devs. As poor, overworked, relative beginners we need to cut down the dev process into clear, practical stages and throw out all the fluff. In my experience in all areas of life, the least productive people of all are usually too busy digesting paradigms, pie charts and pyramids to get anything done.

 

The Extra Credits video is where I first really heard the term, and their example is far from what I would call 'commercially viable' and is more like a greybox level to me. I think perhaps we should remove 'commercially' from the definition because it seems to me that while an mvp is there to scope what a shippable product will contain minimally, it is not in itself a shippable product except in purely theoretical terms.

 

I wonder where demo fit's into this?

Quoting @frosted's descriptions:

"MVP: the minimum needed for release. Full systems, full content. Maybe not ideal, but releasable. (Demo? Maybe, it wouldn't be releaseable as in for sale and it would be "ideal"... Hopefully).

Vertical Slice: essentially an alpha (system complete, but little to no content) (Not a demo, this is more like a prototype).

Horizontal Slice: a skeleton of the entire game, an "outline" in the creative writing sense. Or a single layer of game play - for example in multi layer games (strategy layer / tactical layer). (Again just seems like a prototype to me)."

For me personally a demo suits best, simply because everything is layed out. It's just a matter of increasing gameplay via content and tweaking difficulty curves etc... Although the focus isn't to overburden yourself with the complete scope of the game, finally it'll give you massive insight into scope. As in many truthfully say the last 10% can take as long as the other 90%, if the demo is taking too long you know to rein it back in right there and then.

 

@ShadowK actually I think a demo is pretty much the same thing as a vertical slice. If you have a game with 12 missions planned out and you create one finished mission, that's a vertical slice (sliced by mission) and is pretty much the definition of a demo.

I agree that a demo is the best idea, simply because you will have tackled every single thing, from core systems to polished graphics, and you will know exactly how difficult the rest will be and can plan accordingly (or drop it altogether if not feasible!). Not to mention you can give your potential players some real fun. So for me Greybox -> Demo -> Full Game.

To take other people's definitions of MVP (i.e. a game ready to ship) - well I call that a finished game, doesn't mean I can't update it later. And if that's what an MVP is then to answer this thread (again) I think a vertical slice is a much, much better target to aim for unless you're sure you're going to be able to finish it.

 

@ShadowK

IMHO what define a demo is that it is promotional. It's not a release in the proper sense, it's a not a production step either. In fact any production step can be used as a demo, though fgenerally demo are only a small part of the game and can be build or tweak specifically for the purpose of promotion and not happen in the game at all. Very often vertical slice are picked as demo on showfloors.

I'm not sure throwing that in

@Billy4184
Who said I'm an overworked beginner?

I think you are confused, the video about mass effect isn't about MVP at all. They have minimal in the sense of functionality given the design NOT FOR RELEASE Like I said it's an animatic. They may had use the term (as in its the minimal validation structure, it would make sense as we often use the market metaphor for internal production structure), but then that's not how mvp is discussed in the general sense.

If you use that in that sense you are making a leap that will only confused discussion more. It's like talking about "client" in the context of programming, it's not to be confused for an actual real world market client, it's an extended metaphor because it's convenient.

I think what you miss is "PRODUCT" what's the minimal product to released, not the minimal version of your game. Think of it as the minimal service the product offer, a mvp game should have a title screen because it's a required feature to go commercial. Ie what is the minimal version that look professional irrelevant of quality. Of course those are ill define term but whatever.

You are too hung up about the commercially viable, you put too much in it.

If you want to really say the term is useless when it's already proven even among game, you are free, I'm out of the discussion, we have entered belief and petty semantics. I'm not helping either

And extra credit isn't the golden standard in term of practice within the industry, I have seen a lot of "hoopla" happening among professional when that video happen, because they often have things mixed up and people scratch their head.

 

YEP let's remove MVP for first playable!
#Don'tKnowWhenToQuit

 

This.

Imagine if all the energy put into what to call each step, were instead put into building instead? There is no MVP with out the P.

 

I kind of look at it like this... your average good Steam Early Access game is an MVP.

It is viable: customers will actually buy it.
It is minimal: there are frequently literal "coming soon" labels slapped over less critical features.
It is a product: it is fully playable and provides an adequate experience.

I'm talking about the good Early Access games, not the crap.

This is my goal. To produce a product that people will buy, and give positive reviews to. My job as a developer is to try my best to figure out how to achieve those two goals as fast as possible:
#1 - People will buy it.
#2 - People will positively review.

Is a tutorial part of my "mvp"? I attempt to answer the question by asking myself: does my game need a tutorial to achieve positive reviews?

A "full release" should really have a tutorial, but perhaps I can get away with an MVP that doesn't have one. Truth is, there isn't really an objectively correct answer to the question, so at the end of the day, you just need to guess. You try to make those guesses 'informed' and 'smart' but at some point you just need to pick a number and roll the dice.

The real point of the phrase "MVP" is just to help you avoid feature creep and focus on the critical stuff... don't treat it like it's science or some real, tangible thing.

 

I liked your post but I think this needs a little clarification. An MVP is not a set in stone tangible thing but it is kind of a scientific process. To much attention on this thread has been about an exact definition of MVP and not about the process. The more objective "scientific" information you can get, the quicker you can get it, the easier it will be to develop your startup.

Here is a simple question. Who here recommends that newcomers spend years and years developing an mmog as their first game? Who here recommends newcomers start with something smaller?

That question is really the essence of the lean startup philosophy. It is better to start with something smaller to see if you have the talent, and if people have interest in your games. If you don't have the talent or can't learn the skills to be a game developer, it is better to learn quickly and pivot quickly so you don't waste your time.

 

The nomenclature can be whatever you want it to be. Before the term "mvp" programmers would look at the feature list and ask themselves "can this feature wait till version 2?" and if the answer was yes it would get bumped off the roadmap.

The phrase "mvp" essentially codified that process.

"Can this feature wait till later, or do we absolutely need it to launch?"

Call things whatever you want, as long as that helps you succeed.

 

It's important to note that customer of MVP are "early adopter", they are not every customer, that's an important distinction because behavior pattern is not the same, the reason is that they will dig through the "jankiness" to get the gem of your product (the core functionality). They will be the one making extended guide and ease the early majority. They supplement the value and provide valuable feedback.

See minecraft and the craft recipe tree, there was no in game guide, no tutorial, early adopter figure it out and build a wiki, they build forums and they made video promoting the game. They build the community at no cost for the dev.

Just look at what happen to the new forum and user who jump fixing the issue with stylish and all.

 

I'm crossquoting from @Arowx's thread to not derail it even further. Let's move it here.

Imho the question 1 polished game vs several unpolished small games is at its core very similar to the one I opened this thread with. Perhaps it would have been good to phrase it this way from the start, because that would have avoided the whole semantic discussion about what different terms even mean.

Feel free to discuss the new-ish topic in the context of beginners starting out, and in the context of pros that already have a bunch of finished games under their belt. I could imagine recommendations for those situations being different.