I have over 8 years of experience working with remote game development teams and over that time have developed a ton of strategies for making it work. In this presentation, I describe some tools and strategies that have worked for me when working with remote teams.
8. DISTRIBUTEDTEAM STRATEGIES
• Have a clear workspace/time
• Establishing clear roles
• Clear and accessible documentation
• Regular meetings
• Well-defined pipeline
• Version control
• Community activity
9. CLEAR
WORKSPACE/TIME
• Get dressed
• Have an environment where you
do your work separate from other
parts of your living space
• Establish set hours
• Take breaks for physical activity
• Stock healthy food
10. CLEAR ROLES
• Each team member
should have 1 main role
• Programmer
• Artist
• Sound design
• Composer
• Writer
• Designer
• And so on…
14. CLEAR
DOCUMENTATION
• All of the ideas in your
game should be written
down somewhere
• Text
• Lists
• Spreadsheets
• Stats of game objects
• Diagrams
• Sketches
Image source: https://jbhannon.myportfolio.com/game-design-portfolio
15. GAME DESIGN DOCUMENT
(a living written document describing the specifications
for everything in your game)
16. GAME DESIGN DOCUMENT
(a living written document describing the specifications
for everything in your game)
20. REGULAR MEETINGS
• Establish a regular weekly or bi-
weekly time to meet with your
team
• Use Zoom, Discord, Google
Hangout, etc.
• Give “delta” check-ins describing
what’s different from last time
• Establish an agenda, stick to it,
and take meeting notes.
21. PIPELINE
• Establish “rules” to maximize
compatibility for all team
members
• Specify export formats and
procedures for assets
• Establish rules for how artwork
must be made
• What brush sizes, effects,
filters, etc.?
• Document in your project wiki
22. VERSION CONTROL
• Establish an online repository for
your project
• Establishes a safeguard against
a project breaking down
• When you try out new things,
you can create a “branch”
isolated from the main version
of the file
• You can revert files to previous
versions
25. COMMUNITY ACTIVITY
• Establish pages on social gaming
sites early on
• IndieDB
• GameJolt
• Itch.io
• Be active on social media
• Facebook
• Twitter
• Use hashtags!
• #Screenshotsaturday
• #indiedev
• #gamedev
26. DISTRIBUTEDTEAM STRATEGIES
• Have a clear workspace/time
• Establishing clear roles
• Clear and accessible documentation
• Regular meetings
• Well-defined pipeline
• Version control
• Community activity
Editor's Notes
So let’s talk about working together…
Specifically, let’s talk about what happens when a game development team works far away from one another instead of (click) in the same office together.
This isn’t really new: indie developers have been working with what they have access to forever. 2D Boy – the indie studio made up of Ron Carmel and Kyle Gabler that made World of Goo – famously based their offices in “whichever coffee shop they were in that day.” Likewise, lots of other teams have members who live all over the place.
So how do you manage a project when your team is distributed all over the world and you have to manage productivity over the internet?
So I’ve worked on A LOT of games that included some major portion of the project be done in a distributed manner, whether that be sending in art assets, managing overseas physical production, or good old version control
Today, I’m going to talk about a few strategies that I’ve learned to help manage this process. These aren’t exhaustive, but I’ve found that they can be super helpful for maintaining productivity.
First is, get dressed and have a hygiene routine to start your day. Showering and getting dressed will help you get into a mindset for productivity.
Second, if possible in your living situation, having a clearly defined workspace – try to avoid working in spaces where you rest or relax – no working in bed!
Third, establish clear working hours and walk away from your tasks outside of those hours. This is really hard for creatives, but can be good for mental health and relationships.
Fourth, take breaks for physical activity every few hours. Do push-ups or sit-ups every once in a while if you are able. Take a short trip outside, even if to step into some sunlight. Getting away from the screen is healthy and will make you more productive when you come back.
Last, stock healthy food instead of junk food
The next thing to do for your team is to give each person a primary role that they fill. This can be something like programmer, artist, sound designer, composer, and so on. On small teams, you will likely shift between roles at times – I’m primarily an artist and level designer but was once in charge of a sound team because I was the person with everyone’s contact info. Having one role to always return to will help organize tasks and maintain forward momentum.
So this is what a typical Kanban Board would look like in a physical environment. Tasks are posted on a post-it note and placed in a column that describes what state they are in: to-do, in-progress, in testing, or finished.
If we look at this game studio image again, we can even see a similar board in the background!
There are also online versions of Kanban boards that can be really helpful when working with a distributed team. This is a screenshot of Trello, an online productivity site where teams can build their own boards.
Tasks are created as “cards” which have text and other embedded information. You’ll see cards here that are tagged with colors for what type of task they are – art, programming, sound, design, and so on – as well as bubbles for who the tasks are assigned to.
Another key item for your team is to have the ideas for your game clearly documented somewhere. This can be in text, in a series of lists, spreadsheets or tables, numerical stats for objects in your game, diagrams about your game, or sketches.
This is where we talk about the Game Design Document, or “GDD”, which is a written document that you edit and update over time describing the specifications for everything in your game.
I’m not going to show a picture of a game design document right now, because if you google search “game design document”, you will find a ton of great templates and examples that would fit your needs.
The thing that I will tell you about game design documents is that while an old-fashioned Word-document-style game design document can be useful for getting your initial ideas down on paper, they’re also really hard to work with and hard to search for team members. More often than not, your team will not read your GDD.
So what should you use?
This depends on your team and what type of game you’re making. When I was working in mobile development and if the app was relatively straightforward, it was sometimes enough to draw wireframes, or draft versions of the interface, describe how they connect, and that was it. On other projects, spreadsheets can be really useful for mapping out things like story or level beats, numerical stats of individual game objects, or other data organization tasks.
Sometimes creating diagrams can be really useful. This flow chart, based on the Game Maker’s Tool Kit Boss Key diagrams, shows the flow of spaces in a level and the ways in which players will encounter them. From here, we can make map sketches and grayboxes.
My personal favorite of all of these, though, is to establish a wiki for your game using a site like Wikia or a tool like MediaWiki. Wikis are great because you can put all the information from those other methods into an easily navigated and searchable format that allows you to hyperlink pages to one another. While a linear text game design document can be hard to navigate, this takes a lot of that pressure away. Likewise, you don’t have to distribute new versions to your team when you update them.
If you go to Fandom.com, which is the new name for Wikia, you can start a wiki from their homepage by going to Wikis > Start a Wiki, then fill out your wiki’s information.
Next is to have regular communication with your team. The best thing is to establish both a team chat in an application like Slack or Discord and a weekly meeting time.
Weekly meetings should be via at least audio, if not video so you have the benefit of establishing a better connection with your coworkers. Each meeting should center around team members giving providing a “delta” check-in, which is when someone describes the changes or work they did that week. Having this responsibility keeps people accountable for their progress. Lastly, try to distribute an agenda before hand and stick to it so you don’t get lost discussing your latest favorite games, movies, etc. Having a written agenda will also give you the basis for meeting notes, which can be kept on your wiki or Google Drive.
Another thing you’ll need is to clearly establish your project’s asset pipeline. A challenge of distributed teams is that you are not working off of a single office’s set of software and you may need to take compatibility into account.
One example is if you are creating a 3D game in Unity and you have distributed 3D artists, some using Max, some Maya, and some Blender. While Unity can import all those program’s native formats, a Maya model may not be readable by someone without Maya on their computer, so you have to set rules for what formats artists should be exporting as.
This goes for how assets are made as well. Establishing pipeline rules for how assets are generated helps artists regardless of distance or individual workflow create assets that adheres to the standard set by the project’s senior staff.
So here’s the big one for a lot of folks: version control. When you have a distributed team it’s not enough to share files between one another and while cloud resources like Google Drive are convenient, they are ultimately just hard drives. What happens if that version is erased or becomes corrupted? What happens if the project something breaks? This is why version control is so important.
Version control allows you to have a place online where your team can access and contribute to the project from wherever they are by simply logging into the project’s repository. There are many ways to do version control such as Git, Subversion, or others. There are also lots of places to store repositories such as GitHub or Atlassian Bitbucket. While the standard way to access these repositories is through command line interfaces, it can be convenient to use interfaces such as Tortoise SVN or Sourcetree for those who’d rather have a windowed interface.
If you go to Fandom.com, which is the new name for Wikia, you can start a wiki from their homepage by going to Wikis > Start a Wiki, then fill out your wiki’s information.
If you go to Fandom.com, which is the new name for Wikia, you can start a wiki from their homepage by going to Wikis > Start a Wiki, then fill out your wiki’s information.
Finally, community activity can be very important for feedback and morale while you are developing your game. Eventually, all games get to the point where they’re not that nice looking, or where things are not working that well yet and for some developers, it can be easy to lose momentum.
Social media and game pages can help in a number of ways: by regularly updating on a GameJolt or IndieDB blog, you both improve visibility for your game and motivate yourself to have something new to show on a regular basis.
Showing work on social platforms and tagging it with appropriate hashtags also allows you to get feedback from outside your team and see what people respond to. Taking part in things like ScreenshotSaturday is super helpful for getting eyes on your project. Lastly, with so many people sharing work in this way, it can be a way for developers to lift one another up with good vibes, so it’s worth taking part in this.
Today, I’m going to talk about a few strategies that I’ve learned to help manage this process. These aren’t exhaustive, but I’ve found that they can be super helpful for maintaining productivity.