As you may have heard, Flatland: Fallen Angle has been given a facelift since it was last published, and that facelift is coming to the interwebs quite soon. It’s taken a little longer than expected, partly because of the different builds* we require.
*I’m using the word ‘builds’ here because ‘versions’ is misleading: these are all the same ‘version’ of Fallen Angle, but they have slightly different features. For the purposes of this article, I won’t be discussing builds with the same features for different platforms (PC versus mac builds, for instance). I’m sure there must be a better term for this concept, so please let me know if you know of one.
There’s a couple of different builds of Flatland: Fallen Angle that are currently on this computer: 5 to be exact. And as far as I know, there’s at least 3 more to come.
Why are we making so many different builds of this one, very small game? How do we decide what builds to make? And how do we keep track of them all? What follows will be a mixture of marketing, product design and technical tips that will help you to decide whether and how to split your code base.
The first question is why, and this is where I have to put my marketing hat on. And we start with a simple truth:
At this stage, Flatland: Fallen Angle is primarily a marketing tool.
Why? The game isn’t in any state to be expanded upon using its existing code base (which, for the most part, has to be thrown away). The gameplay in it is now 2-3 iterations old and thus isn’t horribly useful as a playtesting tool. And while we’ve had a pretty decent conversion rate in terms of purchases, the game simply isn’t of a high enough quality to concentrate time on selling it further.
With this in mind, we come to the true utility of a game like Fallen Angle: to introduce people to the world of Flatland and to get them to engage in that world and our company.
How do we want people to engage with us? We want people to sign up to our mailing list, and we want people to sign up to the alpha of our next Flatland game (more details on that are incoming).
I could (and probably should) write an entire blog post about why mailing lists are important to a starting business, but we’ll just take it for granted that they are.
So we’ve got two separate goals for how we’re wanting to use Flatland: Fallen Angle going forward, and in general, we want to be able to send potential customers in different directions depending on where they see it. In other words, we want to have several different calls to action (click here to buy the alpha/click here to download more, etc.). Combine that with the fact that we need a version that’s easily playable, and we end up with the need for a number of different builds.
Next up, is figuring out which builds we need. We decided these by looking out our marketing funnel: that is, how the customer will travel from having never heard of us to buying. The best way to illustrate this is through example, so here are the 5 builds of Fallen Angle.
The first is the web demo. As mentioned in the section above, there’s a need to have a version of the game that’s easily playable. As a starting studio, asking people to download the game is unwieldy and generally a bad idea, and seeing as we’re using Unity we have the opportunity to put the game on portals like Kongregate as a marketing push. However, our full game is approximately 30mb on web player, and waiting for a 30mb preloader is a pretty awful experience for a user.
So we decided to pare down the web game to the first 4 levels and call it a ‘demo’, which halves the file size and adds the benefit of being able to encourage people to check out our website for the full game (this is the call to action). So that’s our first version: ‘demo-web’.
The next question is: once people have played this demo, will they have enough to want to buy the alpha? Our guess is no – they need to see the entirety of Flatland: Fallen Angle before this is the case. However, they’ve probably seen enough to exchange an email address for the ability to download the full game.
This is where the Curiosity Edition comes in: we’ll continue to give it away for free, but we’ll be sending it specifically to those who are on or those who join our mailing list. This will help us to create a community and closer relationships with the people who are interested in what we’re doing. The Curiosity Edition still lacks the arena and commentary features, and has a call to action of buying into the alpha.
Which is where the Appreciation Edition comes in. It’s available to those who are in the alpha/have already bought it (which will become equivalent once the switch is made), and contains the arena and commentary features. There’s no call to action, because there’s no need for one.
For now, at least.
For those playing along at home, that’s 3 builds so far, out of a promised 5. The last two are extras for specific purposes.
We’re going to be selling our alpha program through Desura as well as on our own website, so we need a separate, executable version of the demo (‘demo-desura’) to act as the demo there (note that the call to action from this demo links to the desura website rather than to ours).
Finally, we need a slightly altered version of the Appreciation Edition for those whom we’re sending the game as a freebie, with a call to action to buy the alpha version.
And those are our 5 builds. But how on earth do we make them all, and keep them all up to date when changes need to be made?
In a word, source control. Specifically, source control with branching. More specifically, we use git.
I don’t really want to turn this into a lecture about how important source control is, so let’s just say that it’s really important.
In this case, we’ve got five different branches of the game representing each release version (demo-web, demo-desura, curiosity, appreciation and appreciation-free). We also have a master branch, which contains anything common between the builds (for instance, the code and framework for calls to action are in the master branch, but they are only present in the scene in builds that need them), and a demo branch, which contains the changes to level 4 and the menu system to make the game a demo.
When you’re doing this, there’s always the danger of mixing up branches and pushing changes the wrong way (I did this at least twice), so you’ve gotta be sure you know how to revert changesets and how to deal with this. While this can be a pain, there’s a huge advantage to being able to make changes to the game as a whole and then just push them to your various builds.
Hopefully, this blog post has given you some insight into what goes into deciding how your game builds might get split. I found myself quite surprised by the sheer number of builds that we needed to split Fallen Angle into and the work that needed to go into making these builds work together. With any luck, you won’t be so surprised when you face similar issues.