"Yes You Can!" - Life Lessons From a Game Jam

During the last weekend of January I've been part of the Global Game Jam 2016 - 48 hours of work, creativity and crunch time. The stated goal is to create a game, learn new stuff and of course meet new people. What makes GGJ even cooler is that it happens simultaneously all around the world - 36000 jamers from 93 countries. As Arnold Nesis put it: "My favorite event of the year is basically  'thousands of people worldwide meet for a 48 hour weekend and... work'."  (really hard).

We made "I Have A Mouth And I Must Clean" (5 cookies if you recognize the reference) - but his friends call him "IHAM". A local multiplayer PVP game about the epic struggle between good and evil - germs Vs. toothbrush, made in Unity (we uploaded the game to Kongregate so everyone can try it out).

I believe that, as in every high-intensity situation, there is a lot to learn about life and about yourself at a hackathon. So in this post I'll do my best to extract even more value from those 2 days - using examples from our own story and extrapolating.

Yes you can! (Summon creativity at will):

Creativity is a controversial subject. Some are firm believers that inspiration and ideas are somewhat magical beings - they come and go as they please, while others (myself included) hold the opinion that they are a direct result of practice, knowledge, experience, training and hard work. I think the controversy originates from the fact that no one is wrong: inspiration is indeed a random occurrence, but you can "move" the average quality and quantity of ideas you come up with both by knowing more about the relevant fields and by practicing the art of coming up with ideas.

In case you've never been to GGJ - each year there is a unique theme that's revealed at the start of the event (this year all games had something to do with "ritual") - so you can't prepare a game idea before hand. You can't wait for the muse to hit you in the proverbial shower. You have to brainstorm an idea with your group that's simultaneously: doable in 2 days, the team likes and has at least most of the required skills to create, the game doesn't suck too much. And you have to do it fast - every minute spent brainstorming is a minute not spent on designing and building the actual game.

I've attended together with my partner - Nataly Eliyahu - and we had to do it twice. The first team we "recruited" (on the spot) was both too big and had somewhat conflicting visions of the kind of game we should make - so Nataly and I split off . So we were a couple of hours into the jam and had to brainstorm a completely new "good idea" - which turned out not to be that big of a deal. Both "final" ideas were reasonably good. 

The moral of the story - if you don't feel creative - try harder :).

Yes you can! (Make an actual game):

You know - one that actually works and doesn't bug-out every 5 seconds. This is perhaps the best part of any hackathon - the realization that it is possible to build stuff 10, 20 or even a 100 times faster than large companies do it. Sure, there's less polish and some bugs/edge cases you blatantly ignored and perhaps worse architecture (but not necessarily - on that later) - but it f-ing works! After that it's hard to go back and face the abysmal inefficiency of a "normal" 9-5 job - you're stuck with the gnawing feeling of "I'm wasting my time". But maybe that's just me :)

That being said, you still have to be realistic, cost-efficient and very calculated with how you allocate your limited time. 

The first challenge we faced was being just 2 devs - with no art skill to speak of. So we chose a game that's light on art requirements (we considered getting a public image of teeth, germs and a brush and drawing the UI ourselves) but heavy on mechanics and balance (asymmetric PVP is tricky to balance well - in retrospect perhaps it's too complex for a game jam). Luckily, Jonathan Beyt-yacov, a cool artist and a great guy, heard our brainstorming session and decided to join us - so no Google images were needed - but we were ready to use the skills we have and avoid the skills we don't.

Jonathan, me, Nataly and Yaam (who did the sound editing). Nataly is holding our protagonist - the toothbrush.

Another common mistake at hackathons is to overestimate what you'll get done in any given period of time - even though it really will be more than you'd get done "normally". On top of that, people often leave no buffer time for basic QA, bug fixing, polishing, integration challenges and submission. The "solution" is basically to assume you have even less time, and be incredibly brutal when cutting down non-essential features. Continuously ask yourself "is this piece of work absolutely necessary for the game to function well?" - if there is a doubt there is no doubt. Kill the feature with fire.

