Got 69th on Innovation! - Ludum Dare 54 Results, Lessons Learned

Hey! Just wanted to share some thoughts about the results and lessons learned from my experience participating in my first game jam.

Results

Last Saturday the results from the event came in:

I am very satisfied with the ratings I got! I am especially happy with my rating on innovation, as I set out to make a game with a mechanic that I personally haven’t seen before.

Thank you everyone for playing, and giving feedback!

I feel the execution of my entry wasn’t as good as I had hoped, but listening to feedback, I now have an updated post-jam version that feels way better than the jam version. I am also still working on new levels for this post-jam version.

Speaking of the post-jam version, since the event is over, it is now included in the original jam page. Development of this post-jam version will keep going in that project page. Therefore, the post-jam version page will be hidden soon.

My Ludum Dare 54 Entry - Escape the Slime Lab

My entry for Ludum Dare 54’s jam is called “Escape the Slime Lab”. It’s a puzzle-platformer where the player places “lab shapes” on the level to solve each platforming puzzle, and allow their playing character (a slime) to reach the exit of each level. The catch is: The player can only place lab shapes if the shape encases the slime inside.

Example level from post-jam version

This mechanic was inspired by the theme of the event “Limited space”. This was the first idea that came to my mind; a platformer game where the player could place boxes enclosing their character (limiting their space) to solve levels. The player character would also be able to use those boxes to walljump, allowing the player to reach places they couldn’t reach. The first thing I imagined was pretty much the gif above; the player using the limited space given by the box to walljump to the exit.

I have seen platformer games where the player has to place objects to solve each level, but I don’t think I have ever seen the mechanic applied with the twist I have.

Being my first jam game, I learned various lessons about participating in this kind of events. I would like to share the ones that I feel affected me the most: “Scope and time allocation” and “Playtesting”

Scope and time allocation

Before this event, I had developed many game prototypes of different genres (none published) on different game engines, so I already had some semblance of how much time is required to develop different mechanics and game components. For Escape the Slime Lab, I knew that puzzle design was going to take a good amount of the available time, so the scope for the game would need to be a little bit limited.

List of planned features at the end of the jam. As of writing, most missing features are already implemented on the post-jam version

The first thing I did was to make a list of things I wanted to include in the game for the jam. I set for three levels and a tutorial, using at least one shape (the box), and additional mechanics of locked goals, buttons to activate them and a physics object to keep the buttons pressed. Other than that, there was the obvious game features like music, sound effects, visual effects, menus, etc.

Due to unforeseen reasons, I had to step away for around 10 or 11 hours of the time I had planned to use for the event. So I had to skip some components and rush others. In the end, I was able to finish all mechanical aspects and levels I wanted for the game (except for a level timer), but couldn’t deliver on the menus, music, and visual effects (polish in general). The player’s controller was also rushed, resulting in a less than optimal feel for the player. I also couldn’t get anyone but myself to playtest the levels either, but more on that later.

I did have that setback in time, but I also made some mistakes allocating time. I spent a lot of time making sure the code for the lab shape inventory was clean and facilitated fast level creation and iteration. I also spent too much time drawing the game’s sprites; simpler graphics for the platforms would have taken less time (and maybe looked better).

Lesson learned

Try to make a schedule and stick to it

I feel that the project was well-scoped for the event. If anything, my time allocation was the culprit here. I could’ve used some of the time I spent creating the inventory and graphics on improving the player controller and user experience. Some of that time could have also been spent on creating music, menus, and visual effects, or maybe even a couple more levels and mechanics.

That is why, I think I will try to make a schedule next time, estimating from the beginning how long each feature will take, and try to leave some extra time for any unforeseen stuff or last minute changes.

Don’t waste time writing the cleanest code

Clean code might be more readable, maintainable, and scalable, but if you are making a jam game (often simpler games), it might be wise to write code that just works. If later after the jam you decide to expand the game further, you may have to come back to rewrite it, but you won’t have the pressure from the time limit.

Playtesting

Playtesting allows you to see how others react to every element of your game. This is probably one of the most important aspects of game development because of that. You want to know how others react to your game and mechanics. You want to know how clear gameplay is to them, how accessible your game is, and how difficult they find your game. This last point is especially important with puzzle games.

Puzzle games have the distinction from many other genres in that, once you know the answer to a level, the difficulty is just how hard it is to execute it. This means that, as the puzzle designer, it’s very hard to evaluate the difficulty of your own puzzles.

During the jam, playtesting my own levels, I started to feel that the levels were way too easy. I started thinking that maybe the mechanic wasn’t that good for a puzzle. I had to remind myself of the last point to keep going: It’s very hard to evaluate the difficulty of your own puzzles.

I ended up publishing my entry without playtesting from anyone but myself.

Luckily, I was able to get others to play my game in front of me soon after publishing it. Difficulty-wise level design seemed to be about as good as I hoped it would be. I wanted all three levels to last between 5 and 10 minutes on first playthrough, and that’s about what I measured. It was satisfying to watch other people puzzled with a level for a while and then let out a satisfactory “ahh!” when they figure out the solution.

Terrible user experience on shape placement on the jam version

User experience was atrocious though. I had gotten used to my own rushed player controller and ux that I didn’t notice the obvious problems they had. As bad as it was, I wasn’t really having trouble placing shapes or completing levels. But players were, and that’s what matters.

This has been fixed for the post-jam version, but it would have been noticed before publishing if I had playtested the game with others. You can read more about the problems and changes made to the player controller and shape placement here.

Lesson learned

Get other people to playtest your game (if you can)

Get others to give you feedback early. Not only will you get a feel for how fun and understandable your game is, you will also learn how accessible it is to others. It’s even better if you can get people with different levels of gaming skills. And it’s even better(er) if you can watch your playtesters while playing, even if it is through a live stream or a shared screen. Try to observe how they react to elements of your game, and think of ways to adjust where necessary. To you, everything in your game is obvious, you made it after all, but maybe a player has a hard time recognizing that a sprite is actually a platform and not part of the background for example, or maybe they don’t notice an important HUD element and they get stuck in a level because of it.

Just keep in mind that you should listen to the problems playtesters feel they have with your game and maybe their suggestions, but you are the one that has to decide on or come up with the right solution for your game.

Improved shape placement on the post-jam version

Closing thoughts

I feel the final ratings I got were around where I expected them to be. Not spending time on the player controls and user experience certainly had an effect on the fun and overall ratings. Having music and more levels would have probably boosted them too. Participating in the jam was a very fun and interesting experience. I got to develop a game with a new interesting mechanic that I hope to expand on in the future.

Having learned these lessons, I hope to do better next time, but if I don’t, oh well, I will have learned something else.

I do recommend everyone thinking about participating in a jam to just do it. Creating stuff is very fun.

As one final note, during playtesting a friend of mine found a way to solve a level of the game in an unintended way using one less piece than expected. It’s not incredible, but to me it meant that my game allows people to express their skill in ways I didn’t expect, and that made me feel real proud. I hope you also get to have moments of pride with your creations too!

Didn’t get to record the moment my friend showed me the skip, but I still wanted to share it. So here it is as performed by me.

Unexpected level solution discovered by a friend

Thank you for reading! If you want to play the game (jam or post-jam), or if you want to keep up with its post-jam development, remember it will keep going on this page.