Few Thoughts After Global Game Jam 2015

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.

Option 1

You want to:

Option 2

You want to:

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.

1. The Team.

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.

2. Team Roles.

You will need to define strict roles and give people clear responsibility with decision power.

3. Brainstorming.

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:

4. Health.

Probably one of the most underestimated factors.

5. Tools.

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.

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.

6. Learn New Tech.

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 

7. Code like a sir.

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.

8. Pareto Principle.

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.

9. Useful gadgets.

You may need this:

10. Play Tests.

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.

11. Ninja Commit.

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.

12. Submit form.

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:

13. Presentation.

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).

14. Public WiFi.

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.

15. The day after.

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/