Can polishing the GUI be ever considered a part of making the MVP?

Question

I've read and watched about the MVP:

• Minimum Viable Product for RTS game?
• What should be created first in a video game?
• And of course the video everything on the subject links to

I'm trying to apply this concept to the menu-based combat game I'm trying to make as a hobby project.

This is a little bit tricky because when I started the project I did not know about MVP. As a result, I first cut my original idea significantly down to what I considered the minimum release-worthy version of my game; so that I could, in the future, release my game and then iterate on this first release. This, obviously, was far more than what would be considered MVP. Out of necessity (the game started as a project for a Uni class) I first focused on coding the stuff so that I could show my code to my Prof.

The result is that I now have a large, working though bug-ridden and unplayable mess of a game that I'd now like to try to slowly bring to playability. In order to achieve this I'm finally trying to cut the game to MVP and only work on these parts of the game that form the MVP, ignoring the other parts; then iterate on this, until I hopefully finally bring order to everything I made earlier. (I even commented out lots of code that is not responsible for the MVP-ish parts of the game.)

Unfortunately, it has proven difficult for me to determine which parts of this game form MVP.

One such difficult case is the GUI. As far as I understand, GUI is only part of MVP insofar as absolutely necessary to allow me - the dev - to interact with the game. So monsters are to be represented as uncolored squares etc.

But the problem is also, as far as I understand, I should keep polishing the MVP until it seems fun and only then add any content. But I now think that polishing the GUI a little bit more is a prerequisite of this.

Example 1: In the spirit of the MVP, I do not have health bars now. Instead, I have bare numbers on top of the empty space where the monster's sprite is supposed to be placed in the future. However, I find it not very readable to have a monster's HP represented as 3649/6000. A bar filled to around 60% of its maximum length would be far more readable IMO.

Example 2: The status console. Originally, since I only focused on writing more code, the console was a mess. Status messages were often in a counter-intuitive order, were poorly broken into paragraphs, etc. I found that this itself was making it annoying for me to interact with the game. So I started working to fix the console, and I think I fixed it somewhat, but enough to make me satisfied. I would now like to continue working on fixing the console.

Both examples show why I have feeling that polishing the GUI beyond what would be considered MVP is a prerequisite of making the correct MVP. I don't know, maybe it's a peculiarity of menu-based combat games: the menus themselves are at the very core of the game so they should be usable and information from the game should be displayed in a clear way that makes it easy to comprehend what is going on?

Am I correct that stuff like adding health bars instead of bare numbers and breaking the status messages into paragraphs correctly, displaying some of them in a smaller font, adding sleeps between more important messages can be considered a part of making the MVP? Or am I misunderstanding the concept of the MVP?

Answer 1

Remember, these terms we throw around like MVP, agile, ECS, vertical slice, etc. are not absolute laws of the universe. They're just ideas that some folks have found helpful to their process.

Where they help you make progress, use them. Where they hurt your progress, bend them.

No MVP police will arrest you if you use a health bar. Steam will not ban you from selling your game if you put line breaks in your console earlier than you were "supposed" to. Your computer won't collapse into a black hole.

The only real consequence of how you interpret "MVP" is what it does to your development timeline.

So, look at your schedule:

• When do you want to have your complete, playable version? What absolutely has to happen for you to get there?

• Are you on track to meet that goal based on your velocity so far?

  Did the time you spend improving the console so far threaten your deadline? Or did it help, by making it clearer to read what's going on, so your testing is more efficient now?

• What pain points do you still have, and how do they rank in priority order against the other features you still need to finish for your target MVP milestone date?

Once you've evaluated this, you can triage the remaining work items based on the value they add versus their cost/risk.

By managing your prioritized backlog of work, and re-evaluating periodically as you get further along, you can make sure you stay on target to deliver something playable for your MVP milestone date - maybe even with some niceties included as a bonus to make the next phase smoother.

Remember too that the focus is on "viable" - we want to find the minimal route to a playable result, not minimalism for minimalism's own sake.

