Post Mortem #IGJAM16
This week I had been participating in the IGJAM16 where almost 200 particpants from 27 different countries came together to make games in 48 hours during gamescom. And it was easily the best game jam I have attended so far and an awesome experience.
The theme was “Masks” and we made Tentacle Party Crashers:
TENTACLE PARTY CRASHERS is a local co-op stealth dancing game where you play HUMANS who snuck into an ALIEN party who have a human themed masquerade ball and you and your friends want to crash it with your FUNKY DANCE. But beware the OVERSEER who tries destroy all funk - try to BLEND IN and remain undetected. Funk TOGETHER to FUNK BETTER until you’ve reached MAXIMUM FUNK and infect the alien race with your FUNK.
Watch the Trailer… yup, we have a trailer:
Listen to the soundtrack on SoundCloud and then continue reading:
A downloadable version will follow.
Our team consisted of these lovely people:
Menno Deen (Netherlands)
Jack Hoefnagel (Netherlands)
Pavlo Shelyazhenko (Ukraine)
Kolja Lubitz (Germany)
Daniel Kiedrowski (Germany)
And me… obviously.
In order to become a better jammer and share some thoughts, here is my post mortem of IGJAM16.
My duties
Although during a game jam everyone does way more than just one thing, everyone still has a main focus. I intended to only deal with music and sound design. But also ended up as tech artist, build manager, team coordinator. So it’s no suprise that there is only 1 song, 1 short loop and one more sound. But that does not mean I had less fun - I even think the opposite is true.
What went wrong-ish.
First the things that could’ve gone better
Timing
It took us way too long to focus on a game idea. Like WAAAAYY to long. While the majority was already working on prototypes, we still had no idea where we would be going. It took a few hours actually, and hours are very valuable time during 48 hours. So obviously setting a time limit for a core idea seem like a good idea.
Too few deadlines
I think that it would have been a good thing to have more internal deadlines and have a running version of the game at each deadline and then have a team meeting and play the game and also have other people playtest the game at each stage.
Missing GDD/Description
Since it tooks us such a long time to figure out an idea to work on, everyone had a slightly different game in mind when we actually started. And until the second day we didn’t notice that. A small text, like the description above, to get everyone on the same page would’ve helped a lot to define the core mechanic.
So next time, I’ll try to write a simple game description like the one above. It only takes a few minutes but saves loads of time - and gives clear direction.
Too long until playable prototype
Instead of building a very crude but fast prototype to test the very core mechanic early on, it took until the night of the second day until we had a real playable version of the game running. And so we missed a lot of valuable playtesting feedback.
So stripping down the core mechanic even more and get a playable version of the game that can be lost and/or won on the first day of the jam will be a major priority for the jams to come.
What went right
But there were also many things that worked particularly well.
Rapid Paper Prototypes
This is definitely a thing I will use in future jams. When someone has an idea, even if it’s a very vague one, just start playing it with paper.
In the beginning we just started playing games we made up almost on the go. One person would make up the rules while the others were playing the game. This made flaws in the concept immediatly clear and it was very fast to see if a game might be actually fun.
Although we ended up doing something different than we had during this phase, I can see how this will yield good results.
It’s a keeper.
GIT Workflow
From previous jams I made the experience that it’s best, if everyone works in their own branches. Not feature branches - because this is too granular for a jam, but person branches. Each team member had his own branch in git and I was responsible for keeping the development branch up-to-date when features were finished. I would update the master branch, whenever there was a solid version.
This had the benefit that I was able to resolve merge conflicts pretty fast, because I had a good overview of what things were conflicting. And while I was resolving things the others could keep on working.
It also made it easy to share functionality between persons. Like someone would just merge the branch of someone else, if they needed new functionality or assets.
Next time I will extend this into using person scenes to have even less conflicts and force the use of prefabs more. And I, or someone else, will maintain a scene where everything gets glued together.
Trello
At first I wasn’t sure how to organize the trello board and we weren’t really keeping it up to date. But in the end we had a good workflow running.
It was very simple: everyone had their own list with tasks ordered by priority. So the top task would most likely be the task each one was currently working on - but always just a small amount of tasks. We had a backlog of ideas and notes and tasks to come. So it was very easy to see what each person was doing and what they could do, when they ran out of tasks.
Also it was easy to have an eye on for potential conflicts. Like not having two programmers work on dependant components.
Instead of just archiving each card we also had a Trash list, where I would put things that we deliberately moved out of scope. Because when just archiving the cards one could be easily confused, if suddenly a task, that was there just a few minutes ago, was no longer there.
When others finished their task, they moved it into my list, so that I knew which things have yet to be merged.
And of course the Done-list. It always feels good to move stuff in there and see it growing.
The Team-Building
After the theme was announced but right before the Game Jam really started Anchel, who organizes the nordic game jam, made us do things to break the ice of talking to strangers and form teams with people we do not know - yet.
It involved hugging, introducing oneselfs within 30 seconds, find people with a different eye color, more hugging and explaining game ideas.
At the end the participants had to split up in 4 groups - each in one corner of the jam-room. Each corner represented a type of game: multiplayer, singleplayer, mobile and VR/Experimental.
That all worked extremely well and I really hope this will be done more during other game jams.
My Team
It clicked from the get-go. Although we had trouble finding an idea in the beginning it was fun. There were very productive discussions and no fights.
Having a great team during a jam is the most important aspect, because having fun is even more important than actually finishing a game. But it’s also the aspect you have the least amount of control about - so appreciate it, whenever possible!
We’ll definitely keep in touch and really hope to jam together again soon.
❤️