15 things to remember when you're going to take a part in game jam.
This article is some kind of a brain-dump of thoughts that were in my mind since I took part in GGJ2015. You can use this as a list of good advices or just a set of points that you are already familiar with. It’s written from a point of view of a developer that also had to serve a producer. Moreover, it was my first game jam and first published title.
First of all, you have to decide what you’re going to achieve.
Meet new people (team met on jam)
Learn new technology/programming language/engine
Play different/all roles (eg. no artists in range, two devs)
Deliver something like one screen demo
Most probably base your game on explosions, blood and gore
You want to:
Test your existing team (communication, management, tech/art skills).
Deliver good working and playable game.
If you chose second option, this article is for you 
To quickly introduce our jam, we had 48 hours to create a game. Actually it was 3 days from 17.00 (5 p.m) friday to 15.00 (3 p.m) sunday.
Gather a team of people you know or you work with. First of all, it would make the communication much easier. Secondly, you know exactly what to expect of your team members. In our case, we had 3 people that work together and two family members.
You will need to define strict roles and give people clear responsibility with decision power.
Designer – For creating ideas, defining corner cases and drawing wireframes.
Producer – For cutting ideas, creating list of assets/features, setting priorities and monitoring progress in time.
Developer – For implementing features selected by the producer.
Artist – For creating assets selected by the producer.
Don’t start with writing tons of code, leave it for the second day. Everything that you need at the end of the first day (first few hours) is a well defined and clear vision of the game. This means you’ll have to gather your group and perform some coffee-driven-brainstorming. Probably you’ll jump from one idea to another, leaving many ideas in the backlog, but remember to be strict – start from the base concept, then add bonus features. As a result, you’ll probably receive complicated and clever game mechanics with a lot of corner cases/levels/skills. It’s OK, but then you have to cut 80% of those ideas to leave only the simplest ones and FREEZE them. If you are ready with this, you have to be sure that every team member has the same vision of the game; to achieve that easily, you’ll have to:
Wireframes – draw them on paper. Plan user experience, screen transitions and asset postioning.
List of assets – artists have to know their progress to keep details on proper level.
List of features – developers has to know what to research and implement.
Probably one of the most underestimated factors.
Sleep well – our sleeping brakes were about 6 hours long. This still allowed us to work 8hrs on the first, 13hrs on the second and 5hrs on the third day. I felt definitely better than other jam-mates that were crunching for 20h.
Eat well – yes, you’ll need a lot of valuable fuel. Fast pizza is nothing in comparison to normal food like fruits, vegetables, bread and sweets.
Take micro breaks – it’s proven that sitting for long hours may cause problems with blood circulation. You should make breaks. Our team has been caught on making strange poses, push ups and dancing in the corridor.
Coffee – don’t overdose it. It will destroy your sleeping plans. I’ve experienced it and not recommend this.
To sum up, if you’re not a robot, you’ll have to work like a normal person. Don’t push your working hours over the limit, your brain cannot handle this.
Ok, you have your team mates next to you, you can share tasks verbally and share content on a memory stick. But it would be very useful to create some sort of product backlog and repository. You can use free tools to achieve that.
Tasks management – create a backlog and board with statuses. It would help you with two things. Firstly, all team members can see the progress. Secondly, if you own producer and developer roles, you don’t have to remember about every single task, you can just focus on programming. I can recall our board as an example. We’ve used Trello to store about 40 development tasks. Our board should be still online.
Please remember that whole team should use it. In our case, only developers used those tools. Probably, if our artists were more familiar with those tools, our work would have been much more organised. For example, assets like images and sound cues were shared by a memory stick. It was sufficient but not effective.
I know that this paragraph fits option 1 mostly, but we’ve decided to took some risk. We wanted to use some lightweight framework instead ofUE4 that we’re familiar with. Finally we’ve chosen LOVE and Lua.
If you like the adrenaline, you can lean new programming/scripting language during game jam – we did 
I’ve heard a lot opinions about code created during game jams. People say that it’s the worst spaghetti that can be created. Every programmer should be familiar with this concept, it’s hard to read and avoid errors. That’s why you should spend some time for refactoring and applying design patterns.
Pareto Principle stands for: Finishing 80% of planned work will consume 20% of time. The rest 80% of time will be spent to finish 20% of tasks. It’s so true and so frustrating. The most difficult tasks like learning Lua, LOVE and creating core classes were finished in the first 20% of total time. At this point we thought that everything went just great and we’re finishing. But then, it took us all 80% of time to push this game to a playable level. Of course, missing tasks were trivial ones like: adjusting screens, loading proper assets, playing sounds, fixing bugs, play tests and making UI improvements. It’s discouraging and gives you a lot of stress, you have to be prepared for this.
You may need this:
Comfortable slippers – OK, you can sit whole day in shoes, but at the end – don’t take them off in public Take slippers, feel like you’re at home.
Power strip – just in case, assuming that your team have 5 people, you’ll need to plug in at least 5 power cords. We needed 7.
Cup, fork, spoon and knife – even if there are some kitchen or free food oportunities available, it’s much easier to prepare and enjoy a meal with your own equipment.
Memory stick – just in case of connectivity problems.
USB cables and chargers – they are always needed, no matter where you are and what you do.
Overconfidence is a weakness. People that are not familiar with your idea may have strong difficulties in playing your game. For example, we had spent 30 minutes during the third day, catching random people and asking them if they could play our game. As a result, we’ve found and fixed about 20 issues. Believe me, it wouldn’t be possible to find those issues on our own. Photo shows our best testers.
It’s well known example of what not to do, if you’re about to present something in, let’s say, just half of an hour – don’t submit any new features on your own, stabilize existing ones only. And cooperate with rest of the team. Our mistake was that we’ve updated some background images and forgot that some of them are common for more than one screen. As a result, new background created for the main maze was also used in the ending screen Despite tha fact that this new screen is awesome, we were unaware of sideeffects. It was just not the right moment, tests were finished and game was going to be published in about few minutes.
We also broke another rule – product backlog should be frozen on the first day, right after the brainstorming.
It was probably the most challenging moment I had. It was just a few minutes before official ending, our game was ready, but we had to answer a lot of questions, fill some text boxes and upload files on web-based form. Prepare for that:
Photo – take a team photo, you’ll have a nice souvenir also.
Screenshots – you can use tools like Greenshot to make it quick. If you cannot make screenshot in fullscreen mode, don’t panic – run game in window mode.
Description – write a few words about your game.
Technology notes – describe your tools.
Installation instructions – describe how to download and execute your game.
Credits – present team members and their roles.
Mirror – submit binaries and sources into external mirrors, paste links in description fields. You’ll save a lot of stress during submitting a form.
Safety – make a copies of all texts that you’re going to type into the web browsers or use Lazarus – a lot of people are doing the same, website can hang or crash. You’re stressed – hardware also is. Something will happen for sure.
Depending of how big is your game jam, in the end of third day, you will have a few minutes to „sell” your game to the audience. There is no time for preparation, timer starts when you insert memory stick into the presentation computer!
We had 3 minutes and succeeded to show all gameplay. But! I’m afraid that our presentation was a little bit chaotic. It would be much better if we had prepared 2 minutes movie. This is also another reason why your game should be as simple a possible. Of course, executing game on another PC requires to install some prerequisities (like DirectX End User Runtime in case of UE4).
This is not related to production process, but in my opinion, well worth of mentioning: my first rule of public WiFi is not to use it. I’m always prepared and have my own mobile internet access.
Mondays are tough, but this was the worst one. I’ve decided to go to work and it was a big mistake. I’ve completed a few tasks and then had to go back home and sleep. My brain was less useful than a bag of styrofoam…
Conclusion
Taking a part in the game jam is a great experience. I’m sure you’ll find some of those advices in professional game development documents, but the first-hand experience is much more influencing.
As a dessert: If you’re interested, you can check our game here.
Enjoy !
Original article: http://mpolaczyk.pl/few-thoughts-after-global-game-jam-2015/
Read more about:
BlogsYou May Also Like
