spring lisp game jam 2025 - devlog 1
2025-05-11 • spring-lisp-game-jam-2025

Another year, another Lisp Game Jam!

I'm starting this Spring Lisp Game Jam without preparing an engine before hand, so I'll have to be a little bit quick on the feet if I want to deliver something. My idea this year is to remake my previous game with completely different internals. In 2024, my game architecture was:

• RayLib (C library) acting as the main game engine renderer and loop.
• S7 scheme (C library) as the Scheme "VM" that would run the gameplay code.
• Scheme scrits for the gameplay.
• Some C glue code so I could call RayLib drawing methods from Scheme gameplay scripts.

This architecture actually worked quite well because both RayLib and S7 scheme are quite easily portable to pretty much anywhere, and using Emscripten I was able to create a web build of the game with WASM and the script files added to the virtual FS Emscripten creates (so I was easily able to test the game as an executable and build the web version).

It did had some caveats, though. Although progamming in C is quite nice, building the project was not, as both CMake and Emscripten added quite a bit of cumbersomeness in the process. I also had a nasty memory problem happening from time to time that I couldn't solve, but was certainly related to the Scheme VM bindings I created so I could allocate and free memory whenever Scheme variables were in scope (so I didn't need to allocate memory on the Scheme scripts, instead I only called (draw-texture "TEXTURE_ID") and the C engine would handle memory allocation).

This year, I feel I'll have more fun changing the entire engine but keeping most of the game intact, so I can have the same baseline to compare two different game engines. My planned tech-stack is to replace the main engine backend RayLib (C) with Macroquad (Rust), and to replace S7 Scheme with my fork of rust_lisp. This is aligned with a couple of interests that I have this year:

• I want to test using a core engine in Rust.
• I want a barebones, very simple implementation of a Lisp scripting language.
• I want to avoid using Emscripten, and export a very simple WASM project.
• I want to be able to export to different targets without much difficulty (but the finished game build is still going to be web).

Macroquad was a straightforward replacement of RayLib - it is even inspired by RayLib API, and it's very easy to port Macroquad to different targets, including Rust wasm32-unknown-unknown (compiling a WASM without Emscripten). Choosing rust_lisp for the lisp/scheme implementation was actually the hardest part of this tech stack. I initially wanted to use more complete scheme libraries such as Rust Steel or even to embed Lua so I could run a Fennel VM, but some testing made me realize I would be forced to use Emscripten for cross-compilation (most projects have some kind of dependency that requires Emscripten for WASM, such as wasm-bindgen). So I chose the simplest lisp-like implementation I could find in Rust with sufficient initial support, so I could increment it ad-hoc. The good thing is that for the initial state of the project, compilation targeting wasm is very simple.