Post-mortem on Magnetic Trek

The concept of Magnetic Trek only started two days before the Game Jam started only. As you can see in my notes [PDF], the first concepts of the game had it as a top-down scroller. The player's particle would collide with either good or bad particles, the good ones making it grow, and the bad making it shrink. At the end of the level, the player would encounter the disk's read head, where they'd need to be big enough to be read, or lose the stage.

Things evolved quickly in the 10 days of the challenge, and the concept switched to a side scroller instead. For expediency's sake, I opted to use coloured squares instead of textures – a decision that I came to regret.

The core game concept revolves around magnetism. Charged particles either attracting or repelling depending on their polarity. I think that makes for interesting game-play opportunities that I haven't seen used much in the wild. The first attempts at implementing magnetism involved a square of randomly charged particles surrounding the player particle as seen in the notes.

By the time the core concepts were working, I was only 2 days away from the Jam's end, and I could only spend max. 2h per day to complete the game. My original plan included shrinking particles and a level boss that the player had to be large enough to pass. But that all got cut off and instead I introduced the obstacles – aka the black bars of death – after seeing some microscopic images of the surfaces of hard drives.

I made the choice of using Chicken Scheme because I hadn't yet had the opportunity to use Scheme. By far the Lisp I'm most experienced with is Elisp (in Emacs), and Common Lisp second. So that was a nice learning opportunity. My choice went with Chicken as it is compiled to machine code rather than interpreted, which is a nice change as my day job involves interpreted languages already.

Chicken has modules called eggs that can be installed easily with the chicken-install utility, which is nice. Those modules then get compiled in the executable right away when indicating to the Chicken compiler that we want a statically-linked executable, which makes distribution simpler.

To avoid memory issues – even though chicken is garbage collected – I have avoided spawning entities excessively. To that end, the game actually has a set number of particles which it reuses whenever one goes off-screen. It also does the same thing for obstacles, of which there are only ever 3.

In the end I used a statically compiled executable and shipped it out with instructions to install SDL2 and SDL2_ttf. This was OK, but some people still had to compile and struggled. One of them did it in a twitch video and he was unwilling to let chicken-install write into his /usr/local directory, which I can relate to. Distribution is definitely something to investigate for a future participation.