8 gamejam lessons learned during Reklaim development


Hello! Here's a compilation of things I either realized or knew and tried to abide by during the development of Reklaim. I hope you can find these tips useful during your own game development adventures! Some of the points are Unreal specific, but most of the paragraphs talk about general things like organisation, gameplay loop or polishing, so you can find them helpful regardless of your toolset ๐Ÿ˜

Make a mess if you can afford it

When you look at my previous Unreal jam entries, you might notice that on a mechanical level they are not nearly as complex as Reklaim. And I assure you, this is not due to lack of skill. Quite the contrary - when developing Should Have Stayed Home and Mushroom Vacuum, I was working full time with Unreal, while Reklaim was my first attempt after 10 months of not touching the editor. When you work profesionally with a tool, you tend to use your best practices from the job in your side projects. My previous entries are ridden with proper asset names, straightened nodes in blueprints, occasional C++ code, event dispatchers... you get the idea.

Making your project clean and presentable for other developers is great if it's going to be really big, but otherwise there's no point, it's a waste of your time. Code faster and extend the scope your game by cutting corners! Keep in mind though, that the mess must be deliberate, and not a byproduct of lack of experience. Also, code-wise your game can be the most terrible atrocity as long as this fact doesn't show during gameplay! So make a mess in your jam project right now!... if you feel comfortable with the tools you are using, that is.

If you are a complete newbie that downloaded the engine last week, this approach will not work for you as you will inevitably be hitting new roadblocks over and over, and the messy codebase will just make everything even more confusing, making you furious in the process.

Be warned though - one massive downside to this approach is that if you decide to continue development, you'll probably have to rewrite the entire game. I know I will. [F]s in chat only ๐Ÿ˜ฑ

Make it fun first, expand later

During the first day of Reklaim development, no actual level design was made. I spent the whole day creating a movement system that was enjoyable enough to make you *want* to explore every nook and cranny of Unreal's first person template map (which is like two corners and some boxes btw).

Even though not all of it is explained in the tutorials, Reklaim features some mechanics to increase and preserve momentum:

  • autojumping by holding the jump button allows you to skip decceleration that happens while running on ground,
  • the dash button launches you forward with a set velocity, meaning that while it's usually faster, it might slow you down if your current speed is faster than the dash speed (but it also gives you great air control, pretty much a double jump),
  • jumping when near a ledge gives you a speed boost,
  • when attached, you can detach from both types of hooks at any time - this is especially important with green hooks that you pull towards because you deccelerate during pulling,
  • when jumping from downward slopes, your velocity increases with slope angle - though there are only two spots in levels 3 and 4 that use this mechanic to make the regular jump a better option than a dash.

All of this was made during that first day, and it gave me a lot of flexibility when creating the levels later. Also worth mentioning, if you feel that your game has potential after that first day, it keeps you motivated during the entire jam.

Playtest with other people or self-imposed restrictions

While developing a game, you also unfortunately become good at it. This is a problem, because you can unwittingly make the game unbeatable for new players. Having your friends/family playtest your game is the best thing you can possibly get, but if for some reason (like an occasional global pandemic) this is not an option, then the second best thing to do is trying to playtest while putting additional restrictions on yourself. Play the game without using one of the mechanics, decide to walk on ground as much as possible even though your game is about jumping and so on. It's frustrating, but you want your game to reach as many people as you can, so do it for them ๐Ÿ˜ฃ

Nobody reads the tutorials

No, seriously. People don't care. If they aren't completely stuck, the box of text on the side that moves and makes a sound will go completely unnoticed. This is why the level itself also needs to be a tutorial, and thankfully this happens to be Reklaim's first level's sole purpose. My mistake though is not enforcing the proper execution of every move a requirement to progress further.

Here's a list of skills required to beat the game in order in which they appear in the tutorial (I recommend you to play the game side by side while reading this or watch a gameplay video by iwanPlays โค):

  • movement - pretty easy, if you don't move, you won't progress further,
  • jumping - there's an obstacle that you cannot go around, you have to jump,
  • slopejumping - this one is done badly, because the player doesn't have a point of comparison between a regular and sloped jump; thankfully everyone feels the need to collect that gem in the middle, so they tend to reattempt making the jump,
  • crouching - again, if you don't crouch, you won't progress further,
  • sliding - this one is pretty meh, semi-optional, you don't need to slide, but if you do, you will go through the tunnel way quicker,
  • hook 1 (pull) - first hook is semi-optional but the second one is mandatory,
  • hook 2 (swing) - this one is unfortunately optional and only awards you with a gem,
  • dashing - one semi-optional gap to jump through, should have made it wider to ensure proper execution, but then again I didn't want to make it too hard for new players,
  • changing direction mid-air - this one is great, because I've never seen anyone cheese it. You just have to do it properly and it's not completely unfair because the lasers below can be avoided due to a hole in the wall showing you where to go next.

