In Honolulu it’s still yesterday

It’s 11pm on Tuesday the 7th of June, the date of my first scheduled #AltDevBlogADay post. Well, in Honolulu it’s still the 7th. As an academic, I am like Douglas Adams loving deadlines, especially as they whiz past me. My brother, one of the UK’s leading Graphics Designers (even with colour blindness!) hates this ability to ignore deadlines: “In my Industry [women'http://globalgamejam.org/ . On hearing about it, I jumped on board immediately being one of only 3 sites in the UK that first year, but pushing and prodding and guilting others into hosting each year since. Newport, where I work, have hosted every GGJ so far, and I believe been the only site to have team members from more than one country. In the second game jam in 2010, two Flash programmers from Kentucky were unable, due to work commitments, to take part in a local site and we were asked if we could “put them up for the weekend”. This we did, and via Skype and IMs they collaborated with a local artist here in South Wales and we all learned a lot.

It was an interesting experience, and in anticipation that more inter-site collaborations might take place, I wrote the following advice for people working between different time zones:

“Why Kentucky Bourbon isn’t as good as Welsh Whisky :-P
or

How I learned to stop worrying and love speaking with people who weren’t really there

Ok, to get serious. You’ve heard about the chance for inter-jam-site collaboration. This WAS done last year, between a couple of Flash Programmers in Kentucky and an artist or two in South Wales. This was more accident than design, and was the result of the Kentuckians not being able to commit to the US times for last year’s jam and wanting to start/finish early. However, it was one of the more productive team efforts! Here’s how…

Firstly, it is only fair that a timezone separated team doesn’t get more (or less) than the full 46 hours to make their game. So, wherever your team are, either the latest starting member should be the timekeeper, with all others starting in sync – with the side effect of meaning some jam-sites might have to keep running – or a specific time to start/end be chosen that honours one member’s 5pm Friday to 3pm Sunday – but then some sites start early and finish a bit later. In our case, the Kentucky guys started early, where we finished on time.

The second issue is good communications. We had Skype set up on a projector screen with an ambient mike, so all local participants could see/hear the distant partners and vice versa for the keynote; I’d sent the Kentucky guys a link to the keynote a few minutes before, so we all watched it together. Then, after a short while, all participants wanting to make a pitch did so, including our colonial cousins. All participants, local and remote, voted on the best ideas, then we entered the horseplay section where people negotiated themselves into teams; this is just how we do it in Newport. Actually, the Kentucky team had one of the chosen ideas, and were programming oriented, so a couple of local artists (well one initially) were drafted in to complete their team. This put the concept design and lead with the remote partner, but it’s just as likely that a remote partner will be working on someone else’s ideas. In that case, it’s doubly important that the distant collaborators feel strongly included in the jam-site’s activities. Otherwise, they may get disgruntled and bow out, leaving a designer without a game. We had a set up where partners could either be seen by all, or talked with more privately by their colleagues.

Finally, the bottlenecks and pipeline of game production needs to be fitted to different time zones. When done well, people can pass over complete work to be further developed by the others, leaving a partner free to get some sleep. This will depend on what time zone people are in, and what their skills are. For example, initial design leads to the need for initial gameplay programming, while art assets can be developed, then some testing, then balance/polish/integrating final assets. Finally, if possible some proper testing and final tweaks. All these fit well with members from different time zones!

So, in summary:

1) Sync your team

2) Ensure inclusion and good communication

3) Plan to make use of different skills at different times

If you are interested in inter-site collaborations, please communicate early to other hosts, especially if you can start early and/or finish late at your venue. Remember, communication is critical, but a collaboration across zones is what the Global Game Jam is all about!

P.S. Penderyn Whisky is the best spirit in the World! It’s made in South Wales from God’s recipe for Ambrosia!”

OK, this applies to the GGJ specifically, but given that I am borrowing Honolulu time here, how can this be useful to us as developers. Well, it’s more important for us “indies” than the big studios, but given that game development is likely to be outsourced, etc, we all need to get to grips with the advantages of different time zones for our own pipelines. Imagine posting a build to your Mercurial server, going to sleep, then 8 hours later having a nice big list of juicy bugs to fix. Or posting that Maya model up, then knowing that the following afternoon that the programmers will have tested it in engine and you can confidently start rigging and texturing it. Sounds great. It’s a 24 hour a day world. And even with an 18 hour crunch day (like the one I’ve got planned for the 8th of June :-P ) I’d love to have 1/3 more productive time to play with.

It’s 11:59 on Tuesday the 7th of June in Honolulu, I’ve written 1138 words and hit the Publish button. What have I learned? Academics are bad at deadlines, because they spend all there time looking forward, not backwards*. Both are needed. Both are hard. We need to embrace the fact that we live on a large round oblate sphere.

*Unless you are a Historian.