After participating to the Spring Lisp Game Jam last year, I felt it had been a great experience that allowed me to get it touch with a brilliant community of curious and passionate developers. Naturally I decided to also join for this year's Jam.

Learning from past experience

My last game ranked 25th out of 30, which is not very good. It was also my very first game ever and a lot of the Jam time went into learning the basics of game development. My game had no sprites, the background was vomit orange – chosen for contrast with play elements during development. It played OK and the concept was unusual but not well executed.

I also used straight SDL bindings without a game engine, which is actually something I enjoyed as I love Not-Invented-Here having been primarily a PHP dev for many years (sarcasm inside…)

I remember being surprised – and not in a good way – that games ranking better than me weren't necessarily very creative. The difference seemed to really be in the quality of the execution, and the gameplay. And the packaging, but we'll come back to this.

So for this iteration, I decided to write something that played well, looked and sounded good but wasn't necessarily very creative, hopeful to make it above 20% of the submissions.

Things that went well

I decided to go with Guile, because I like Scheme, and I like GNU. And some crazy person decided once to make an official branch of Emacs with ELisp substituted for Guile. If it could do that, it could surely run my game! Guile is interpreted and that allowed rapid iteration. It also has a nice community and documentation, that helped a lot!

I went with Chickadee for my game engine, and it's really brilliant, it abstracts all the SDL stuff I had to deal with last year and makes loading spritesheets and other assets super easy. It takes care of the main input loop with its 1000 cond predicates and really gave me a leg up in implementation.

I worked with my son this time who is 9 this time around. Although he can't really code that much, I involved him in the game design, and of course the play testing. This was a great experience and gave me the opportunity to glimpse his potential when it comes to problem solving and thinking creatively.

The community around the Jam is great, on itch.io of course, but also on the Fediverse, which is where I hang out the most. It was really great to feel a synergy with others as we were all rushing to implement our little games for the Jam's deadline!

I managed my development goals with a TODO.org and ordered them as a layered MVP. This worked super well and I could conclude development one day early with a few missing TODOs but a well working game.

Things that didn't go so well

Packaging turned out to be a nightmare, much like last year's. Even though Guile is packaged for lots of distros, Chickadee isn't, and neither are the GL and SDL bindings it needs. I first used Chickadee's built-in bundler. And it works from Debian to Debian. But it's lacking some libs when going cross-distribution.

I used up some of the last day before submission to try to make a flatpak. Which I actually succeeded in making and runs cross-distribution. However submitting it to Flathub is an exercise in administrative patience and I faced with how many linting issues my manifest had, I gave up quickly.

Thanks to the extended review period, I finally managed to make a AppImage of the game that runs on many Linux distros except Arch that doesn't have libcrypt.so.1 installed by default – but easy to solve via the libxcrypt-compat package.

Things I've learned for the next Jam

Make the game easy to play

Web-based games are much more approachable. I prefer native games because I'm old enough that they tug at my nostalgia, but last year, 6 of the top 10 games were web-based. They just make playing simpler, and so get more reviews, and reviews of less irritated players. I should consider a web-based game next time

Packaging is a pain regardless of the tech. I should elect my tech before the Jam starts and figure out packaging and distribution first. That will make the jam a lot nicer and I'll get more players to review the game.

Presentation matters

When looking at the list of submissions, even though they're randomised, it's hard not to judge based on the thumbnail of the game. For example, Guilepede's thumbnail looks great and I just want to play it based on that. Yes the cover image is generated by ChatGPT (spit!) but so what?

I had people talk about my game way more than last year's, based only on the development screenshots I sent out. I got sprites from OpenGameArt from the get go and didn't have plain color placeholders this year. This really made the game stand out to anyone who looked at the images.

Avoid high concepts

Trying to reinvent a game genre isn't a good idea for a Jam. Better take something existing and add a twist to it or some gameplay differenciation. That's a lot less costly and is still creative enough to make your game stand out.

And that's it! Thanks for reading!

I agree on many points, in particular the packaging. I came to the same conclusion: it needs to be easy to run your game. AppImage is linux only which might reduce player count (though many lispers are probaly on linux). Another point for browser games: cross-compatibility. I did work on packaging as AppImage since the last jam and was hoping to test it out this time bit did not submit anything this edition due to travels but looking forward the playing the submissions and hearing wether you got more feedback with the AppImage version

I should elect my tech before the Jam starts and figure out packaging and distribution first.

This is really good advice. If you choose a lisp that doesn’t have a good out-of-the-box distribution story, it will eat up a lot of your precious jam time unless you get that solved ahead of time! The jam rules mention this already, but perhaps it could be emphasized more.

While I don’t love Appimage for general-purpose application distribution, it’s actually a pretty good fit for games, especially if they’re single-player.

I worked with my son this time who is 9 this time around.

Also really good advice! I’ve been collaborating with my kids for the past 6 years on this (they were about that age when we started!) and it’s become something of a tradition to play thru all the entries together and talk about what we like and don’t like. Kids are great at finding bugs and noticing when things don’t make sense.

Yes the cover image is generated by ChatGPT (spit!) but so what?

This will probably not be allowed next time. It’s important to credit the original creator of whatever code or art you incorporate into your game, and these tools make that impossible.

I have a kid a little older that got involved, learned to use blender from a youtube tutorial, and rendered a sword modelled from scratch bc, well, that was the tutorial! It's been fun going over comments and reviewing other entries together while discussing the next iteration of the game.