What would be the MVP for SC2...?

If the answer were generally known, don't you think there would be a lot more competition to SC2 out there? SC2 is the product of countless hours of design decisions; every patch that was released to SC1, SC1's initial design, the lessons from WC and WC2 that went into the SC1 design, and so on.

Game design isn't an exact science. Game design is working with infinite possibilities. Sure, there are fairly standard features in RTS, but the question here isn't What is an RTS to everyone? because everyone isn't building your game, you are. So it is rather, What is an RTS to you? (and why?)

Analysing the work of others is important; but getting started on your own work is far more important. Research is important; but don't let it bog you down. Start creating fun.

MVP is a brilliant idea, but you're missing the spirit of it: MVPs are about actively prototyping your ideas, not about over-thinking yours and everyone else's work. Getting your hands dirty is more important than worrying about what the supposed minimum mechanics for an RTS are. Many games can be considered RTS which fall largely outside the usual definition of that genre. Get a demo out and have people start playing it; and they will decide whether your product is viable, as well as genre.

I'm a little too far into the weeds to see

Until you start prototyping, that will be the case, and many questions will remain difficult to answer.

Some aspects i would say are quite easy to decide what you need for an RTS in generel. Depending on your concept, you need one "unit", that can be build, ordered or the game just starts with it.

Starting with Starcraft as your example, implement maybe a worker unit, one building and one fighting unit. Your building should be able to build both of them. General i wouldnt even add a resource to harvest, but since Starcraft heavily depends on it, in that case you should do that.

The hard part is, what features do you need to implement aswell. Your fighting unit needs to be able to "fight". So can it shoot? can it attack in cc? What are the enemies? Do you need more different units (e.g. air?)

Yes, you should only start with one race, so you basicly only got mirror matches so to speak. Additionaly, you dont need a map (if that doesnt hinder any very important features), just a square to move on. What is the objective? Destruction of the enemy or victory points, controlling capture points?

I think the problem with RTS is, that you basically got so many important features and basic elements, you still need to implement to have a MVP, while it is really hard to say, what core elements of your games are.

In my opinion it comes down to compare your base game to other RTS, and there are a lot of them, and even continued in a sequel, they are not the same.

• C&C Tiberium and Red Alert Series: Starting with main building, construct buildings by menu without a building unit, construct units in menu when corresponding building exists, different types of individual units (by foot, ground vehicle or air)


• Dawn of War 1 & 3, Company of Heroes: Base building with bulding units, no active resource gathering (passive generation by controlling points), most units are group based


• Battlefleet Gothic: No Buildings, no resouces, different types of units, not replaceable, skills are extremely important

All these differences make RTSs so vastly different. Trying to strip down a game to these basics are wastly more complicated than the example Extra Credit gave with racing games: Accelerating blocks, collision, thats it.

What makes your game unique

The key reason for developing an MVP is that you can test your idea early, and release if you need to. That is, you ensure you always finish development with a "something", rather than a nothing.

However, that doesn't mean simply making the most basic version of an RTS you can. It means making the most basic version of your RTS that you can.

Figuring out exactly which features and assets are needed is an art itself. However, your goal should be to minimise re-creating things you know work and including as much stuff that you don't. That is, you should only include things that are generic to other games - if you need it to properly test your specific ideas:

• Do you need sophisticated AI? (For a one-level MVP, you might get away with just a fixed build-order the opposition always uses.)




• Do you need more than one faction? (Maybe your game focuses on the synergy between two races and that's key. But maybe it's actually just a "nice to have")




• Do you need to have unit building and resources at all? (Maybe all you need is a pre-made battle scene with a set number of units, perhaps all your key ideas are actually focused on the skills and tactics side of things)




• Do you need to have multiplayer at all? (If the aim of the game is to make a 6000 player MMORTS; then yes - you probably do)

This of course also includes art assets:

• Do you actually need it to run in 3D? (perhaps you have non-flat terrain features)




