The power of the crowd – how community support drives TerraTech to success
May 2016 marked two years that we’ve been working on TerraTech as a team. We got a small boxy shared office in Hammersmith in London, took the plunge and started spending all of our time focusing on a game about building vehicles with blocks, attacking enemies and stealing their blocks to make your vehicle bigger and better.
Looking back, it seems to be going well. Our studio, Payload, is now 14 people strong (including our new Programmer Django and new QA lead Adriano) and we are just settling into new office across the city in Kings Cross, which has the advantage of a bit more space, fibre internet and no construction site outside our window. TT has been in Early Access for just over a year now and our brilliant community is as active as ever. We’ve managed to get to this point whilst remaining entirely independent (no publisher, no VC, and total control of our own IP), the sales of TerraTech directly fund its development.
All of that sounds a bit smug, but we are all well aware of the risks, difficulties and pitfalls that can plague small independent studios, and we are grateful that we’ve managed to steer around them so far. There are still lots of challenges ahead, including adding multiplayer (our most keenly requested feature), and getting the game ready for a full 1.0 release within good time, as well as plotting a path beyond that.
We could not have done this without Unity. They helped us out a lot with trial licenses and offered the best complete solution for getting TerraTech form drawing board to gamers as soon as possible. Once we had a demo we showed it to everyone and anyone who would look at it, and before long we had completed our Kickstarter and were on our way to Steam Early Access.
Our grassroots approach to marketing is going strong, we believe in a public approach to development. We invest in our community by live stream development of our game every weekday on our Twitch channel, as we have done for over two years. It is still the cornerstone of our efforts to speak to our community in addition to our own forums, Steam, social media and as many shows as we can cram into our calendar.
We maintain a very fast update schedule, typically a new update comes at the end of every two week sprint. This means that our players can see us working on new features one week and get their hands on them the next. This short loop increases the amount of feedback and interaction we have with our community. We know very quickly what is working and what is not. The ‘fail fast’ mantra is easier to follow when you have a solid group of real players to take a reading from and when you learn to take your ego out of the equation it helps you make your game better.
We believe in public development and fast cycles because we believe they increase community engagement and retention within the game, aid in word of mouth viral spread, helping us reach new players and YouTubers, and also because we have an obligation to our players to keep them informed of our plans and continue to improve the game at a good pace; some of them took a chance on us a fairly long time ago.
The community also help us in hands-on ways too; Steam, the forums, and Twitch help us keep a handle on the massive amounts of reviews, comments and chatter. Wiki mods created and maintain an awesome wiki for TT, with help from the great team at Curse. Volunteers have helped translate TT into over 12 different languages (the most recent being Danish, Kæft hvor fedt!!). We had a group of players who helped us with testing new builds before they went public, before we switched to a stable and unstable branch system. TT lends itself well to user generated content. We added a feature that will allow people to easily share their in-game creations via Twitter (using steganography, read more about that here), we scrape all of those creations and include them in the game, we also showcase the best ones each week on our Twitch stream.
There are still risks involved in being so open with our processes and plans for the game, not least the danger of over-promising. It’s important to ensure that members of the team feel comfortable talking to the community as candidly as possible, but also know not to promise features or content that is not yet being worked on, as we all know it’s hard to predict certainties when making games. Keeping a unified message amongst the team on common questions can be tricky, so the golden rules are;
If you don’t know the answer, don’t make it up, refer it to the relevant member of the team who will know, or just admit that some aspects aren’t decided yet.
Discuss the game as a team regularly, maintain a team-wide channel (we make great use of Slack) where people post their work and listen to each other at daily stand-up meetings.
Maintain an FAQ and ensure everyone knows the answer to the most common questions about the project.
Something I’d not realised before we started Early Access is the conflict between balancing the game for what is fun now vs. what the end vision of the game will be. When we started, we had a demo in which every block in our game was available more or less from the start. As the project evolved we introduced a progression that held the top tier items until they were unlocked in the later stages of the game. Normally this would have been fine, but as our players had been used to the earlier freedom, to suddenly have their toys taken away was a problem. I now try to evaluate each change to the game based not only on where we are going, but where we are now.
As the barrier between our team and our players is thin, they know what most of us are working on, most of the time. This means that when you’re working on a hotly anticipated feature it can put pressure on individual team members. It’s important for the whole team to help manage expectations and ensure that the community is steered away from singling anyone out.
We have found that by giving ourselves shorter development and release cycles, we naturally moved to prioritise shorter form features - but everyone wanted to have something nice to show off with each update. We’ve since identified the importance of taking time to tackle larger features too, which might not show results for several sprints, as each feature should be judged on its necessity to the game, rather than if it is doable for our next update.
There’s also the unknown factor, we’re experimenting with a process we’ve not tried before on TerraTech and so we have to remain vigilant as there may be other risks that we are not yet aware of. But all in all, it’s been a positive experience so far and taught us lots of new things. Find me on Twitter @KrisSkellorn if you have any questions or comments.