Sponsored By

A quick guide to international remote teams in game dev

Gameloft game designer Rowan McDonald-Nyland shares lessons learned in working across time zones, as well as advice on addressing the challenges and opportunities of international game development.

Game Developer, Staff

April 16, 2020

8 Min Read
Game Developer logo in a gray background | Game Developer

Rowan is a game designer who's been at Gameloft's Brisbane office for just over a year, during which he worked on Ballistic Baseball for Apple Arcade, as well as two unannounced projects.

International Relations

Hi! My name’s Rowan McDonald-Nyland, and I’m a game designer working for Gameloft at their Brisbane studio.

We recently released Ballistic Baseball for Apple Arcade, in which I worked on designing, implementing and balancing the commentary system, as well as providing balance support on other systems along the way. Prior to that, I worked as a designer at Torus Games across a variety of licensed titles, such as Ben 10: Hero Time, Paw Patrol: On a Roll and Hotel Transylvania 3: Monsters Overboard

Though headquartered in Paris, Gameloft runs 19 separate studios across the globe, not including the various smaller, specialized teams, which the studios can leverage for specific help.

I actively spend a lot of time working with teams all over the world. I want to share my experience working across time zones, as well as give some advice on addressing design problems - and taking advantage of the opportunities - presented to you when you’re in this situation.

How is it different?

There are two major issues that stem from international collaboration; the first and most obvious being the difference in time, with some offices literally being on opposite sides of the world. 

The second issue is that the other team isn’t physically there with you, which presents an entirely different set of challenges, though ones that aren’t unique to international work. 

Working in this type of environment offers plenty of these challenges, but here are some tips for overcoming them.

The importance of clarity

Designers all have stories about team members interpreting designs in surprising ways. The job is all about communicating ideas, and anyone who’s experienced these challenges can tell you how difficult it can be, even when you’re sitting next to the programmers and artists. When you introduce thousands of miles to the project, things don’t improve.

This means that good documentation practice is more important than ever. Keep documentation detail-oriented, but concise. Nobody’s going to read a 500-page game design document, even if it is technically part of their job. Keep things slim and get straight to the point.

It’s also important to not assume any prior knowledge of documentation standards. For example, it’s common for designers to use square brackets to denote a variable which should be exposed, like [this]. However, if you assume that the other team recognizes this practice, you can find yourself in a world of trouble when nothing is exposed to the design team.

Placeholder art and design docs are similarly dangerous. If it’s not extremely clear that an asset is a placeholder, it will be assumed to be final. This can lead to unnecessary work (e.g. audio being created for placeholder assets) and a lack of confidence in the product (because the placeholders look appropriately terrible). 

As with internal studio work, the trick to good documentation is to avoid relying on it. Never send off a document for another team without also communicating with them, ideally via a kick-off meeting video call.

You’ll also need to stay in touch throughout the process. Everyone will interpret your brief in a different way. As a designer, it’s your responsibility to keep an eye on progress and nudge the ship in the right direction. 

Prioritize communication during limited time overlap

Of course, keeping in touch with a team in another time zone is easier said than done. Real-time communication can be extremely limited, depending on geography. This time zone problem is perhaps most pronounced here in Australia, but can cause problems no matter where you’re working.

When developing Ballistic Baseball, we were working with the Montreal-based audio team. Unfortunately, Brisbane is 15 hours ahead of Montreal. This means zero office hours overlap. Our 8:30 AM is their 5:30 PM, whereas their 8:30 AM is our 11:30 PM. Not a great time to get up and go to work!

As such, it’s important to take advantage of whatever time overlap you can find. Since some of the audio staff would work until 6:00, we’d get into our office at 8:30 and check emails immediately. Failure to communicate quickly meant losing an entire day of work, which can be disastrous to schedules (especially if it happens more than once). 

Another effect of this is that weekends also get in the way of communication. When it’s Friday in Montreal it’s Saturday in Australia, and then we have the same problem with Monday/Sunday. So, we have an effective two hours per week (half an hour each morning for four days) to communicate easily. Any attempted contact outside of that brief window means a huge delay.

Our solution was to schedule bi-weekly calls, using the 8:30/5:30 time frame. As well as giving us a guaranteed time to talk with the other team, it also let us focus on more immediate concerns during the daily overlap. If something could safely be put off until the call, it was.

Working towards a vision

Game designers should always be working towards a shared creative vision, often created and held by the creative director (or, in smaller studios, the lead designer or producer). 

Unfortunately, international teams will naturally have less buy-in stemming from less exposure to the vision-holder. They may also be working across several projects at once; especially if they’re a specialized team, such as one that creates only audio or 3D assets.

It’s key, then, to not only establish the creative vision early, but to reiterate it frequently. 

On Ballistic Baseball, we didn’t establish the vision quickly enough. Though the game looks great, the art style can be a bit misleading. It implies a kind of NBA Jam-style “goofy” sports game, which isn’t the case (Ballistic Baseball strives to be a true-to-life baseball game). 

This had the intended effect of making the game approachable without alienating baseball fans, but we didn’t make the intent clear enough when starting work with the audio team, and the initial files we received were too “cartoonish” and light-hearted. We set up a call that involved our vision holder and never had the issue again, but the time had already been wasted. 

With or without a “vision statement” - a document that outlines the creative direction of the project - it’s still a good idea to begin any collaboration with a kickoff meeting, in which you talk through the vision. It’s also worth routinely reiterating it. 

Establish Well-Defined Roles

Somebody needs to have definitive control over the decision-making process. Depending on the team size and structure, this is usually the lead designer, lead producer or creative director (or equivalent).

It needs to be firmly established that they have the ability to say yes or no to ideas. This should also be done as early as possible - ideally during (or before) the kickoff meeting. 

This isn’t as problematic in large studios, where hierarchies tend to be well-defined. But in smaller or less formal teams, make sure everybody knows who to go to when decisions need to be finalized. 

This is done to save time, not to avoid disagreements. Disagreements mean challenging established ideas, and that’s a great thing! Designs can only grow when ideas are challenged, and teams that are less connected to the project are in a perfect place to do this.

However, somebody needs to have the power to make a firm decision that everyone can get behind, whether or not they necessarily agree. Otherwise, it’s easy to spend time bickering or work half-heartedly on a feature you don’t think should be included. 

Avoiding the “Us vs Them” mentality

This leads to the final point; avoiding negative attitudes towards each other. Much has been written on pack mentality, but this is going to be a brief, fairly broad point that applies to any two teams working together;

Remember that you’re working towards a common goal. 

Everybody involved is a professional and is trying their best to help the project succeed. This is something that seems easy, but I’ve yet to work on a project where at least some negativity didn’t threaten to creep in once two distinct teams were made to work together.

On top of that, text is a terrible format for clear communication. There’s very little sense of tone and attitude, which is compounded by non-native speakers often using more formal language. 

This loops back to a previous point - set up calls. People are rarely as angry or upset as they seem in text, and a call in the next available time slot is almost always the best way to calm things down and get everybody on the same page. 

Conclusion

To reiterate, six major points to take away: 

  • Communicate often and clearly.

  • Documentation should be high-quality, but not relied upon. 

  • Figure out the time difference, then reserve the time overlap for communication.

  • Establish a clear, concise vision, and reiterate it frequently. 

  • Establish well-defined roles to avoid wasting time when making decisions.

  • You’re all working together towards a common goal. Act like it! Be allies!

Though it brings unique challenges, working with international teams can be a great thing. They bring brand new perspectives, great ideas, and are often just as excited about a project as the rest of the team.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like