Ludiotic

Wow, what a weekend that was! Arrived in Luton at about 2pm on the Friday, and didn’t leave again till 7:30pm on the Sunday. In between, I managed 5 hours sleep, and that’s more than a couple of people got! Before I go any further, I want to personally thank the organisers for allowing me to be there to help out, and also to the participants, for putting up with my endless interruptions of “Hey guys, how’s it all going?” I just hope that occasionally I was able to help your weekend run a bit smoother.

Ok, now I should explain what this event was all about. This was a game jam, hosted and run by Train2Game and Epic Games. At this event, around 80 or so participants would have 48 hours to create a presentable, functioning game prototype using the Unreal Development Kit (henceforth referred to as UDK). Most of these participants were students on the Train2Game distance courses for video game production, studying Art/Animation, Design, Development and QA. There were also a few students from outside of Train2Game.

It began with a number of keynote speeches, including Mike Gamble, the EU Territorial Manager for Epic Games; Dr Richard Wilson, the Chairman of TIGA; and Markus Arvidsson, lead programmer at Teotl Studios (of The Ball fame). They then unveiled the theme for the games: Guy Fawkes. They’d been grouped into ten teams, comprising of around 6-10 people, with a fairly even spread of skills across the groups. My role, as a mentor, involved checking up on the groups periodically, and whenever they had any issues, either with tools, facilities, development or anything else, we were there to help them as quickly as we could.

Now somehow, I ended up with “UDK University” on my name-badge, which I did not attend, nor do I have any experience in coding with UDK (except one afternoon where I made a two boxes and a corridor). Unfortunately, this meant that there were a lot of times in which I was unable to help the students, as their problems often involved quite complex UDK functionality. Although I did manage to help with a few logical design issues, and a couple of people managed to solve their own problems while I was sat there (I didn’t exactly do anything, but it was good to see things work!). I was also doing my best to keep the groups along the right lines regarding their 48-hour schedule, and I’ll be bringing up some of those tips a little further down the page. On the other hand, the other mentors were far more competent than I, and deserve a huge amount of credit for helping the groups realise their ambitions. In particular David Smith, Cedric Hauteville (of Supermassive Games), and the aforementioned Markus Arvidsson.

All things considered I must say that I am beyond impressed with the participants at the game jam; most of them had never worked on a game project on their own, let alone with other people! And there were only a handful that had ever attended a game jam before. Yet pretty much all of them were able to produce some very impressive game prototypes, in an intense, high-pressured environment, using software of which they mostly had very basic experience. And yes, for better or worse, many of them slept barely a wink for the whole weekend.

There are a few points I did my best to impress upon the jammers, many of which apply to game jams in general, and here are the ones I can recall now:

1. “What does the player do?”: This should be tattooed onto the back of every game designer’s hand (metaphorically…probably); At least three of the groups told me they were going to have puzzles in their game, but they mostly hadn’t thought about what the puzzles were going to be at that point. I cannot stress enough that the gameplay needs to be thought of first, and that the exact setting, character development and backstory can come later if you have time. If you don’t have gameplay, you don’t have a game.
2. Work with the tools and skills you have, not against them: One group told me they were thinking of having Limbo-style physics puzzles in their game, so I asked if anyone in their group had ever designed/built physics puzzles before. When they all said “no”, I said “Don’t do physics puzzles”. 48 hours is short enough that you’re going to struggle to make a good game with the skills that you DO have, without having to battle new, unfamiliar techniques in that time as well. This advice comes directly from my first game jam, where I suggested a similar idea; having particle jets balancing a ball, which could be navigated around mazes. It took the poor guy all night to code, and then we found in the morning that once it did work, it wasn’t actually fun as a game. So we had 24 hours to do something different. You want to know as soon as possible if your game concept isn’t quite working, so you want to code a working prototype as soon as you can. Designers should make an effort to find out early on what their team is capable of producing well, and fast.
3. Check compatibility as quickly as possible: This problem hasn’t come up quite as often in the other game jams I’ve been to, mainly because the tools were simpler. A huge problem people had at this jam was exporting models from 3DS MAX into UDK without losing all their textures. It took ages to remedy the issue, and it took people a long time to realise the problem was there at all. My advice therefore would be to check that every kind of asset you are going to use will work in your build environment; you should check a basic, textured mesh is going to appear and act how you want it to, before you spend two days building the model. This goes for audio assets, animations, video files, anything that might have a compatibility issue.
4. Set deadlines: I was pleased to see that one of the groups had been talking to each other and discussing schedules and milestones; this allowed them to easily be aware if they were taking longer than planned, and they could respond to this, either removing features, simplifying the design or just re-focusing their efforts on a certain aspect of the game. Everyone should do this, it can help you to manage your time and efforts, you can have a better, if smaller finished product, rather than one which is larger, yet clearly unfinished.
5. Keep talking to your teammates: You should continuously be checking in with them. Are they having technical problems? Do they think the game idea is still working? Do they need sleep? Sometimes they will answer “no” to that last one, and they may be wrong. If they’re making unusual mistakes and getting more irritable than usual, tell them to get some rest.
6. Air fresheners: Deodorant, scented candles, anything. Sorry to say it guys but those rooms were quite…pungent after 48 hours without a shower nearby. Most jams I’ve been to had much larger rooms for fewer people, so weren’t quite as densely populated.

I also have one or two suggestions for the management, regarding the next game jam they do:

1. Give the teams some specific game-jam advice, especially considering it was many people’s first jam. At other game jams the organisers have usually run through several suggestions, a bit like I’ve just done, to try and keep their jammers in the right frame of mind.
2. The Guy Fawkes theme is quite restrictive; it suggests a specific character, historical period, setting, and even a short plot (excuse the pun). This meant that a lot of the groups were heading along very similar lines, completely devoid of any collaboration. A good game jam theme should be sufficiently vague to allow for a wide variety of ideas, allowing people to be really creative. If I were to suggest an alternative to “Guy Fawkes” it would’ve been “treason”; this allows room for different characters, settings and narratives, but provides enough focus and specific ideas that can get the creative juices working productively (I hope).
3. Give out the written brief on the Friday night, instead of halfway through Saturday. I’m sure this wasn’t intended, but it could’ve saved a lot of confusion. This should also have clearly stated what packages were needed when.
4. A few tool-specific tips; everyone is using a complex tool that they are mostly quite new to, so a few time-saving tips would have been useful, such as “Have a master level where all the kismet is scripted”, seeing as transferring kismet from one person’s project file to another is a nightmare. Also a quick guide to the packing software would have helped ease a few minds I think.

I should finish again by saying that I had a great time working with the game jam team, and seeing what the groups came up with was a real pleasure. Being a mentor gave me a rather unique opportunity to get a good look at all of the different projects, and based off what I saw I have great hopes and expectations for all participants. I would also recommend many of them look at attending more game jams, dates for many of which can be found at http://www.gamejamcentral.com/. In particular I would recommend attending the Global Game Jam. Anyone who knows me knows how much I go on about those, but they are just so much fun and great experience for fledgling developers.

I’m hoping to meet and work with many people from this game jam again someday, and I hope to attend the next Train2Game/Epic jam. I’ll try and learn some UDK in the meantime!