Minimal viable product

One thing that you will sometimes see when reading indie game developer blogs/postmortems  is the discussion of the minimal viable product (game). It’s one of those terms that have different meanings depending on who you ask, but from my point of view, it is essentially an agile development method.

Essentially, the idea is to build the bare minimum game experience necessary to find out whether people find the game fun or not. For an indie game developer, this approach is typically married with a couple of additional behaviors:

  • Code Reuse. Rather than building new game engines, reuse an existing one. It’s impossible to overstate how important this point is for indie developers, and it is one reason why I’ve occasionally during my game development “career” reached out to other developers of turn-based games to share code and experiences. Despite being very conscious of this, it’s also one of the areas where I don’t think I’m very good – the code reuse across the various projects I’ve done over the years has generally been abysmal. One of the things that I hope to do with the code for Pirates and Traders 2, is to try and reuse more elements of the same framework for some different game ideas that I have – hopefully meaning that I can create more games in future, in a shorter amount of time.
  • Reuse art and sound. I’ve been fortunate to work with some really talented guys who’ve charged me reasonably for their services, but this one is really critical for indie game devs. There’s a fair amount of free and low-cost music and sound effects out there. Art is harder, but that exists too (I suspect one reas Ion for the popularity of the pixel art aesthetic, is that there are a lot of pixel art sprite sets available for free). I did this really aggressively in the original Pirates and Traders; absolutely every piece of art in the original game was either Public Domain or Creative Commons, only replacing the art as the game began to earn revenue. For Pirates and Traders 2, I’ll be mostly reusing the art from the original, although I have plans made for stuff I want to add/replace as and when money allows. It helps, of course, that I create games where graphics are not critical to the gameplay; i.e., if you can’t enjoy the Pirates and Traders gameplay with the basic graphics of the original, you probably won’t enjoy it with professional art either.
  • Key features only. The idea in a MVP is that you want to stress your core game loop, because if it can’t stand on its own, the game isn’t going to work later either. I’ve been playing a bit of Assassins Creed 4: Black Flag lately (for Science…. research, you know 😉 ), and it’s been quite instructive. The core game loop there is of course going around murdering people in towns and doing the same to ships on sea. The game throws a ton of collectibles at the player to try and make you stick around, but (unless you’re the type that absolutely has to get 100%), the game is only going to hold your interest for as long as you enjoy the core game loop. Personally, after 6? titles, I’m pretty played out on the whole assassin game mechanic, and while I love the ship battles (and especially the visuals), it’s probably not going to get me through the entire game story. This is also why – IMO – it is a huge design flaw in the game that you have to play through almost half of it before they unlock all of the ship features. Although it’s still an interesting game, I can’t help feeling that the game series has lost sight of what made the game compelling to play in the first game (hint: it’s not collecting 399 sheets of paper and eavesdropping missions). Returning to my own games, the core game loop of Pirates and Traders are the ship battles and the port trading; the first version of the game contained little else (most of the RPG elements came later). The Pirates and Traders 2 beta will start in a similar place. When following the MVP approach, it’s critical to focus on the core game loop, and get it right.

 

One of the big “risks” of Pirates and Traders 2 is that I’m messing around with that core game loop – adding fleet action to the game changes the complexity and dynamics of combat. If it works out the way I hope, it will add extra depth and complexity, particularly to the later parts of the game where the player typically has a strong ship that can dominate the opposition in the current game (making the core game loop boring). If the redesign fails, then the game will have become more complex without adding any value to the core game loop. That’s the part that makes game design tricky – it’s easy enough to dream up new features, but if there’s not enough cost/benefit in the changes in terms of gameplay, it’s easy to end up with a worse game.

Even if the core game loop is perfect, though, that’s of course no guarantee of success. As Jeff Vogel commented in a post recently: Writing games for cash is a harsh, unforgiving affair. Success is rare and failure common, instead of the other way around. If an indie game fails, it shouldn’t surprise you. Success should surprise you. Focusing on the MVP is one way in which indie developers can reduce the risk in creating a game.

 

Regarding the beta, it is almost ready to get started. Saved games are working now (at least to the extent that my testing has uncovered), work now is focused on just running down the To-Do list to ensure that there are no (fewer) major broken features in the first release. Currently at 38 TODO items to go, but most are quite small, so with a bit of luck, the beta may be out this coming weekend. Assuming I don’t run into any major bugs while play-testing…