If the current interface is too hard to read for you to clearly understand what's happening, then is it really "viable"? Will you be able to play the result and accurately evaluate whether it will support your target experience, and plan your next steps accordingly? Or are the rough edges too painful/distracting to get a good read, forcing you to risk more work on an unproven concept?

That's a judgement call you need to make based on the needs of your particular game, not a textbook definition for others to adjudicate for you. There are lots of different philosophies about how much depth and niceties are "enough" to prototype a feature - see Lee Perry's "Pizzazz First, Polish Later" microtalk, about 5:20 into this video. There, he argues that we should separate the notion of "good player feedback" from the notion of "polish," arguing the former is actually part of the core of the feature we need to be able to evaluate the feel and experience, not a coat of paint to add at the end. That doesn't mean we put the MVP on hold until we have final assets for everything, but it does mean putting in a quick & dirty placeholder effect isn't necessarily breaking the MVP "rule."

At the end of the day, it's your game, your production timeline, your risk to manage.

If you're answering to a publisher, backers, or prof, can you be accountable to them and say "this work is helping achieve our agreed-upon milestone goals"? If you feel you can't, maybe that's a work item to put into the longer-term backlog, and come back to later.

Answer 2

TL;DR: The idea behind creating an MVP is less about the precise definition of an MVP and more the general principles of:

• Not starting to polish until you have something you can actually play
• Not doing too much polishing (in the beginning and altogether)
• Not adding a bunch of features before having something playable

---

You start off creating the smallest thing that is actually playable. This would have no polish.

Then you polish this until it "works":

• Part of this is getting rid of bugs.

• But some polishing also makes sense here to have it be functionally fun: the core controls are smooth, you can see what's going on, etc. (but not that it looks "pretty")

  If you consider a platformer as an example: you start off moving your character around in an empty room and tweak this until it feels smooth and only add elements after this. If the player's "core" controls aren't smooth and you want to change them late into development, you may also need to change how abilities that affect movement work, how different types of floors interact with movement, how enemies move and attack, what some levels look like so they're not too hard or easy, etc. Of course you may need to do these things anyway when you adding features, but you don't also want to do it for something you could've addressed a lot earlier.

  Also, and perhaps more importantly, you may realise your vision just wouldn't make for a fun game, and you either need to rethink parts of your game (or your entire game) or just scrap them altogether.

You shouldn't spend too much time polishing though:

• Polishing too much can come at the cost of making "real" progress on your game, i.e. adding features and content and actually releasing your game.
• Things you add later may require you to make significant changes to what you've already done and scrap large parts of the polishing you've done so far.

At this point you get into a cycle of adding the most important next feature or piece of content, getting rid of bugs, doing some polishing and repeating.

After this, or somewhere in the middle of this, you start doing the "final" polishing, where you make things look "pretty". You shouldn't do this at the start.

Whether you consider an MVP to be the part before or after the initial polish shouldn't really matter.

---

For your example, I imagine having a "clean" UI would be a pretty important factor in whether it's functionally fun (as defined above), so you should definitely be polishing that a bit.

This includes how you display health. If you want a bar, I might recommend simple ASCII -'s, where each - represents 10%, or something like that. Of course it depends how much effort different options would be for you and what would fit in your UI.

I would start with extremely basic status messages that probably aren't even complete sentences, so if you're considering adding paragraphs, these may be too complex for an MVP (but it depends on what they actually say). Making sure you're able to actually read the messages would be important though, so adding delays between messages might make sense.

Answer 3

If your game is very UI-centric, then reading and navigating the UI can actually be the core mechanic of the game which you need to demonstrate in your MVP.

But it seems to me like you are already beyond the MVP phase and entered the prototyping phase. The purpose of an MVP is to get a playable game running so you can iterate on its design. But it seems to me like you already did that, discovered essential problems in your design (like UI which is so bad that it distracts from the game experience) and started to iterate on them.

Just make sure that you prioritize issues correctly.

Is the UI really the worst problem right now? Does the bad UI prevent you from playtesting your game mechanics because even you can't tell what's going on in the game? If so, fix the UI! But is the UI already able to give you the information you need? Are the problems with the UI largely cosmetic? Then you should focus on aspects which are more relevant to the game mechanics right now.