Congratulations everyone on another successful Ludum Dare! Now that results are out, I'll reflect a bit on my game (Holding Out). I also realized I never formally wrote a post-mortem for last event's game (Fallowtide), so I'll include that here as well.

There is actually a surprising amount of overlap between the two events, despite how different the games are, so I'll summarize into a few shared takeaways:

1. Make the player feel something
2. Play to your strengths, but maybe not too much
3. Utilize base code
4. Plan ahead
5. Sleep

Here goes!

Make the player feel something

Both Fallowtide and Holding Out are built around delivering a particular emotional experience to the player, but they do it in different ways.

Fallowtide is intended to be mysterious and uneasy. This is supported by art that is visually dark, a mysterious NPC with his face hidden by shadow, a spooky music-box soundtrack, and dialogue with ambiguous intention ("May you dream of fire and warm things"). The mechanics support this as well; the player is free to play slowly and carefully while the game gradually reveals more to the player.

Holding Out is intended to be slightly frustrating and absurd. It's built primarily off of one joke: contrasting the frantic, high-energy nature of a zombie survival situation with a comically sluggish and unhelpful customer service line. The goofy animations and stereotypical hold music add to this feeling.

Actual customer feedback for Gary was mixed:

We'll go over this feedback at Gary's next quarterly review. (Thanks @jcmonkey, @jdeedubs, @jvolonte, @yorsh, and @mpk90 for your amusing and varied comments)

One important pitfall here is to avoid accidentally undercutting the emotional experience with contradictory aesthetics or mechanics.

For instance, Fallowtide probably suffered a little bit from a lack of a lose condition; the fact there was no risk for the player limited how effectively it could apply tension. Contrast this with Sacrifices Must Be Made, the Ludum Dare precursor to Inscryption, which does the dark mystery reveal more effectively because the player is also struggling to stay alive in game.

Holding Out has almost the opposite problem; it relies a bit too much on players learning the underlying systems (like how enemy spawning/movement works and which upgrades are most efficient), and is easy to lose if you don't. Losing means you are forced to restart and hear the same jokes again, which isn't very fun. I probably should have added checkpoints or reduced the overall difficulty so most people could beat it in one run.

See also Fade, where I unintentionally made an emotional story-based game brutally difficult so that many people couldn't actually finish it to experience the story.

Play to your strengths, but maybe not too much

Everyone has different goals for Ludum Dare. Maybe you want to build a portfolio; or learn a new engine or framework; or test how well you work with a new team; or grow as a game developer in some other way. What your specific goals are will highly flavor whether this section applies to you or not.

I have two goals that have been somewhat consistent throughout my Ludum Dare experience:

• Make cool games. Test my mettle as a developer to deliver enjoyable, polished games in a short period of time.
• Try something new. Learn and grow by tackling different genres, visual styles, and emotional experiences.

Holding Out was really my first attempt at a humorous game (not counting the "so bad it's good" game I made in five hours for LD49). Since humor was the "something new," I felt okay falling back to standard 2D shooter mechanics as the base gameplay. For Fallowtide, the "new" was the visual style (non-pixel art, with a large character illustration) and gameplay (tile-based farming deckbuilder).

I think Fallowtide was probably more useful from a personal growth perspective, simply because it was so much different than my past games. For next event, I might try to focus on Innovation, which has historically not been one of my highest categories.

Utilize base code

I use PyGame for most game jams, which is a relatively lightweight Python wrapper for SDL 2. As a graphics library, it's missing most of the features available in game engines (animation handling, particle systems, physics, update/render loop). So, it's particularly important to utilize base code.

Per the Ludum Dare rules for Compo:

You’re free to use any tools or libraries to create your game. You’re free to start with any base-code you may have.

Frankly, I haven't been very organized about building base code prior to the event. However, I will reuse some code event-to-event as needed:

• Fallowtide and Holding Out both modified versions of a dialogue manager originally built for Broken Threads
• Holding Out uses some primitive objects and a particle base class from Launch Party
• Holding Out uses a sprite and animation manager I built way back in LD42 for Rampart and upgraded for GMTK Jam 2022 for Six Shooter
• Fallowtide and Holding out both use an image manager and sound manager class that I originally built for Spellcraft

Ludum Dare is about designing and building a game in a weekend. If you find yourself writing the same boilerplate every event, you probably aren't learning anything new, and it's stopping you from using the whole time efficiently. For next event, I might try to consolidate the various pieces I reuse often into a starter project.

Plan ahead

48 (or 72) hours is not a lot of time. It can be tempting to rush through the ideation and planning phase so that you can dive into the "real" work of programming your game without wasting any time.

Do not do this. You will very often make a worse game.

I'll often spend at least the first 2-3 hours weighing ideas and planning how the game will work on paper. You should have a good idea of what your main mechanics are and roughly how the game will look. If you're making a puzzle game, you don't need your final levels, but you should probably think up one or two to make sure the mechanics are actually viable for making interesting puzzles. This might feel like a lot of time, but it's way better than realizing 24 hours in that your entire game idea doesn't work and you need to start over (that said, you should pivot if you need to --- Spinnerets was originally going to be single-player, and it would have been a much worse game).

I had a long planning period for both Fallowtide and Holding Out, and I think the games benefited from it. I probably should have gone a little deeper in the initial planning for Holding Out, since I ended up making some odd design decisions on the fly (like giving the player a dodge roll when it really wasn't useful in combat with the enemy designs).

Sleep

In my experience, it's not worth sacrificing much sleep during a game jam. If I get less than ~7 hours of sleep, I'll lose that extra time in reduced productivity anyway. And be more miserable.

Conclusion

Both of these jams have been an amazing experience, and I've gotten some personal best scores in multiple categories:

Thanks everyone who played my game during play and rate. Comments and feedback are what completes the loop and leads to iteration and personal improvement. I absolutely would not be where I am today in my development journey if it weren't for this community and the support and insight it offers.

Cheers, and here's to an even better Ludum Dare 54!