Triple Hill Interactive formally came to an existence at 1.1.2015. So we are young company. However we already created a small mobile game (Dracos) in 2014. It was made as a side project of the company Comunique we worked in. Later on we were able to separate from Comunique and work on new game Bacteris, which we are pretty proud of, but it is yet to be commercially successful and I am afraid it never will be. That wasn’t it’s real goal however. We are not experienced game developers (we have experience in software development, but not in making games), and therefore we desperately wanted to know, not just how to make games but also how to create games properly. One of the first issues we encountered was preproduction. Well lack of it anyway.
When you’re creating software that is going to solve some problem for the user, you start by analysing that problem and trying to find solution, preferably with bit of visual design and user experience (UX) in mind. Intrinsically it doesn’t need to be fun. When making a game you need to find fun part of the concept and it’s only achievable by iterating. Making concepts, finding good stuff, throw away bad stuff, repeat. This process is obviously time consuming even when iteration
is quick. Asset creation is halted during that time, since you basically don’t know yet which assets you’ll need to create and even how to create them.
We are trying to solve this problem by working on two games at a time. It might sound counter intuitive to solve time loss by adding another project on top of the existing one, but let me elaborate. If you work on games, and have released one, then you are probably doing the same thing already. Well if you are AAA developer or already established studio, this is probably something you already know. For us, it’s knowledge found by working on our games.
How we get here?
After Bacteris was released, we needed to support it by bug fixing and designing new levels. At the same time, we were doing some prototyping from our “backlog” of ideas. That’s where it hit us. We are working on two games already! One is finished and other is not even a game, just a concept, but it’s work, right? From that moment we were trying to change our mind sets. When working on one project (and you might know it can get numb when you are working on same project for long time) it’s fresh air for mind to, just for quick moment, jump on another. Even if it’s only at brainstorming level. So we divided our team to two parts. One that is fully working on game in production and one that is working on prototypes. Team working on prototypes is also supporting games already released. Of course anybody in our company can give an opinion on what is right or wrong with any project and we use that feedback to create better games.
However this approach is not without it’s issues. You have two running projects each with it’s tasks and on top of that released projects need support. This requires tools for planing, asset version management and development process management. We decided to use JIRA for tasks, bugs and improvements. Then we started to use “sprints” as a methodology for progress control and feature management. There I would like to say that none of us is expert on agile methods. We just tried customized idea of what are “agile methods”.
“Production team” is working in two week cycles. We sit down before each cycle and go through the latest iteration of a game. We look through what has changed from previous build and if it is looking/feeling better. Then we try to find what should be done in next cycle, create corresponding tasks and start another cycle. This review process gives us real feel of accomplishment and progress, which is quite important in long running project.
We use GIT on our internal server to track assets, and doku-wiki system as documentation platform (for design documents, code snippets, implemented systems – AI, pooling, etc.). We feel that it is important to gather and store as much knowledge as possible into our wiki platform. Using code snippets and systems already created for previous projects help “prototyping” team with their work. Creation of generic “game framework” is something we need to put together into package that will be used in our projects later on. After the first game is finished and released, second one will be moved from prototype stage to production, giving space to another prototype and cycle continues.
All things described here are approaches we find useful and work for us. If we’ll be able to expand our team in future, then those methods are something
we want to build on.