spring lisp game jam 2025 - devlog 2
2025-05-19 • spring-lisp-game-jam-2025
I finished the game today! You can play it at itch.io. I had a change of plans (as it happens during a Game Jam), and instead of copying the previous game I made for SLGJ 2024, I made a much simpler Snake game for this jam.
A brief description of the architecture I posted in the game page:
The engine architecture is quite simple: I use `macroquad` for the "engine backend" things (game-loop, render, input), and `rustlisp` is used as the scripting language, with the `lisp` environment extended to use `macroquad` native functions. My code mostly acts as a glue between `macroquad` and `rustlisp`, and the game logic is 100% written in the small subset of Lisp that is `rustlisp`.
Some side-notes:
- Building the game using Rust "wasm32-unknown-unknown" target was absolutely delightful. I only needed to be careful once when adding a lightweight library to generate random variables so that it would also be compatible with this target (I ended up using oorandom library), but otherwise, the generated build was very lightweight (the resulting .wasm was 807.6 kB in size, exported
.zipfile to itch.io was only 248.5 kB!), and more importantly, it was trivial to build the game locally. - In general, I had more fun with Rust macroquad than C raylib. It's a bit of an unfair comparison - macroquad is much simpler, don't have any 3D rendering API - but the way the project is set up made it much easier to integrate with my own scripting solution (playing building blocks with different frameworks on Rust is better than the C experience), and the existing API is insanely simple. I still quite enjoyed Raylib, but I'm very excited for macroquad future and role in the Rust ecosystem.
- I wasn't expecting rustlisp to be the perfect scripting solution, but alas, it was the perfect scripting solution - at least for a Game Jam I barely had time to prepare for, and had to make the game quite quick.
rust_lispwas a breeze to tweak and expand the default Lisp environment (the "native" methods available in the Lisp scripts I'd load), and I even forked the project to change some of its default environment function calls to make themelispcompatible (e.g. I replacemaptomapcar), so I'd be able to iterate on some code using Emacs instead of running the game. I didn't even tested the REPL that it's available with the framework; I tested most of the code running it on Emacs and then building the game (which took less them 300ms everytime).
I liked this setup so much I'm planning to reuse it for other gamejams, and to start mantaining my forked version of rust_lisp as a "Micro ELisp" (MEL) project. My idea is to have MEL as a very small, no dependency subset of Emacs ELisp, so that it's easy to use on the Emacs context. At least during this jam, this allowed a very fast workflow of procedurally running functions in Emacs before building the game, and it was honestly quite fun to do so.
