(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 -

• Introductions and interests
• Theme of the Game Jam
• Brainstorming ideas
• Team name and Game name
• Roles
• Schedule

I made a rough plan for us to follow -

• Day 1 – Prototype
• Day 2 – Prototype + some art/sound
• Day 3 – Finish the base game
• Day 4 – Polish/improvements
• Day 5 – Extras/features

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.

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.

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

How is a 5 day jam different from a 2 day one?

It's a bit more relaxed, but you're completely burned out by the last day. You can aim for a more ambitious game and prototype, but you're still likely to overshoot. You may have days to work on features even after the MVP is done, but the 5th day is an illusion (As I mentioned above).

I felt that staying up the first night discussing, planning, and getting development started (Especially with the time difference) was a good idea. You'll be a little tired the next day, but the second day isn't so essential.

You will be tempted to start slow and lazily. This is partly unavoidable, but be aware of it. At the same time, try not to burn out half-way through by overdoing it. Work healthily, with some exercise, fresh air, food, water, and sleep. Or at least some combination of those. On some days.

Unreal Engine specific

I had almost exclusively used Unity for Game Development for the past 3 years (Besides some C++ work). My only experience with UE4 was through following a C++ UE4 course on Udemy. Especially coming from Unity, there were a lot of incorrect assumptions that I made.

Expect a slow start. Setting up a new project with Unreal takes time. Once the basic framework is in place, things will speed up naturally.

Using C++ for a jam is possible, but... expect a slow start. Setting up a game framework in Unreal is difficult and slow, at least as a beginner. There are errors which make the engine crash and are almost impossible to track unless you have someone more experienced to ask. Some of these are normal C++ errors (which really should pop up during compilation), such as declaring a function and not defining it, or accessing a vector's elements without initializing them. Another one was because the CreateDefaultSubObject has a TEXT parameter, and the parameter HAS to be unique. If you copy one of Unreal's cpp files which are part of the template, as I unwittingly did, you'll crash the editor with no errors! But after the first two days everything went MUCH smoother and faster. The macros are hard to figure out and I got the feeling that documentation on some of them is out of date. But after a while you'll understand when to use which one, and things will go smoothly.

CollisionComp = CreateDefaultSubobject<USphereComponent>(TEXT("SphereComponent"));
//If you copy this line of code from the Projectile class in the First Person C++ template
//(To make your own projectile, as I was trying), remember to change the TEXT value

Expect to use Blueprints at some point or the other. Developing a game using purely C++ isn't supported very well in Unreal. You would need experience and in-depth knowledge to be able to do that. More often than not, when you look for solutions online, they will be Blueprint specific. Even Unreal's C++ tutorials incorporate Blueprints for more than a few tasks.

Mixing Blueprints and C++ is possible. BlueprintImplementableEvent is a lifesaver and also pretty much necessary. This lets you communicate between C++ code and Blueprint code.

Compile times can be really long. Compiles are rarely slow in the latest version of Unreal, but this was a bigger problem for me with older versions.

Packaging. Just because the game compiles, does NOT mean it will package without errors! There are some errors which only show up during packaging. Also, packaging is slow! Ours took 10-15 minutes. There was someone on twitter who took 4 hours to package a single level game. Packaging errors are non-specific and hard to understand. Ours just said "Error Code - Unknown Error". Scrolling up the log showed 10-15 yellow warnings and finally 2 red errors (Why couldn't these just have been at the bottom instead of the "Unknown Error" code?!). Our errors were because of specific files, mostly .uasset files. This is explained below in the Source Control section.

Unreal Engine 4 and Source Control -

Use source control. To be honest, I hadn't used source control for a game jam before this one. The time and effort didn't feel worth it for 2 day jams. You'll manage a surprising amount of work in 5 days though, and source control will help overcome several major problems during development, such as collaborating remotely, revision points for lost progress and the ability to test out ideas without compromising the project.

Practice using Source Control before the jam. I hadn't properly used Source Control with UE4, or the Git client we were using, before the jam. This cost me, and at times the team, several hours on a few occasions.

Git and Custom Events in Blueprints. Often when we merged branches or pulled changes, existing features seemed to inexplicably break. Quite often this was because of Custom Events in Blueprints, specifically those overriding BlueprintImplementableEvent functions from C++. Unreal replaced them with generic "CustomEvents" in Blueprints, which stopped them from being called. Replacing the wrong events with the correct ones fixed the issue.

Git and LFS, and some common issues. LFS is required. LFS does not work. We had a lot of trouble setting up LFS with Git and Git Kraken. Later, I'd often have one or two files missing in my UE4 content browser, which caused errors, but ONLY during packaging. Another sign of this is if you open a BP but can't save your changes to it due to an error like "Blueprint only partially loaded". The file will be present, but will be just a 0 kb pointer, and won't be read by Unreal. The solution is to find these 0 kb files, delete them, and pull/LFS pull again. If this doesn't work, clone the repository again.

Two people should not be working on a blueprint at the same time. Git does not do a good enough job of merging changes to a blueprint, whether it's a map, blueprint or something .uasset. Decide who is working on the main level at a certain time, and everyone else can work on their own work and test them out on different maps. This does cost a lot of time on the last day, so plan accordingly.

Bonus - Be careful with your commit messages. I once got extremely frustrated and had "Stupid JSON $%!%" as a commit message on a year-long project (For a problem which turned out to not be because of JSON). I later spent a day figuring out how to rename this old commit because I had to share the git repository with a prospective employer.

Common errors (UE4) -

Editor warnings, files missing on opening the project after a pull or merge, project doesn't open in Unreal. There are several steps that work for most generic errors. 1) Switch to master 2) Pull 3) LFS Pull 4) Delete the VS files and regenerate VS solution 5) Delete binaries, .vs, saved, intermediate, build, saved folders and .vc.db files and try to open the .uproject again 6) Clean the solution and then Build again in VS 7) Once someone had to reinstall VS 8) Finally if nothing works, or even if you just don't want to bother with all of this, just try cloning the repository again - the rest isn't even worth the effort.

Updating a project to 4.19. This actually requires opening some files and editing them, otherwise the project won't convert or open, and neither will the VS solution. Google "Unreal engine convert project to 4.19".

If you're new and don't know the 100 different reasons the Editor may crash without errors, or if you make some C++ errors which aren't compile-time once in a while, commit often and just checkout an older commit if something breaks. You'll probably figure out your error.

Final thoughts

A game jam can be an amazing experience, and you can get a lot out of it by preparing for it in advance. Unreal Engine 4 can be difficult to use for a beginner. A lot of Unreal's C++ tutorials don't give good explanations, but the Unreal Course by Ben Tristem and Sam Pattuzzi on Udemy has in-depth and beginner friendly explanations and a great teaching style. I highly recommend checking it out.

I've made some criticisms and complaints about Unreal Engine in this article, but I thoroughly enjoyed and appreciated the experience I had. Overall, I'm happy with how well-structured Unreal is, but I feel it isn't as well-documented as Unity, and is inflexible about how you use it. I believe Unreal would work extremely well for large and long term projects.

Please let me know if you found this article interesting or helpful, or if you would like more detail on any of the points mentioned.

Leave a comment or find me on LinkedIn.