How does an indie studio come together -- and ship games together -- if they're not located in the same city? Emeric Thoa, former Ubisoft developer and current creative director of The Game Bakers, explains what tech and techniques can make it work.
The last time I had a second of free time was over the Christmas holidays and I used that free time to write a paper about our experience making Squids and the realities of budget and profitability for an iPhone game. I wrote this postmortem because when I started as an indie, I would have loved to have such information, and I felt it was useful to share with other developers.
I was amazed by the attention it got, and I was very pleased to read all the nice comments about the article. And for those who asked: no, it didn't have a visible impact on Squids' sales, but it generated 24k unique visitors to our website in three days, which made the article more visible on Google and made the information more available to the industry, and that's always a good thing.
There's something else I would have loved to know more about before diving into indie game development: the tools and best practices for running a virtual indie game studio. By "virtual", I mean a game development studio that doesn't have an office.
This is a situation shared by many indies: you start your project from home and don't have the budget for renting an office, or maybe you're a programmer and you have an artist buddy who lives in a different place.
Lack of an office might have been a problem in 1995, but it shouldn't prevent you from making games anymore. The problem nowadays is that there are so many ways to do it, the idea of running a virtual studio can be overwhelming.
One thing I love about indie development is that it's not only about having people play our games, but also about developers freely exchanging ideas about our work and methods. So here is a bit of information about how we've tackled this issue at The Game Bakers, how we are organized, what tools we're using at the moment, and how much this stuff costs us.
The Global Game Bakery
When I think of a "real" game studio, I think of a traditional office with an open space shared by the development team. I call The Game Bakers a "virtual studio" because we are spread out around the world. The team works together all day, but remotely from different cities, countries, and even different continents.
When I was working at Ubisoft, of course I was working in real offices, but I also had a lot of experience working remotely with other studios. Splinter Cell Double Agent was made by three teams spread across three continents; Ghost Recon Advanced Warfighter was made by four teams in the U.S., France, and China.
When we started The Game Bakers, we wanted to make smaller games with a smaller team than we had at Ubisoft, but we also wanted to create high quality games with good production values, like the console games we had worked on. One of the cornerstones of this ambition was to rely on a network of talented people whom we had worked with before on console games, but who were now spread out all across the world. (Even our initial members in France were not living close to each other.)
Working with these talented people we already knew and liked would guarantee better efficiency, higher quality, smoother communication, and it would make our work more fun on a daily basis. To set up a structure that would work for day-to-day operations, we had to draw upon our past experiences with remote collaboration.
Here is our team for Squids and Squids Wild West.
The core team is made up of six people spread out in six cities, in two different countries. The total team is 19 people, five countries, and almost as many workplaces as people on the team.
The core team, working full time on the games, includes:
- 2 programmers
- 1 technical manager / data manager
- 1 artist
- 1 game designer / level designer / producer
- 1 level design intern
- 1 studio manager (funding, legal, HR, marketing)
UI, story, audio, modeling, and PR were handled by part time coworkers. Most of the team is freelance contractors. Working with contractors instead of employees is convenient in that it saves a bit of money for the studio, but it's very uncertain, as anyone could leave the team at anytime. That's a huge risk for a project where everyone is responsible of a key aspect of the game. One way to reduce this risk is to keep the projects short (shorter than a year). Being extra nice to them also doesn't hurt. Managing trust is a much more important task in a virtual studio with distant contractors than in an office where everyone is an employee.
Even if you forget the part time people and just consider the core players, this is pretty big for an indie team, and a bit of work and effort is required to keep everyone moving in the same direction. The key word here is communication.
Communication Tips and Tools
When people ask me, "What's the most important quality in a game designer?" they often expect me to answer "creativity" or "knowing games" or "understanding both the technical stuff and the art stuff". But I actually think the most important quality is being able to communicate clearly and to fire up a team with your concept. Programmers are some of the hardest people to get excited about a concept, but if they get all fired up after asking the game designer a questio -- with shinning eyes and fingers itching to start typing some code -- that's how you know you have a good game designer.
Communicating your vision and having the energy to make it happen is already difficult when your team is all working from the same place, and it can become a huge challenge when you never see these people face to face.
Talk is Cheap... But Effective!
At Ubisoft, I had this great producer who told me once, "If your e-mail is longer than five lines, just pick up the phone and call. E-mails are for cowards; they create misunderstandings and take a long time to write. Just call. Do it!" I started to pay attention and realized that she was absolutely right.
It's crucial to maintain human relationships with your remote coworkers. Voice chat allows that (in addition to saving time and being a more precise way to communicate). Within the team, we use Skype for instant messaging and conference calls, with a set of guidelines:
- We always turn Skype ON when working, so that everyone on the team can reach us.
- Every day, the whole team tries to have at least four hours of time that we're all online, even if some of us have to deal with a six-hour time difference (ex: Paris / Montreal).
- When text-chatting on Skype about a feature, if the discussion takes more than two minutes,we move to a call. Like e-mails, text chatting can feel nicer and easier, but it's really less productive.
- Video chat is nice sometimes, but really it isn't necessary. Voice matters much more.
- As the producer and creative director, I try to talk to everyone on the core team at least once a day.
- To keep everyone updated, the whole core team has a weekly meeting, during which everyone explains what he or she did during the week.
This last point is very important. How much someone sees of the big picture can be vastly different from person to person, and there's no water cooler where you can catch up with the more "informed" members of a virtual studio. The weekly meeting lasts between 30 to 45 minutes, and everyone is updated and has the opportunity to ask questions.
- Gmail account: Free + around $8/year for your own domain name
- Skype or Google Hangouts voice chats: Free
A Video is Worth a Thousand Pictures
Regarding game design documentation, I'm a big advocate of videos. If I were creating a game design scholarship program right now, I would trash MS Word and replace it with Final Cut and Photoshop. Sharing your vision for a game mechanic or a gameplay loop is way easier with a video. It gives the whole team a concrete direction... and the whole team actually watches it. Who wants to read a 10-page game design document? Not everyone on your team. But everyone wants to watch a one-minute game concept video.
Here are examples of early game design documents I did for Squids.
- Keynote PDF files with very little text, includes a generic overview of the features and VISUALS.
- A mock-up video made mainly with pictures borrowed from Google Images and assembled in After Effects. It's ugly, it's badly animated, but it gives an idea of the game. In the video you'll also see how it evolved to become the much prettier game that Squids is.
- Sharing a video on the internet: Free
Sharing this video to remote coworkers is super easy and free with YouTube or even password restricted Vimeo, and is a good example of how much remote work has changed in the last 10 years.
Getting Into Details
Once I have shared my global vision of the project and I have a set of features in mind, I usually start on the "ugly" documentation -- which is more project management, actually.
- A feature list in Excel, prioritized, and with a timeline and budget.
- A list of tickets (features specifications chunked) entered in Assembla, an online Cloud development tool that allows managing projects in an Agile kind of way
Our use of Assembla is pretty basic. We define milestones that we split into two-week sprints (a sort of "mini-milestone" with defined objectives and a working version). For each sprint I write a bunch of specs and break them down into tickets. We review them with the programmers at the beginning at a sprint and each ticket has a status: new, fixed, pending, closed. The usual stuff.
This works perfectly for the programmers, since their work is very systematic. For art production, we rely more on a simpler Excel task list and we try to check in on progress twice a week, in order to reprioritize and keep the project moving.
File Sharing, Versioning, and Source Control
For all videos, documents, and art resources, we use Dropbox. For those who don't know about Dropbox, it's a great file hosting and sharing service that basically allows you to share a folder from your computer with others, and syncs it in the Cloud.
For most of the team we managed to increase the default free space (2 GB) to around 4 GB, which is enough so far, and for the art and design team we have pro accounts so that they can store bigger files like high-resolution PSDs.
- Dropbox 100 GB account: $99/year
- Dropbox 2 GB account: Free (and Dropbox offers a lot of ways to increase the free space).
The code is hosted on Assembla, and we use Github as a source control tool. It's proven to be very efficient and reliable.
One big advantage is that everyone has a repository with complete version history locally on his or her computer, which basically means that I don't need to be connected to the internet to commit some work, and most importantly, if I somehow screw up the server data, there will always be someone with a clean version that we can restore. For a clumsy designer, it feels safer.
We use GitX on Mac -- an open source version control system with a visual interface -- to commit our changes, but many other tools exist too.
- Assembla "Single plan": $19/month.
- GitX or Github: free.
For beginners, what all this means is that all the team can work at the same time, on the same project, and then merge everyone's work together on a remote server instead of having to send manually updated files to the whole team.
Sharing Versions of the Game
Sharing builds is a universal need within the digital industry and it's not really any easier or harder for virtual studios, but it is something we needed a solution for.
We have several ways to distribute a development build.
- TestFlight is a very convenient service that allows you to send an iOS or Android version to a list of recipients. It's very easy to use, but it requires the users to subscribe, and if you want to send an ad-hoc build on iOS, you will need to add the user's UDID to your list of devices.
- HockeyApp does more or less the same, but we also use it to get crash reports from our players.
- HockeyApp: $25/month.
- TestFlight: free.
Workcamps, and Getting Drunk Together
Finally, one of the best ways we've found to improve remote work is to stop being remote for a while. We call this a "workcamp", and the recipe is pretty simple.
Workcamp Recipe, for a Six to Eight Person Team
- Rent, or find someone to lend you, a big house with enough beds for everyone.
- Make sure the house has a peaceful, countryside location, or is close to the sea.
- Make sure it's far away enough from anyone's home that nobody can go home at the end of the day.
- Make sure you'll be able to get a decent internet connection.
- Book the place for two weeks, preferably soon before a milestone deadline.
- Book plane and train tickets for everyone.
- Bring a lot of board games.
- According to your taste, bring a dedicated cook (like we did twice) or prepare to cook yourself (knowing that you'll lose at least two hours of worktime a day). Or just warm up pizzas!
- Make sure you won't run out of wine and beer.
- Repeat every six months.
The values of a workcamp are numerous:
People get to work together for real, and that bonding will last and prove useful for the next six months of remote work.
It's also extremely productive if done at the right time. Before an important milestone, work is usually well-defined and everyone has a lot to do. We've found that in this setting, everyone is fine working 10 hours a day, with a nice lunch break and a little game time at night. For us, a two week workcamp is as productive as three weeks of normal work.
It's simply the spirit. Sharing indie dev time, game time, and food and drink time with your team is always fun, but it's especially cool when there's something exceptional about it. The simple fact that the workcamp breaks the routine makes it cool, and worth the financial investment.
Here is a short sample of our workcamps:
- Transportation: Depends on your team. For us, it's around $1200.
- Housing: we managed to borrow a place a few times. We rented a great place once for $1500 for two weeks.
- Food: $300 (everyone chips in $10/day, and the studio pays for the rest. Basically, for the wine.)
We also have celebration parties when we ship a game. Here is the "baking / squid cooking workshop" we did after Squids' release:
The pros & cons in short
Here is a last bit of experience regarding virtual studios:
- Simplified ability to hire worldwide talents
- Reduced office costs
- Schedule flexibility
- No travel time to the office
- More quiet than an open space
Every week, I find myself in a situation where I really appreciate working from home. For instance, going out to buy something at 11am is something I didn't do for the seven years I worked in a company office. Another example is the ability to focus on work for four hours without being interrupted. When I was at Ubisoft, I had someone coming to my desk asking for something every 15 minutes. Lively, for sure!
- Requires an experienced core team, with very autonomous people
- Requires dedicated people (serious workers) with calm home offices
- Reduces productivity due to harder communication
- Although technical tasks are easy to manage remotely, art and game design tasks need even better communication
- Can't get a beer with your buddies after work!
Even if the team works well together and everyone's on board with the virtual studio organization, you will still miss some of the comfort of a real studio. Skype voice chat quality problems might occur. You might also feel the need to draw something on a whiteboard -- game designers love whiteboards -- but online whiteboards have not been a great solution so far.
At first glance it might seem like a virtual studio isn't worth it, but the point about having a worldwide team alone makes virtual studios a growing necessity: today, making games is frontierless.
"Real studios" are great for many reasons, and sooner or later we might move to some sort of hybrid organization here at The Game Bakers. But so far, the virtual studio has allowed me and my team to follow our dream of creating our own studio, our own games, and own our IPs.
Alongside digital distribution, a virtual studio organization is a major factor why it's now possible to make games with total creative freedom and earn a living from it. I hope sharing our methods will help some other indies who might otherwise have been scared off without even trying.