It’s been a few months now since the release of A Planet Wakes as part of the month-long (well, month-and-a-bit-long) Antholojam, and it seems as good a time as any to do a post-mortem of the jam process. This will be the first of (likely) three articles elucidating what I think were the more interesting parts of the process. This first is a list of Lessons I Have Learned – a set of guidelines, if you will, for remote game jamming with small teams.
A Planet Wakes was developed with three other people, and the project was co-ordinated entirely over Skype and Slack, including one rather memorable conversation wherein the majority of my end was carried out from somewhere beneath the English Channel on a Eurostar train. Some of these lessons we got right the first time, without any apparent effort; others were learned the hard way. The question of which lessons are which is left as an exercise for the reader.
LESSON 1: ALL WE NEED TO DO IS MAKE SURE WE KEEP TALKING
The first suggestion is also the biggest caveat. None, and I mean none, of the following will help in the slightest if you don’t use your words and stay in constant communication.
You need to know that everyone is committed from the word go. Get everyone in a skype call as close to day zero as possible. If a team member can’t find and commit to a time, how are they going to find time for the project? The immediate follow up to this is: regular check-in times. Chances are you’ll all be working on different things at different times, so a regular meeting is a must. How regular that is will depend on the jam length – we found weekly audio/video Skype meetings worked for a month-long jam.
If someone goes dark for a period of time (again, how long is project-dependent), give them one direct contact in whatever medium is most likely to elicit a response. If said response is non-existent, extremely delayed, or otherwise worries you, remember that in drastic times this option is always open to you: MAYBE DROP THEM LIKE A HOT POTATO AND FIND A REPLACEMENT. (Be aware this is SUPER context-dependent. You know your team, work with them). In, you know, a nice way. Be clear, but don’t be a jerk about it. Most people are super well-meaning but if they are Not Actually Doing The Thing then it may not be working out (for caveats, see Lesson 5).
LESSON 2: THE MORE YOU KNOW
If you’ve never worked together before, get EVERYONE to articulate, clearly and in detail, what they expect their role to be. So not “game design” but “I can do level design and scriptwriting. I like to use google docs but I don’t have much experience creating and modifying objects in the engine. I can do the boring work to copy paste my numbers but I’ll need programmer support to make objects that are easy for me to edit and tell me where they are”.
Poke holes in your team. Find out whether there are any specific skillsets missing. Make sure everyone knows who to go to if they are blocked by someone else’s work. If you have multi-taskers (and in a small team chances are you probably do) work out what is and isn’t a feasible amount of work for one person to do. Some people (by which I mean ‘me’) will enthusiastically want to contribute to EVERYTHING that falls within their skillsets. Invariably, they won’t have enough time or brain-space in the end, so reel them in early if you can.
LESSON 3: SOME HAVE GREATNESS THRUST UPON THEM
Someone has to be the official bossy boots/meeting chair. You’ll usually find that at least one team member does this naturally. When you find out who that is, nominate them into the role. If it’s official, it’s easier for everyone and decisions will get made. It’s nice to want to be egalitarian about everything but at the end of the day someone has to say ‘ok, this is what we’re doing’. This doesn’t mean you have to give up any kind of democratic approach, but it’s incredibly useful to have someone who you all agree has the power to squash circular arguments or pointless tangents.
LESSON 4: FLOAT LIKE A BUTTERFLY, STING LIKE A BEE.
For a short project with no distinct ‘design phase’ you need to be agile, but for the love of all that is holy don’t ‘use’ agile. Go read the agile manifesto. Now read it again. Get it? (Got it.) Good. Particularly for programmers it can be tempting to try to do things the way you are used to doing them at work, but unless you work somewhere tiny, those processes are probably too detailed. Forget SCRUM, because you can’t do daily standups with a remote team, especially if some of you have day-jobs or are in different timezones. If you are a lover of methodologies and like to play “pin the tail on the buzzword”, go with Kanban.
Throw away as much process as possible. Keep core things – an online space to chat in (slack is great. slack is my favourite. I loooove slack), version control (we used github but I SUPPOSE it’s possible you might want to use something not made by/for lizard people*), maybe a task board (hello trello), but remember that the core of agile is people over processes. Don’t waste valuable jam time trying to find the best processes – process will develop organically from your team dynamic.
LESSON 5: DAMMIT, BABIES, YOU’VE GOT TO BE KIND.
By definition, jams are heavily constrained project spaces, and unresolved conflicts rapidly become ticking time-bombs. You’re all in it together and you need to take care of each other, because that’s how you’re going to get the best results. Give team members the benefit of the doubt. If something is coming through badly in text, try to make a time to talk with audio. If you blow a gasket or screw up some work, apologise, clear the air, and keep moving.
Be sensitive to mental health (your own and other peoples’) as the high pressure moments of a jam can be difficult to navigate. Don’t be afraid to say if something’s giving you trouble – whether you want to go into any detail is up to you, and will depend hugely on how well you know your team members.
So this advice is a little at odds with the earlier suggestion of dropping non-contributors. Sometimes people will go dark for mental health reasons that they cannot control. In these cases, talk to the person if you can, listen to them, and look for a solution. Maybe you can cut part of their workload; maybe you can help them break down their tasks; maybe you can credit them for what they’ve done so far and ask them to handover to someone else. You may still have to ask them to step back. If things are bad, you can be a better friend to them if you’re not trying to be a team member as well.
LESSON 6: BE PREPARED
That’s ‘be prepared’ in the Scar-in-Lion-King kind of way, not the cheerful boy scout kind of way. Expect things to go horribly, surprisingly wrong. Expect other things to be unexpectedly brilliant. Make contingencies. Make contingencies for your contingencies. Every time you add something, THINK AHEAD to what it might affect down the line (oh hi, sprite system). Kill your darlings. Iterate like crazy. Let things get cut if you’re running out of time/headspace/reasonable amounts of sleep. You might have to cut things that are awesome! Or things you spent a whole week on (OH HI, SPRITE SYSTEM)! This is ok. It’s part of the jam process. Let it go. (This is the Disney song reference paragraph, apparently.)
At this point, that’s pretty much all I’ve got. Maybe this is stuff that is obvious to other people, who knows! I know a lot of it has been said before, but I also think bears repeating. Some of the pitfalls we were aware of beforehand and we STILL didn’t manage to catch ourselves before we got eaten by alligators. Don’t get eaten by alligators when you are game jamming, ok?
*full disclosure: I love git. I am almost certainly a lizard person.