In the last of SeeThrough Studios’ developer diaries, Saul Alexander reflects on what the his team of indie developers did right, what they did wrong, and all the ways an indie studio can be tripped over by the forces beyond their control.
Tuesday, 27th of February, was what you might call a “memorable day”. Two days after completing work on Flatland: Fallen Angle (as our game was finally christened), the core SeeThrough Studios team met for the first time at our brand new office, a space provided to us by the Academy of Interactive Entertainment (AIE) Sydney, on the condition that we provide occasional guidance to the graduates there (who are in the process of starting businesses of their own).
I arrived excited – I’d spent the previous evening contacting various media outlets, and we’d received coverage from two big-name indie games sites: the Indie Games blog and Rock, Paper, Shotgun. The RPS coverage in particular was a coup — probably my favourite site on the entire internet had given the game a very positive write-up, and brought a load of traffic in the direction of our game. Throughout the morning I watched with increasing light-headedness as our page views climb towards two thousand.
Among all the discussion that morning of intangibles (“what we did well”, “what we’ve learned” etc.), that number was a concrete sign that something small had changed in the world because of our hard work over the past three weeks. That the eye of the all-seeing Internet had, for just a fraction of a second, flicked in our direction.
But the day had another surprise in store for us, this one less pleasant. By early afternoon, my elation would stumble towards confusion, when we received a troubling email from Paymate (the company processing our payments) informing us that, for unspecified reasons, they were shutting down our account, and refunding all of the money that we’d so-far received.
Thankfully, this wasn’t a whole lot of money, at that point. If we’d released a purely commercial game, we could have had a much more significant disaster on our hands. Luckily, for this test run, we’d opted to release the game for free, and had only charged for our “Appreciation Edition”, so that those who wanted to contribute to our expenses could choose to do so.
More has already been written about our rather bizarre treatment by Paymate. We also wrote about it on our own blog. But mostly, it was just a brilliant example of the biggest lesson I’ve taken away from this whole experience. Which is simply:
Test runs are freaking awesome. If you put yourself under pressure to achieve something — knowing full well that you will make many mistakes along the way — then you will learn a staggering amount. I can’t recommend the experience highly enough.
So that’s the meta-lesson. What else did this test-run allow us to learn? Well, lots of things. During our meeting, we ran through a four-step process, writing a list for each of four different categories, covering what we did well, and what we need to improve on. These are the things we wrote:
“What we did well”: music, audio (less so the voice recording), the rush to basic gameplay, dealing with technical issues, writing continuity, world creation, company culture, our press release, attracting media attention, tenacity, well-being (we supplied everyone’s lunches!), daily builds, strict on-time hours (or close enough!), and video coverage.
“What we learned”: The transition from the initial rush to carefully managing our progress needs to happen earlier, days off are amazing, Thursday shouldn’t be a tech development day (something always went wrong on Thursday!), voice acting needs to be 100%, level design takes a long time, more QA and polish time is needed, feedback from playtesting is useful but hard to manage, we need more experience with Unity (our development engine), time restrictions are interesting, and sourcing pun titles from from Twitter works!
“What we don’t yet understand”: trailers (ours was hastily smacked together, and fairly wonky), polish, managing documentation, design (getting the gameplay just right), how to pay music royalties, nine-to-five marketing, and having an integrated marketing plan.
“What we want to do”: Have screen-capture software on every PC, make a five-minute video at the end of each day, change to another payment processor, have tools days (where we just work on tools, rather than games), get a lot better at using Git (our version control software), research plug-in libraries (for Unity) before we start using them (we had a couple of false starts), better website design, test rough versions of voice recordings in the game before final recording, and get a full-time artist!
There’s so much more to say about all of these aspects of game development, but I’ve run out of space to do so here. Over the coming months we will be tackling all of them (and many more that we haven’t foreseen, no doubt) on our SeeThrough Studios blog (http://seethroughstudios.com) , as we take our next steps into the great unknown of Being a Proper Development Studio. And Paul and I will also be discussing our journey every week on the Game Engine Podcast, with our co-host Andrew Bitmann. We’d love your company along the way!
You can read the rest of SeeThrough Studio’s developer diaries here. Photo and video credit: David Molloy