Lisp Game Jam 2024
I had time to participate in the autumn edition of the Lisp Game Jam 2024. As always it was great fun and I came in 10th place, my best result so far. This year my aim was to create a very polished game. I planned on using Raylib FFI bindings for scheme to have nice graphics and animations and sound. Also the game jam was the reason I co-authored an AppImage backend for guix pack. So of course I wanted to test using it to distribute my game this year.
You can view my submission here. It has sounds, looks relatively polished but no animations. Feedback was positive overall but in the end I fell short of my own goals. Distribution via AppImage worked well, with the distributed file being 172 MB in size. That is the price of full (linux) portability. The guix pack code packages all dependencies and only relies on the host fuse library, I believe. This means that the AppImage is always quite large.
My prior hypothesis, was that the way I distributed my past entries (zip with source code) was the reason for few people rating them. So let’s compare results across my past entries:
| Year | Game | Rank | Entries | Ratings | Total ratings for the jam | Rating/entry | %rating my game |
|---|---|---|---|---|---|---|---|
| 2022 | metabolize! | 14 | 14 | 3 | 117 | 8.3571429 | 0.23076923 |
| 2023 | defend! | 11 | 16 | 6 | 144 | 9 | 0.4 |
| 2024 | glockenball | 10 | 24 | 6 | 181 | 7.5416667 | 0.26086957 |
With this small sample set, it seems the packaging was not an issue. Across all my participations, about a quarter of the participants play test my entry. In general, one would hope, that all participants try and rate all other games. I know I try to. However, even the winner of the jam was only rated by half the participants (12 ratings). In the edition before this, there were so many entries, that the organisers decided to extend the review period from 3 day to 7 days. This should give everyone ample time to play all games. It would be interesting to learn why this is not the case.
In general, keeping the technical hurdles to try the game as low as possible is certainly helpful. It seems that browser based games are being ranked more often (though I did not crunch the numbers). I will try to build a browser game for my next participation to test this further.
In any case, I had a lot of fun, but also spent quite a bit of time. My org clock tells me I spent 30 hours and 25 minutes on my game. I wanted to develop something with rather simple game dynamics, so that I could really focus on the polish. However, I chose a type of game that I had not done before and thus ’lost’ a few hours getting the ball to move and ricochet off the obstacles correctly.
I did fix some bugs in my klecs library and made copious notes on potential
future improvements. While the core of the library seems stable, the
compose-worlds macro in particular is badly designed. I want to try
to replace it by the threading macro from SRFI-197. I did package it
for chez and it got accepted upstream, but then I realised, that the
guix chez-srfi package tracks a different (and outdated) upstream
repo. Perhaps my next guix patch?
Another challenge I had was the FFI bindings to raylib. Raylib creates an XML file describing all exported symbols along with argument types. However, I found out the hard way, that this XML is not updated in line with releases. In fact, the XML on the 5.0.0 release contained symbols not present in the shared library of the same checkout. I used a parser to automatically generate FFI bindings from the XML file (adapted from chez-raylib). This code then failed and I had to update the bindings by hand in a local copy. In fact I tried several git checkouts of the raylib repository and could not find any where the XML and shared library was in sync. Probably something to report upstream.
As usual, I tried to keep a brief devlog on itch.io which I copy below for posterity.
Devlog
Day 1
Today the Lisp Game Jam Fall 2024 is kicking off.
My goals for this jam:
- improve my development experience with guix tooling
- write a simple but very polished game
- improve my klecs ECS framework and make sure it can handle running many systems
Day1:
Created a guix.scm file which allows me to have a development environment. Later hoping to package it using the new guix patch to generate AppImage files https://issues.guix.gnu.org/73842
Day 2
Today I figured out how linear ball movement works (with movement along a vertical line being a special case). Started working on collision but that is not yet working. Hope to fix it tomorrow. And if tomorrow is a very good day I hope to get most of the game logic working so I can work on polishing everything up and adding plenty of animations and eye-candy.
Also should work on getting screenshots up soon.
Found a bug in klecs, my ECS library, which I fixed and pushed to Github.
Day 3
I am still struggling with getting the trajectory of the balls right. Simple math, but somehow I fail to get it working just right. However, we do have collision detection so the balls bounce off the walls (and off the blocks soon too I hope).
I was really hoping to get this done, however, since this is more or less the main game dynamics spending some time on it seems justified. But that also means I still have no pretty pictures to show. Hope to add background and sprites very soon.
Day 4
Man, did I struggle today. I reworked my collision dection system so that I can know from which side the ball hit the block and make it bounce off appropriately. Then I re-wrote the movement system (turns out using high-school math to define the linear equation and moving along that was not the best approach). I also scaled all movement by delta time to be independent of frame rate.
Last issues I am aware of: my launcher is launching several balls per click. Also I currently stop after the first collision is found, but should really handle every collision at each update loop.
I started at least looking for nice game art to turn this into something visually exciting. Really hoping to iron out all kinks in the engine tomorrow and getting on to making things pretty, one of my jam goals. Perhaps should have chosen a game type that I had more experience with…
Hope everybody else is doing great!
Day 5
After a good night sleep I solved most of the issues. And with most of the engine done, I could also start on the graphics. AND we have sound. Very happy with the progress so far. You can see the screenshot attached to get a feel for the style I am going for.
The background image was generated by an AI.
Day 6
So I have solved one more issue I was having, where I needed to inhibit launching more balls in-between mouse clicks.
Tasks that are left: implement win condition, solve some bugs where collision is not detected if the ball goes too fast.
Then I want to add some animations/eyecandy. And a start screen with instructions…
But now I feel on top of things again, I will be able to submit a game before the end of the Jam.
Day 7
We are geeting there. The game is now playable, I found one last difficult to track down bug in the klecs library (that I will fix after the jam is over). Still many ideas, but I am happy. Have a nice weilcome screen with instruction, custom fonts and all.
I need to handle won/lost with a nice message a a way to replay. Then package it all up. If time permits I want to add animations and some more quality of life features. But we are very close to shipping!
Day 8: Wrapping up
I am happy with the state of the game. I made some quality-of-life adjustments, playtested it a couple of times, added an end screen and a fun intro. I am still working on packaging it as an AppImage. I have written instructions oand documented asset provenance on the game page.
I will probably use the weekend do do other things and call this done today.
Did I achieve my goals?
improve my development experience with guix tooling: YES. I learned how to write a guix.scm that allows to have a dev environment and later turned it into a manifest for packaging with guix pack improve my klecs ECS framework and make sure it can handle running many systems: I found 2 bugs, one I already fixed, another I want to give more tought. I though the framework was more advanced and that I had a solution for typical game patterns. However, I discovered during this jam that it is not yet appropriate for this type of game. My game did not reach an amount of entities that would make really challenge the framework. As many other participants are using and writing about ECS (thanks ooffoe) I got more inspiration and learned some more patterns. NO write a simple but very polished game: the game is nice but not super polished. I did not add any animations (e.g. animating the catapult). But it is my first game with sound and feels very finished to me. MAYBE
Still I had plenty of fun participating and look forward to seeing and plaiyng all the other entries
Final day: &%ing packaging
Man, this evening was full of cursing. I thought I had everything in place to package my game and all libraries into an AppImage file. However, that was not the case. I came home after a long day, and nothing went as it should. I made some errors on account of being tired and others because the devil is in the details…
But finally after much panic and cursing, I have a working AppImage file to upload. It weighs in at 175MB, sorry folks. However, it packages everything needed: so it should be really portable and everybody with sufficient bandwidth should be able to run the game.
Happy playing, I know I will have much fun trying out all the other amazing entries. See you all next jam.