Subscribe to the Seeing It Through podcast here.
Sometimes, when starting a company, cofounders will find their views falling completely in line with each other. They’ll find that they were, sometimes surprisingly, thinking in exactly the same way about a problem that has a number of possible solutions. This is when things move the quickest.
Sometimes, the other thing happens. And that’s where some of the greatest learning can happen.
Alphasodic has been the latter, and it’s not quite done.
While writing this, I’ve realised that Saul and I have now come to agree on many of these points. It’s interesting how we’ve found common ground within points of contention to create a somewhat coherent strategy, and how many of the original problems have become less relevant.
The problem can be summed up as follows: we’re going to be using some type of alpha funding model for Flatland. Alpha funding is great: it lets us grow our customer base over time, gives us contact with those who are actually paying for our game and gives us an all important revenue stream.
And yet a part of it seemed wrong for us. We’ve got a vision for Flatland, and that vision requires a fair bit of tech. Our vision involves using varied mechanics to demonstrate how different inhabitants of the world see and understand it, and a lot of those mechanics still need to be made, tested and proven. Now, it’s tempting to just start making bits of the game that address those mechanics, but the simple fact is that by the time we’ve done these, the first bit we make will surely feel sloppy and invalid next to the last bit.
Which brings us (after three months or so) back to the idea of episodic games, but with an alpha twist. Hence Alphasodic.
The idea is that we simply make new, standalone episodes in the Flatland universe, as part of the process of building our tech. This allows us to skill-up our design without worrying about whether everything will fit into a final product, and gives us an amazing ability to take baby steps to greatness by simply ensuring that each episode is better than the last.
I’m looking to take this a step further and to split our development cycles into two independently moving ‘teams’: Tech and Content. Tech deals with build mechanics and tools and polishing those mechanics to be smooth and exciting, while Content builds new episodes using existing tech. This frees the tech guys to take a little more time (though they’d still have deadlines) to really hone a mechanic and make it as good as possible, while the content team builds new episodes using existing systems.
This brings us to the first issue we’re currently tackling: polish. When we talk about Alphasodic, we talk about being able to build and polish a game within 3-4 weeks (and to be honest, I’d really like to bring that cycle down to 1-2 weeks as we move forward). Saul’s main worry with this is that the quality of the games we make won’t be high if we go down this path, and he has a point: there’s a lot of issues with Fallen Angle that spending more time on it might have fixed. My thought here is we need to get to the stage where we can polish a game in this short amount of time, and that we’re simply not going to get enough practice at those stages of polish to get really good at them if we make things slowly.
I don’t think either of us knows for sure which of these stances is correct, which is why the issue is problematic. We simply can’t know without trying one, and either way it’ll take a while to test.
The Alpha of it all
The other big issue is one of release. A traditional alpha program involves paying a certain amount for a product before it gets made, with the understanding that there will be a “final game” at the end. Since we’re going to be releasing on Desura’s alpha-funding channel, we need to (at least for now) follow this model. But in an episodic program without a specific end-point in sight, what does the alpha program mean?
Something I’ve pushed pretty hard for is the idea that we’re going to end up with a subscription model. The fact is that making individual games and hoping people buy them isn’t a sustainable business model for most indie games teams (with very few exceptions, most will also do contract work or sell development tools). A subscription model with regular enough content releases can be. We’re not ready for that yet: we have no track record and there’s a bunch of infrastructure to build. At some point, however, we’ll most likely be looking to transform our alpha funding program into a subscription program of some kind.
Saul and I have tentatively agreed to the idea that when people pay for our alpha program, they will get the first six episodes of our alphasodic Flatland game, regardless of how long those takes to build (ideally less than six months). So the “final game” would consist of these six episodes. Obviously, because we will be improving as we go, there will also be quality inconsistencies from episode to episode. We kind of feel like this is okay – players will be able to look back and track the ongoing evolution of our games and stories, like you can with Mickey Mouse or The Simpsons, but on a much shorter time scale. In essence, our games will be a document recording the history of their own development. This is in line with our “see through” philosophy, as well as being where the “alpha” meshes with the “episodic”.
Our main issue right now is in specifying exactly what it is that we are going to end up delivering to our alpha customers. Because I’m wanting us to push our content pipeline to make better things faster, six episodes might be over quickly. In terms of playtime, the collection end up rather large, or quite small (our upcoming episode, by the way, is looking to be half the size of Fallen Angle (in terms of overall level size), since we’re looking to produce higher quality content, while simultaneously building our tech to be more sustainable).
As the guy who’s designing the value proposition to our customers, I’m worried that I might not be able to make a really juicy promise that we can definitely keep. It feels like we’re really close to a cohesive business/development model that suits our needs, and yet there’s this snag that we haven’t quite figured out.
This, in short, is worrying.