(By semi-optional I mean possible to do but most likely not during the first playthrough, by design. See my speedrun of the game to see the skips in action.)

As you can see, there was a lot of planning involved, but also much, much more that could be done. One additional tip that I could add (albeit one I didn't adhere to in this project) is creating the tutorial level as the very last level in the game, because in larger projects the mechanics can change mid-development!

Know your tools and limits

During development of Reklaim, nothing surprised me. This is because I know pretty well which parts of the engine I am familiar with and which I should avoid like fire.

Despite me liking to call it custom, my movement system was still built on top of good old CharacterMovement. The list of levels and most of the balancing data is held in a DataTable. Levels were made with obsolete BSPs, because I know them better than third party blockout plugins and asset packs. Vocal sound effects were generated in FL Studio's legacy speech synthesizer. Many other cues were either recorded with my Tascam, layered and spiced with iZotope Trash plugin.

I don't know anything about particle systems, so I just used those found in starter content. There are no water particles? Use electricity. No wood? Yeah, just don't use anything...

I'm terrible with 3D modelling, so BSPs were a godsent. Not only because they allowed me to build levels quickly, but also because they have surface properties that let me control texture panning, scale and lightmass resolution. This completely skips the UV unwrapping process and allows for optimizations with lightmap resolution (albeit static lighting is still massively bloated - currently lightmaps are ~85% of total game size... ๐Ÿ˜…).

All static meshes were made in Wings 3D, because it is probably the best 3D modelling app for prototyping. The final meshes, while not very aesthetically pleasing, fit the minimalist artstyle pretty well, matching the detail-less walls.

Moral of the story: use your strengths to their fullest potential and don't waste too much time on stuff that you can't do well. Unless you are a total novice, the jam is not the time for googling!

GPU Lightmass

If you are an Unreal old timer, then the previous paragraph might have tripped an emergency alarm in your head. Why would you use static lighting during a game jam? It takes forever to rebuild everything!

Unreal has a new method of baking static lighting with GPU. I can't tell you how well Epic's solution works though, because it's not available in the engine version used for this game's development (4.22). What I used instead was Loushang's solution, which you can find here: https://forums.unrealengine.com/development-discussion/rendering/1460002-luoshua...

Not only is it faster than classic CPU lightmass, it also yields higher quality results.

Polishing, polishing, polishing

Schedule yourself some extra time for animated menus, custom HUDs, sounds, haptic feedback and game branding. I can't stress enough how much these subtle details add to the overall gameplay feeling.

If you have progress bars or number-based values on screen, animate them! Nothing in the universe happens immediately, that's why just setting the percentage of a progress bar looks cheap and unnatural. Numbers like to be incremented over time. If you toggle some image based indicators, change their color over time. If it's a heart icon, perhaps shake it or flip it when getting hit in the game. UMG makes it all really easy to do and you should take advantage of that. The player changed something in the interface? You owe them a sweet little click sound.

And the biggest, most super importantest thing I need to tell you (if you won't remember anything else, please remember this) - don't use stock engine interface! Design your own button and progress bar image, download any font that isn't Roboto. When people (especially other devs) see these defaults in your product, they will think: oh, it's an Unreal game. This is bad. You don't want them to remember that this is an Unreal game. This is *your* game.

Do keep in mind though that polishing cannot replace a good gameplay loop. Look at my previous gamejam submissions. They had responsive and fun interfaces, but the games themselves were not that fun to play. They look great on a portfolio and they would pass a code review, but in the end they are not something that you could play for more than 10 minutes.

Try to fit the theme into the game

The ideas for my previous jam submissions were made with a mindset: "okay, here's the theme, what would fit well with it (preferably with some smartass spin to make it original)?". With Reklaim, on the other hand, I knew exactly that I wanted to make a runner with turn based combat, and that was before the jam even started. The only question was, how will I fit the theme into that game.

And I do admit - making it only a part of the backstory was pretty sloppy, but it didn't matter all that much because the additional motivation of making a game that I actually wanted to do made me push myself more and end up with a better final result. Some will disagree with this tip, and rightfully so, because it's counterintuitive and not exactly in the spirit of a jam. However my (perhaps limited) experience shows that Reklaim did better as a gamejam entry than my previous submissions.


Thanks for reading this article! There will be more to come in near future so stay tuned! ๐Ÿ˜
Next week: Simplify complex movement mechanics with a state machine

Get Reklaim

Leave a comment

Log in with itch.io to leave a comment.