• Do you actually need multiple character models? (maybe you do, maybe each unit has a personal story and that's important to you)




• Do you actually need icons for the tech tree? (again, maybe you've got ideas to innovate the UI for RTS games and that's your selling point).

But again; you want to only include things you need - and leave anything you don't for a later date.

The MVP principle does not always work well with an RTS, because it is the gestalt of all of your design choices that make it fun, but there are some key points you can aim for when you understand what makes an RTS fun.

The general rules of thumb for making an RTS fun are:

1- Make as many tactics viable as possible. META tactics should require you to use multiple unit types together.

This requires a flushed out list of unit classes to choose from with their final special abilities to be able to test for, but you don't need each unit type. A unit class is a unit that serves a general role in your army and/or has a special ability. If your plan is for each faction to have similar units with different skins and only slightly modified stats, just make one faction. If each faction will have several levels of some of their units that are just improved versions of one another, just make one level of that unit. If each faction has a unique set of units, you may need to build them all out. Just be mindful that you want to test as many classes as you can early on, because adding new classes later can completely disrupt the balance of the game.

2- Make META tactics change as the game progresses. This can be done either by introducing new units over time or by changing the circumstances of your battles.

Much like #1, this can require a mostly built out unit class list, but this is more about how you test your MVP. Your MVP should be able to restrict what units are at your disposal so you can make sure the early levels are still fun without all the endgame content to flush it out.

3- Balance the time it takes to manage your base with the going to war. A common mistake with RTS games is too little base automation meaning your production goes to hell if you have to stop to control a battle.

This requires a fully flushed out economic system to test for. A MVP test with 5 building types may play well, but a final product with 30 buildings might bog the player down with economic tasks and force you to revisit the drawing board how you manage/automate your economy. The best choice here is to make all of your buildings you plan to have so that you can get a feel for what a base at full scale feels like. Here the best you can do is just hold off on fancy graphics until your economy is finalized.

4- Make the environment affect your tactical choices.

This is where MVP testing will give you the most benefit. Adding environmental factors such as high-ground advantages, flanking, special weapons, troop moral, weather, and various levels of open landscapes have both the most potential to set your game apart and make it extra fun, or completely ruin the experience because you made your night-time missions are so dark that players get frustrated every time they have to play one. You can do these tests pretty early on before you have a fully flushed out list of units or economy; so, this would actually be my first testing goal. Also, knowing what environments your units will have to deal with will speak a lot to how you need to design and balance them. It's a lot easier to build your units the first time with all of their needed properties than to go back latter and give them all a coefficient for some new game mechanic.

Not every genre is conducive to a "minimally viable product". Or at least, not in the same way and they won't achieve the same purpose.

Consider a level-based 2D platformer. An MVP for such a thing is primarily about finding good jumping mechanics. You don't get to change your character's jumping physics once you start designing levels, so you need to nail that down early. So you pick some jumping physics, build a couple of test levels, and work out what kinds of physics feel good. You also try some mechanics, like tossing in a few enemies and working out how you want that to work, and/or specialized terrain and abilities (carrying items, etc).

The end of that process is what would be considered the MVP.

An RTS doesn't really do that. Or at least, it never really stops. Every aspect of an RTS feeds into other aspects of it. While it is true that there are some things you just don't change past a certain point in development, overall development is much more fluid. Here's an example.

Towards the end of StarCraft I's development, Blizzard made what I would consider to be a pretty earth-shaking change. In earlier builds, every Zerg building that made units available produced its own larva, which was used only to produce those units. Basically, in that build, larva was an alternate form of unit queuing. This was changed into the mechanic we know the Zerg for today: all Zerg units come from larva produced at a central structure.

That one change fundamentally changed the nature of the Zerg as a race. For other races, tech-switching (changing your primary unit producing building) is a process that necessitates a substantial investment. For the Zerg, you just throw down one building, and your entire production infrastructure can build them.

But this fed into the dynamic of the Zerg in terms of unit design. See, SC1's Zerg were basically built around three fundamental units: Zerglings, Hydralisks, and Mutalisks. These are your basic unit, and everything else is essentially a support unit for them. So Zerg don't really tech-switch like other races; they add a few extra X's to their existing army composition. Big tech-switches for the Zerg were mainly about which fundamental unit the core of your army is built around.

Each design element feeds the other. If you change your production model, you now have to change your unit design to compensate.

A "minimally viable product" for an RTS just doesn't work in general; all of an RTS's mechanics interact in too many ways for a "minimal" product to be anything more than, essentially, a full game.

So I would suggest that you make a small-scale RTS as your MVP. A complete RTS. It doesn't need all the graphics there, but it does need all of the stuff an RTS actually possesses. That will be able to serve the function of an MVP: to figure out how to go about making the game you want to make.

There are several answers here tailored to RTSs, but I wanted to point out something that's universal to the concept of a Minimally Viable Product (MVP).

MVP is a concept that's been around a long time, but became very popular as Agile development took the scene. The concept is quite simple at it's core: it's the smallest product which is "good enough." That's it.

What makes MVP tricky is that it is subjective, and context dependent. If you are working on the last milestones of a military contract, MVP is nothing less than "product passes qual tests." Qualification of your product will involve testing every single one of the requirement laid out for you at the start of the contract (perhaps years ago). Nothing short of that qualifies as MVP.

Early on in a project, MVP is a much lower bar (thank goodness!). However, it is also still subjective. What I think is the minimum product as a developer is very different than that of the product owner, and different still from what the VP of my company may think. You have to pick which actor's perspective you are using when defining a MVP.

The most critical voice, in my opinion, is that of the person managing finite resources: your time and your money. In a corporation, that may be a project leader or someone in finance. It might be a VP. If you're a small indie company, or someone who is writing games solo, that person might be you. But it isn't the normal game developer you. It's the you that closes the coding tools and art software and pulls up Excel to make sure you can pay the bills this month. Its the you that has to weigh the balance between spending another night coding on your little passion project versus going out with friends.

Since we're talking about small MVP's (that's what the video you linked was talking about), we can start to use Agile's approach to the concept. I would phrase it this way:

The MVP for any iteration/sprint/phase is the minimum product which justifies the expenditure of resources in the time spent building that product.

This definition is why the military definition of MVP I used earlier is valid: for them, the only thing which can justify the millions spent on a military contract is a successful product which does everything that was promised. But for you, you might be justifying a week or a month of time. The bar is lower.

So for this, take off your developer cap, put on your suit and tailored pants, and let's talk about what happens next. Developer you finishes putting out a product. What are you going to do with it?

Later in the process, one option will be to ship it -- to make money by releasing the game. And indeed, that is one key definition of MVP that should never be ignored. If a product could be shipped, it is a candidate MVP, because making money justifies a lot of development resources. But early on, you're not going to release it. So the MVP is more nuanced:

In early development, the MVP is the minimum product which permits you to learn something worth the time it took to produce it.

Note: this may not be what you intended to learn. If the thing you learn is "this game is never going to make it, so we should quit now... but damn was it worth our time trying to make it," then you won. You did some work, and felt it was worth your time. On the other hand, if you decide to can the game and you think "damnit, we just wasted how many months of our lives?!?" then that's a strong suggestion that you weren't doing a good job of limiting yourself to MVP. If you were limiting yourself to MVP properly, the past iterations would already have been deemed as paying for themselves -- no regret.

So now we can get to the examples which other people wrote here. These are answers which explore what is the minimum amount you need to learn something. But they all miss one overarching detail: what is your next move?

The MVP depends on what you plan to do with that MVP once it is created. Take Philipp's great answer and bxk21's comment. Philipp's answer argued for two "minigames," one of unit control and one of base building. bxk21 argued that those arne't as important as the time management aspect. So who is right?

That's a trick question. They're both right, in certain environments. Presumably you are about to hand the released MVP to some playtesters to get feedback. What kind of playtesters are you planning to use? Are they RTS pro's? If your playtesters aren't experts at RTSs, then Philipp's answer is probably spot on. You're looking at the small concrete pieces of the game. They will have enough background to be able to comment on those sorts of things.

Now let's say you somehow get playtesters like TLO, Day[9], or MVP. These are pro level RTS players (or in the case of Day[9], at least an honorable mention, as I do not believe he plays professionally). If these are your playtesters, then bxk21's opinion is probably the right one. They aren't going to care about the little details about whether you build buildings or whether the buildings build themselves. They're going to care about subtle nuanced thing, like time management and balancability. Now you won't have these sorts of things nailed down in early testing, but you should be able to let the flavor of them show through. You should concentrate on making a game which demonstrates the feel you want the game to portray at a high level of skill.

So figure out what you want your next move to be. What do you want to do with your product. Then figure out what your MVP is with respect to that goal.

The key word in “Minimum Viable Product” is product.

A product is something that you charge money for with the expectation that someone will buy it. If the thing you want is an MVP, it has to be just good enough for whatever price point you have in mind. That is, it can be limited in scope, but it must be complete enough to be fit for merchantability.

I’m guessing you probably don’t actually want an MVP, because you’re at the point where you have some idea but don’t even know if it’s worth making into a product. It sounds like what you want to build is a demo or some other prototype. The typical way to do this is to make a single vertical slice of the game that includes all of the mechanics you want to test. In an SC2 type RTS, that might be a single mission (if you’re doing single player) or a single multiplayer map.