This year I worked on a game for Global Game Jam for the first time. Since the team I worked with was spread out geographically, we didn't officially enter at any site, but we still worked on a thematically appropriate game together over the course of 48 hours. For me, a big part of the jam was trying to see how differently working with an entirely remote team felt compared to working in the same room at a hackathon or on a weekend side project. This was also a bit of a new experience for me because I ended up primarily working on design tasks rather than working on code.

Our game jam wasn't completely successful. We ended up with a couple of working test levels and an overall level of functionality that I'd consider something more like a tech demo than a short game. I still feel like we did some interesting work, though. You can check out a video of our game here:

What worked

Unity

Overall, I think the thing that impressed me the most over the course of the jam was just how flexible and useful Unity was for what we tried to do. I hadn't used Unity for a project since 2010 or so, and I'm really impressed with how far along it's come. Setting up test levels and creating new behaviors was quick and easy. A lot of the simple ways to do things feel like sane, correct defaults.

The only major hiccups came from the usual place: multiple people working on the same level or assets. That would've been much more straightforward if we had established some convention or explicitly locked files in our source control so that it was clear who worked on what.

Skype for collaboration

I'm not a huge fan of skype in general, but the combination of open chat room for discussing the game and issues we were having with the ability to switch to audio when we needed a bit more bandwidth was really useful. It's not a perfect replacement for being in the same room; it's still far too hard to share a quick sketch or point out something on a monitor. But overall, I felt like we were able to get things fairly quickly hashed out.

What didn't work

Inexperienced Designer

Frankly, I sketched out a design that was too big for a game jam. We had two major mechanics we wanted to implement on top of a Zelda-like action RPG setup: shape-changing (which also changed the player character's scale) and an Eternal Darkness/Don't Starve style sanity system for giving the game a creepy feeling in reaction to the player's actions. Either one of those would've been more than enough work for a weekend game. Trying to do both, in retrospect, was foolish.

Another point where my inexperience really bit is that I spent too much time working on sketching out ideas and not enough time just implementing them as levels. This is one of those frequent errors that I knew intellectually I needed to avoid, but when it came time to actually make levels, I felt like I needed to sketch out the ideas on paper before investing time in the editor. In retrospect, it would've been much more useful to just make test levels right away.

Unfamiliar Tools

Not everyone on our team came from the same background. We had a mix of professionals used to working on teams with folks more used to working alone and some people rather new to working on games period. This meant that not everyone was familiar with the same set of tools and workflow. That meant we lost a lot of time on things that weren't necessarily the best for getting the game up and running fast.

In particular, several team members not only had not used Unity before, but also didn't even have the ability to have it installed on their machines. They were still able to contribute, but not being familiar with Unity and not being able to import assets or build the game themselves meant that we needed additional people to get things in game and let everyone have an idea about how things were going. In another context, where we had a bit more time, this wouldn't be as big of a deal, but in the context of a 48 hour game it was pretty crippling.

We also had some issues dealing with git (surprise) and Trello. In both cases, the issues weren't insurmountable, but they did lead to some frustration and increased tension. Bad merges always suck, but git's idiosyncrasies make it particularly hard to deal with for people who are looking at it for the first time. Likewise, if you're used to a workflow that is more about someone assigning work top-down, a more pull based approach can leave you asking "what should I be doing?" when the best thing to do would be to look at the backlog and find something you can do.

Time zones

Geographically dispersed teams are hard, but we had some particular challenges because we were in three time zones: UK, US East Coast, and US West Coast. Since one of our goals was to let everyone have time to eat and sleep enough to stay sane, the time zone differences meant that there were big stretches where some people would be the only ones awake. It might've been better for us to organize explicit shifts.

Lessons learned

Overall I was pleased with the experience. I enjoyed getting to work well outside my comfort zone, and I think that there were some good ideas that came out of the game. If I were to do another remote-work game jam, I think the biggest thing that I'd do differently is make sure that everyone was on the same page in terms of how to work together. There's simply not enough time in a weekend to spend any of it discussing how to work. Everyone needs to be ready to start hashing out implementations ASAP.

This was also a reminder that simplicity is one of the keys to having a game that you can actually implement quickly. We didn't cut to a simple core loop fast enough and that really bit us. If we had given up on the tension mechanic earlier, we probably could've come up with something that was more playable and maybe even fun.

Making games is hard. Making games in 48 hours is harder. Making games in 48 hours when folks are trying new roles? Very hard.