Behind The Stone is an indie game studio based in Hamburg, Germany, founded by Slawa Deisling and Monika Rider. They are now working on their first big commercial game for Playstation Vita called Sir Eatsalot. Deisling is the Programmer and Game Designer at Behind The Stone and Rider is the Art Director. Together, Deisling and Rider are working with 4 other freelance team members to create Sir Eatsalot.

Many software developers involved with Behind The Stone initially got into the industry to become game developers out of a love for games. It’s kind of like the children’s dream of becoming a pilot, but for developers. But building a video game isn’t at all like playing one. It requires a lot of teamwork and collaboration between artists, designers, sound engineers, project managers, testers and of course, software developers. As you can imagine, managing so many different teams can be very difficult, specially when you realize that some of these teams are usually not in the same physical location as the main team. In short, managing a game development project is almost never easy.

So, why is it difficult?

There are so many things that you need to do to develop a game. Considering that there are multiple scenarios and levels in each game and each level needs different sets of artwork, soundtracks and characters, you could say that managing the development of a game is essentially managing multiple separate sub-projects. At this point, you have few options for structuring the project:

• Put everything in one project (or board) so you have everything in one place and can easily see what’s going on.
• Create a new project (board) for each level of the game so you have a clean workspace and can focus on whatever it is that you want to do.
• Create a project (board) for each team (for example, one for programmers, one for designers, and so on), so that each team can see all they need to do in one place and have control over how they manage their work.

If you put everything in one place, you’ll have tens of lists and hundreds (if not thousands) of tasks related to different teams in one place. This is good for someone who wants to have an overview of what’s going on and keep the teams synchronized, but for everyone else the result is information overload: It’ll get very messy for the rest of the team members very quickly and they’ll have to struggle to find the tasks related to them between a lot of tasks.

If you create a project for each level, things get better for the team members, but it’ll be difficult to consolidate the information and get an overview of how things are moving, what’s been done and what needs to be done. The project manager will have to struggle to keep up with all the changes in different projects and it’d be difficult to keep everyone informed about the big picture.

Creating a project for each team is probably the best solution for the teams, and the worst for the project manager. Different teams will have a totally clean workspace that only contains their own tasks, but the project manager will need to monitor several projects at any time, and don’t even think about how he’ll go about keeping the teams in sync – after all, all the teams are working to build one final product and communication is the key. Right?

Slawa at Behind The Stone – working on Sir Eatsalot with 13 levels – had tried all three methods and settled on creating a project for each team, but that solution seemed to be far from ideal:

Although we were all working on one game, because the design and programming teams had different projects, it felt like we were working on two different things. We were sensing a weird feeling of separation from each other. Have a sense of unity and closeness within the team has a large impact on team productivity. We are on the same team and knew we were working on the same project, but having two different projects had a psychological impact on the team and made communication very difficult.

Slawa Deisling

Realizing this was the start of a search for something that could help fix this issue, and the search stopped with Taskulu. In the rest of this post we describes how Slawa uses Taskulu to manage the development of Sir Eatsalot.

Keep levels inside “Sheets”

In Taskulu projects, in addition to traditional lists, you can define sheets (or boards) as an additional layer for categorizing lists.

This feature comes in handy when you’re working on complex projects like developing games.

Sir Eatsalot has 22 sheets: 13 sheets for 13 level and one sheet for each of the other necessary works (such as team organization, marketing, basic features, etc).

Being able to access everything related to the project inside the same workspace is great, but it’s not just about that. Having everyone and everything inside the same project, categorized using sheets, means that every team has a clean workspace, can see the progress of the whole project and communicate with everyone else, without ever getting lost or confused by the huge number of tasks and lists inside the project. It also helps the project manager get an overview of the whole project and track the progress of individual tasks easily.

Use “Lists” to categorize the work for each level

Slawa creates 4 or 5 lists for each level (that is, inside each sheet). These lists help with categorizing the work that needs to be done for implementing this level of the game: level design, quest design, and different segments of the level.

Another good way of structuring the lists for each sheet would be to have different lists for different teams: for example, you can create a list called “Artwork” and put all the things that the artwork team needs to do for this level in that list, programming in another list and so on. This method is more useful for larger teams and projects as it prevents cluttering the workspace and makes it easier for team members to find their own tasks.

How much time did that take?

It’s not about control. It’s not about expenses and salaries (although it can be). It’s about productivity and accurate estimations.

Wouldn’t it be nice to know how much time you’ve spent on your project in total? Which artwork took most time to create? On average how much time does it take to do the sound engineering tasks for a single level? How much time will it take to add an additional level to the game? What about a specific task? We usually don’t know these stuff, and that’s normal. It’s very difficult to estimate the time needed for doing tasks accurately.

That’s why people at Behind The Stone track the time they spend on each and every task. They know that up until today, they’ve spent over 3000 hours on developing Sir Eatsalot, that an average artwork task takes 17 hours, and that Slawa is much faster on the tasks related to algorithms than front-end and implementing animations.

But it’s not about the fuzzy warm feeling of knowledge. This knowledge helps Slawa schedule and manage the sprints more accurately, set reliable deadlines, and be on time when it comes to releasing demos and different versions of the game.

Use “Roles and Permissions” to keep things clean

Buddha once said that “Chaos is inherent in all compounded things” and that’s true. It’s hard to maintain order. Things tend to spiral into chaos and disorder over time – sometimes even accidentally. How do you make sure that your project stays clean?

To help maintain the structure and keep things clean, Behind the Stone uses roles and permissions in their project. They’ve defined a few different roles: the founders (Slawa and Monica) can do everything inside the project: See everyone’s timelogs, create or remove sheets and lists, change project settings and permissions. Others can only see the structure, create and edit lists and tasks, and look up their own timelogs.

Special thanks to Slawa Deisling for providing such in-depth insight into the work processes at Behind The Stone.