Alright, so what are we up to (and why are you taking so damn long)?

1) Bug Fixing

When we built our prototype, we built it to be very narrow. We built it do get things done as quickly as possible, with no consideration for code quality. We had one job to do: make it fun, as fast as possible. After we scrapped the prototype, we started building a very wide game. That goal is entirely difficult. We know our game is fun, now how do we build it in such a way so as not to limit our options in the future?

Conventional wisdom dictates that you build the narrowest game to get your idea done. In the startup world, that's called the MVP--Minimum Viable Product. It's a sound strategy to pursue, but of course we know better than every successful businessman of recent times, right? We believe the MVP has to be redefined a bit for games, as at it's most simple, the definition of "whatever players can get their hands on and play" is insufficient. Sure, but what about when you have to update said game? That's where most early access games hit their trouble spots.

In our minds, MVP for an early access game (and no, that's not us committing to early access) is both something that players can play early, but also something that can be updated and expanded upon easily. When your update rate isn't fast enough to fix the problems that players find within the game, you've got serious problems. These problems aren't isolated to the obvious technical ones like hacking and game crashes; failing to patch your game's design in time means that players will play out its systems to the point where the game is no longer interesting, and in the worst case this playing out is irreversible.