A Game Jam Postmortem + Tips for Unreal Engine 4 Beginners

(Originally published by me on my LinkedIn. Thanks to teammate and friend Connor Barthelmie for helping me with some of the tips and proofreading this article.) 

I recently took part in the Unreal Engine 4 Spring Jam 2018. This involved a lot of firsts for me - first time leading a game jam team, first time working with complete strangers for a jam, first time using Unreal Engine 4 outside of following tutorials, first time taking part in a 5 day jam, first time in an Unreal jam. Also the first time I found (formed) a team before the jam instead of on the day of the jam itself. For that reason, I had time to think about the jam, and I wanted to be prepared.

Besides sharpening up my Unreal skills, I wanted to be prepared to be a good leader - to have an idea about how to plan and manage things so that everything went smoothly. To set ourselves up for success. I asked the members of an Indie Game Development Facebook group if they had any advice, and I got a surprisingly large amount of responses.

I've tried to gather my thoughts on what I've learned and present them here, especially thoughts or ideas which I felt would be less commonly found.

Long story short, our team managed a decently fun and good looking 3D game for a 5 day jam. I learned a lot about Game jams and Unreal Engine, and there is a lot I would do differently, especially since difficult to understand packaging errors kept us from submitting the game on time. We polished up the game and added some more features later to submit it for Adventure Jam 2018.

I'll group my tips by category and keep them to the point. I'm going to avoid sharing some obvious ones which you're more likely to find easily online.

Preparation -

I prepared some topics of discussion for our first meeting. This included -

I made a rough plan for us to follow -

I included key points to decide on as a team, and then keep in mind during development - Core idea, asset requirements, features, required features, extra features, and Minimum Viable Product (MVP).

We had separate boards for Programming, Art, Design and Audio on Trello, to keep track of tasks and assign tasks.

Figure - What the Trello programming board looks like after the jam.

The plan was a rough one, and it is really hard to stick to a plan during a game jam. Having a plan does help influence decisions on what to spend time on, at least a little bit.

General

Aim for a simple prototype early in the jam, and resist creating extra tasks and features until this is done. Although this is a simple one, I'd like to add that whenever you've cut down features and thought "This is simple enough", you're probably wrong - cut out more so it's even simpler. If it gets done quickly you can add what you wanted afterwards anyway. If the game isn't interesting or fun without all the extra features, its probably not suitable for the jam.

Get inspired. Look for examples of game jam games online, especially successful or universally appreciated ones. This will help you get an idea of the type and scope of game to aim for, specifically for a jam.

If something doesn't work, fix it quickly and move on - don't search for the most elegant solution. This is common advice, but it comes with a cost. In our case, "hacky" fixes that we didn't really understand did lead to the game breaking often and existing features requiring fixing repeatedly - including in the last hour of the jam. You should weigh the pros and cons and decide on this on your own.

Time differences. We were also working with a healthy time difference - I was in India, three of us were in the UK, and one was in New York. We made a spreadsheet of everyone's available times at first, which helped visualize the best times for everyone to meet. I stayed up late on most days to have a few good hours of synchronized team work. Besides that, we worked in our own time and compiled our work and updated each other on progress once or twice a day.

Doing something completely new for a Game Jam. Well not completely new, but it was my first time using Unreal for a project of my own. This led to a slow start and some lost time. It is possible to do this, if you have someone to turn to to solve common problems, as I did. Maybe don't do this if it's only a 2 day jam and no one in the team is familiar with the technology or technique in question.

A task that takes someone away for a long time is bad. This is something I learned in previous jams. If someone is stuck on a feature, especially if it's inessential or can be simplified, and stubbornly set on making it work, pull them away from it. Don't get attached to it.

Leadership

Do it yourself! This is something I learned from leading a team before. If there's something that needs to be done, especially if it's something no one else wants to do, if it's a dirty, boring, unglamourous job (Like cleaning up the level or organizing the Inspector/Outliner or directories), and it's essential to the progress of the project, even if it's technically someone else's responsibility - do it yourself! If there's a feature you want that you're certain will add a lot to the game - do it yourself! Get it out of the way, get everyone over that speed bump so you can all get back to improving the game. Don't wait for someone else to do it.

Figure - Deal with organization and folder structure.

Have clear definitions of features and the assets required. At times I hesitated to ask someone to work on some art or a feature because I wasn't sure that the work was necessary for the MVP, or that we would have time to include that feature/asset. It's better to stop and think and ask for more early on rather than at the end when everyone is stressed and there's always one more thing required. Think through the implications of design and coded features. For us, including a new power up drop meant adding a mechanic to the player, creating a rat type that could drop this power up, and asking the artist to model another rat.

Try to engage and involve everyone. "Facilitating communication" (And possibly terminating hostilities) - this was the only part of leading the team that I was confident and sure about from the start. For me, this included asking for opinions and ideas, keeping up to date with everyone's progress and issues, and helping everyone troubleshoot their problems.

Be aware of everyone's schedules. Know how much input and work to expect, and during what times, on what days.

Time difference 2.0 - Pull an all-nighter on the 4th night and just finish the game. Everyone should work together. If you're the leader, take the hit, stay up late and work when it is convenient for everyone else. Don't leave anything for the last day. Especially in a 5-day jam, everyone is burned out by the last day. Everything happens slowly. In an Unreal Jam, the 5th day is an illusion - it does not exist. It is purely for making sure nothing is broken, packaging the game, and uploading it. I wish I had done this. Instead, I asked everyone to be up early on the last day but it just didn't work - we were too burned out.

5 day Jam