Good morning! I hope your Wednesday is off to a great start!
Welcome back to the twelfth (!) edition of the Traiteur Dev Blog! Today, we’ll be discussing how Raconteur works across a thousand miles — and usually more.
No falling into the sky
Excuse the lame Vanessa Carlton pun. It had to be done.
Now that that’s over with, let’s talk about TEAMWORK!
Raconteur is headquartered in Lafayette, Louisiana, but our team members span much more than a single location! People help us make games from these locations:
- New York (state)
- Washington (state)
We’ve got a diverse team with lots of different perspectives, and it makes creating games that much more interesting. But how on earth do we communicate across four time zones? Here’s how it works — I hope this can be of use to other developers who follow this blog!
We all communicate via Slack, a free messaging service. You can have public conversations with the whole group, private conversations through direct messages, and also create specific “channels” for discussion related to a single topic (as well as customizing it to have lots of optional add-ins and features!).
Two of my favorite channels at Raconteur are “bandnamesfromnickisms,” which pokes fun at the weird ways I phrase things by turning them into band names, and “batshitjackson,” a channel dedicated to random historical facts about the US’s most insane president, Andrew Jackson.
We then manage our files through Google Drive, where we store supplementary information — from design documents to certain assets to budgets and production timelines, it’s our go-to place to store information that can be easily accessed later.
But what happens when we need something more permanent, that’s not a chat room? We use Basecamp as a place for more permanent, forum-like discussion that the whole team should see. We also use it to assign our to-dos and objectives, so that everyone is on the same page and knows what to do next!
For big milestones, we’ll convene for a meeting over Skype or Hangouts, though we don’t usually have frequent meetings (because a meeting is always an activity, but rarely an actual solution!).
We manage our game’s files through BitBucket, a version control file repository. In software, it can be difficult to manage multiple peoples’ changes on a single project, which is why version control exists! Most devs are familiar with this, but if you aren’t, it’s a safe and secure system of managing lots of files and changes across many people. It’s much more efficient than, say, uploading the game files to Google Drive or using a VPN.
People can immediately grab your recent changes, work off of them, and upload their new changes too, all without causing much conflict with the core game files! If you’re an indie developer who hasn’t started using version control, we recommend using BitBucket in combination with SourceTree (which is a program that is basically an interface for the options one would use in version control manually through written commands).
Finally, this all connects through Google Apps! Drive, email, our shared group calendar where we post when we’ll be on, it all wraps together here.
What’s the process like?
Let’s take a quick example. I’m (Nick) the “business guy” who runs Raconteur as a whole, but I’m not taking the helm on Traiteur — that’s Sander, our lead programmer! We make progress in one of two ways:
- Sander will talk about his direction with the project currently, I give some extra feedback, and then he doles out objectives to other team members to make it happen; or,
- Someone on the team takes initiative and fixes problems/knocks out work without any instruction!
One of the things I’m constantly impressed by at this company is how people genuinely believe in getting the job done, and often go above and beyond. We rarely have to explicitly tell someone to do something — so I guess our process works!
What happens if there’s a problem, though? Game development is complicated and no team is without hiccups and missteps.
One thing that I have always been fascinated with is building a team structure that can naturally solve problems. If there is a bug created by someone’s recent work, we take accountability to fix the issues we create. If there’s a disagreement, we take a step back and re-evaluate what the goal is, why people are taking the positions that they do, and come up with a mutually beneficial solution that takes our different views into account.
Oftentimes, we have to look at the problem from beyond the scope of our vision and also strongly take into account what the players want, rather than that we think they would want. That’s how we diagnosed and fixed hundreds of bugs and issues in our first game, Close Order — community involvement.
That’s a wrap for this week’s post! I hope that this was an interesting insight into our processes, and can’t wait to have you back next week — we’ll have an exclusive insight just for you into an upcoming thing we’re planning!
See you then!