A natural result of this strategy is a simpler game - which is a good thing. Choosing a relatively easy game to implement gave us the privilege of playtesting time (and - perhaps even more importantly - time to sleep). We had a working prototype ~16 hours before submission and had several players (who weren't us) try it out during that time - including the event organizer who (correctly) claimed there was a single heavily favored strategy for one of the sides. That forced us to add a new feature/mechanic to the game ~7 hours before deadline (usually a bad idea), but since there was only sound and UI work left (where I had less value anyway) - it left me free to mess around with the game core and balancing issues.

The moral of the story - you can do more than you think, but you still have to make the right choices.

Yes you can! (Make a fun game):

The kind people play for fun - not just to try it out. And when they lose/finish they want to play it again. Now that's surprisingly hard to accomplish - even if you have more than 48 hours. Luckily, Nataly decided (it was her turn to be the "CEO") we should focus on making a game with fun and active gameplay, and not an artistic game that's more focused on telling a story or sending a message - and I'm really glad she did. I'm a big believer that games can be - and some already are - a form of art, but making an "artsy" game in 48 hours that actually makes the player stop and think/feel something is even harder than making it fun and replayable. 

We went for a cartoonish/slightly over the top feel with the art style and sounds (all of which were made with our mouths - I swear!) and a fast, "arcade style", PVP action game - all in the pursuit of an experience that's "bite-size" (pun intended) fun. I mean look at it:

This is the main game screen. Yes, you're staring into a mouth the whole game.

It had to be responsive, it had to "feel good" to both players - even though their mechanics and gameplay are very different. There's a built-in balancing system - the game is a best of 5, but each time you win your opponent gets a powerup (the bars in the upper corners) - again to make it more back and forth and engaging. And that was our focus - less features, better gameplay. 

We carried this focus even into our final presentation: we were the only group to invite random people from the crowd to play our game live on stage. We knew that we had less shiny graphics and no 3D assets - our best selling points were the cheers and laughter from the crowd during the demo game.

The moral of the story - focus on the main goal and look through the eyes of the "judges". For us it was "what would feel funny and fun to the players" - so it's fairly obvious - but next time you go to a job interview don't think "what are they going to ask me" but "what kind of person/employee is the interviewer looking for?".

Yes you can! (Invest in infrastructure):

Another important decision we made was concentrating the multitude of numbers that controlled all aspects of the game into a single "settings" file. We could change the speed of the brush, germ damage, germ reproduction rate, teeth resilience and many more aspects of the game within seconds - allowing rapid iterations (which we knew we'll need due to the PVP balance challenge). For an experienced developer that might sound obvious, but in a hackathon atmosphere, where everything feels "one-time-use" and there's a very tight schedule, software architecture is often the first to be neglected. 

We even went as far as creating all the scripts and dummy functions we assumed we'll need before writing a single line of actual code. Yes, it took 2-3 hours but we fleshed out the whole architecture and - even more importantly - allowed 2 devs to work on the same small project without stepping on one-another's toes. I implemented stuff that was further away from Unity specifics since I had no experience working on the platform.

The moral of the story - even when there seems to be too much work and not enough time, planning ahead and forcing order upon the chaos is worthwhile.

"Ok ok - you can. But did it work?":

Well... Judge for yourself (another player required).

It's very (very...) far from perfect - but I think it's worthy of the title "an actual game". If your response is something like "we played a couple of times but the brush is too strong and always wins" - that's actually a good sign for me. It means you've judged IHAM according to game standards and decided it's unbalanced - not as a student project that mostly demonstrates the makers' skills/potential.

And if you think it sucks - well - I really enjoyed making it so I don't care :P. Seriously though - if you have constructive criticism then by all means tell me about it. We probably won't change anything but it will teach me something new.

Perhaps you've noticed my incredibly subtle message of "YES YOU CAN!!!". In my opinion, that's perhaps the greatest value of hackathons. The reasoning is as follows: "if I could make ~30% of a playable game in 2 days with no background in Unity - imagine what I could do if I actually knew what I was doing :)". It's not necessarily entirely correct (if Nataly wasn't an expert freelance Unity developer we wouldn't have a Unity game), but my subconscious finds it very convincing.

I understand that it's impossible to work at hackathon throughput, creativity and speed all the time. People need to sleep, rest, eat, drink, take a breath of fresh air, recharge. But wouldn't it be awesome if we could? :)

Until next time, Yes You Can!

Michael.

{If you find my ideas or analysis interesting - consider subscribing (box on the right). You'll never miss a post and I'll know I'm not talking only to myself :) }