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.
Hi Cadence. Apparently on Arch linux you can install the `libxcrypt-compat` package, that will get rid of this issue. Otherwise I'm currently trying to build a appimage package (and testing on arch) that will include that library, but it's trying my patience...
The bundle was produced on Debian (stable), which I think has much older libraries than Arch. I'll produce a second bundle for Arch, and hopefully that will solve you all's problems.
This is unexpectedly really fun! At the beginning I thought it was a GUI to manage TTRPG campaigns, but it's actually a game where you manage parties of adventurers. I particularly enjoyed when my party of DEAD adventurers came home :D. I think it would have been nice if they had stopped reporting, forcing me to send out another party to figure out what happened to them. I think this has good potential.
It's creative. I had to do a bit of thinking before realising that I had to move the character underneath the falling balls for them to be thrown back up. A bit of help text would have been nice.
I had to compile guile-gl, guile-sdl2 and chickadee with the `--prefix=/usr` option on Debian for it to work properly. It must be a path issue but I dont fancy going through Guile's subtleties atm; the clock is ticking :).
I wrote my game last year with Chicken and SDL. It was pretty smooth and the only harder was compiling and packaging for distribution (as always...). I didn't try to interface chicken with a game engine as I was interested in working in lower level, and making a game with SDL alone isn't that hard.
The code is MIT; feel free to use and reuse and hopefully that can get someone going :D
In my view you as the player need to make a compromise as to how much you can grow and when you decide to repel particles rather than consume them. I think that makes the game quite fun. Of course it's unfinished and there were supposed to be more of an ability to shrink which didn't make the cut.
You're absolutely right that the goals conflict. Originally I wanted to add a different type of particle that would make you shrink, or add some power-ups that you could activate to do that. The game is supposed to be happening on a hard disk platter and after passing a few black obstacles, you were supposed to meet the disk read head were you had to be at least a certain size to complete the level.
Unfortunately the time restrictions had me cut off on my ambitions and so that's the best I could come up with for now. I may add the rest after the Jam ends.
For anyone who would be experiencing graphical issues. Please use the latest version (on gitlab only atm) and try running with the command line arguments `-vsync` or `-software`.
Ah, a lisp machine! I can't believe how foreign the OS feels compared to modern unix/windows, that makes one wonder what we'd be using today if the lisp machines had been a success.
Well done on taking the time to learn and write your game on such an odd system, it's great to be able to experiment with stuff we wouldn't normally get to touch.
The tech choices are really original, looking at the code had me scratching my head for a while before I understood what wisp actually is :D. It's also really cool that you got it running in a browser, it simplifies distribution a lot!
You did a pretty good job replicating pacman, and it's nice that the ghosts aren't very smart because at least I have a chance at beating this version of the game!
Hi, I just had a go at building and running the game on Debian 11 bullseye (amd64). I unfortunately cannot reproduce the bug you're experiencing. Sadly I don't own a chromebook so I'm not able to match your exact conditions. As it stands I don't have a solution to help you :(. I can only suggest that you try it out on a different setup.
With regards to the "loading time" at the start of the game, the game actually has a 3s wait time while it displays the instructions on how to play. This is probably what you're seeing as a "blank screen". The game is so simple it pretty much loads instantly otherwise.
