Ludum Dare 60 - Amiga 12000

Yes, I dipped my toes into Ludum Dare yet again in October. I skipped a couple after my last entry for Ludum Dare 57, but with the jam wrapping up forever (maybe) in a couple of years I didn’t want to miss any more if I could help it.

Tools used were Godot, of course, Pixelorama, LMMS and Audacity.

Preparation

After the last jam I embarked on some major changes and a refactor to Digression. I bit off more than I could chew with that and hadn’t touched it in a year. Of course I wanted to have the option to use it in the jam, so a couple of weeks before it I went back and tried to figure out where I was and what was left to do. It was fundamentally broken and was not saving values from the UI into the resources, but I managed to get it working acceptably in time. It also needed some minor tweaks to work in the latest version of Godot, as it always seems to. Without time for extensive testing I just had to hope that it was enough.

I had also prepared some placeholder visual assets after the last jam - just a set of basic shapes and patterned backgrounds to allow me to get on with gameplay development without relying on the Godot icon, which has some issues as a placeholder.

I didn’t bother with getting the title and menu scenes that I often use ready, and I didn’t have time to put together any other base code or practice music creation or my graphical asset creation pipeline (this is foreshadowing… 😅)

Concept

In my brainstorming before the theme announcement I had some ideas for several of the proposed themes, many of which were some variation of redoing the basic concept from Lovely, Dark, and Deep, but better, and with some tweak specific to that theme. I didn’t make any such connection for “Old Tech”, and in fact I was hoping it wouldn’t be “Old Tech” because I’ve already made two or three games that could fit that theme. The idea for the gameplay of having to piece together a route from a set of vague details was one I had for the “Navigation” theme.

Once the theme was announced I quickly made the connection that I could just make the navigating entity some old technology. Could have been a bike again! But I had just done that. Could have been an old car, and been a morality tale about ICEs destroying the planet! But I wanted to use my pixel art planet shader, so I went with an ancient spaceship.

I decided that it would make sense to style the UI like a retro computer system to give it another thematic dimension, and considered an old Unix system like CDE, or classic Mac OS, or some old version of Windows, but I like Amigas and the Workbench UI had the properties I was looking for. I’m not sure at what point I decided that the ship itself would be an Amiga, but I guess it made sense if that was the UI in use, and I like the absurdity of it anyway.

Code & Gameplay

Making use of the placeholder assets I had prepared, I was able to focus on the gameplay right from the beginning. I sketched out the kinds of attributes that systems and planets would need to have to be differentiated by the puzzles, and all the interactions that would be required to allow the player to identify those attributes. By the end of the first day I had a set of resources designed to store the levels, and a complete game loop.

The only thing I had in mind that I didn’t end up implementing was to have a kind of spectrograph display to identify elements in the atmospheres of planets or in the stars.

There’s not really anything very interesting about the gameplay code to be honest. It is the same location-navigation-transition trifecta that has apparently become my default for jams! I had initially planned to make the levels procedurally generated, but I decided I would at least start with some hand-crafted ones to make sure I didn’t become bogged down. I didn’t end up coming back to the procedural generation idea, and I think I was probably right not to bother with it. It was fun hand-crafting the levels anyway and trying to figure out how to get the right balance to them.

I did struggle with some aspects of the UI, as I often do in Godot. In this case the main problem I had was that I couldn’t get the navigation UI “pages” (the level and system views) to size themselves automatically to their parent. This is a problem I encounter quite often. I’m not sure if it was because I was using two basic controls as the roots of the pages, or if it was some other aspect of how I designed them. Since the size of the navigation window was going to be fixed, I just manually set the minimum size for the elements of the pages such that they would fit properly in the window.

Digression of course featured once again for the dialogue. My use of it was very basic this time as it did not really drive the gameplay and there was only one character. I did not encounter any bugs and having it as a main-screen plugin this time was definitely an improvement. I did still find some stuff that I need to think about improving in the future. Some of the classes that need to be used by the developer should probably be named classes so that type hinting can be used without having to dig into the details of the plugin. The controller node was missing some methods and properties that I wanted to use. It was quite late on day three when I discovered the things I wanted were missing, so I just worked around their absence in messier ways due to fatigue.

The level design took approximately 4 hours on day 3. With the game essentially complete by that point aside from a bit of polish, I was able to take my time with it rather than the usual frantic scurry to add content. I think I gave the levels a reasonable difficulty curve by increasing the number of clues and adding some vagueness to what they were describing, so that you couldn’t just rule out systems at a glance as the game progressed. As I moved on to the design of later levels I determined that the best approach was to decide on the clues first, and then design systems that satisfied all but one clue, and one that satisfied them all. The first couple of levels I designed didn’t follow this approach, and I went back and redesigned them for consistency and maximum puzzlement.

Quite a long time into the ratings period a commenter on my game noted that two of the systems on the final level actually satisfied all the criteria. So that was embarrassing. I released a fix for that, and had also released a post-jam version that allowed the player to retry from the previous level if they made an incorrect choice, again in response to criticism I received from commenters.

Art

There were very few art assets involved in this one. The UI is just a couple of 9-patches - one for the windows, one for the buttons - and a bar at the top of the screen. The Amiga Workbench UI is very simple, so there wasn’t much to implementing those.

The spaceship was also very simple. No combat or action animations involved, just off and on, a state for when it is “reading the HD”, and a couple of frames for traveling between systems. Oh and a variation for the navigation screen which I probably could have done without!

The big impressive art in this game, the planets and stars, were not designed by hand. They are the output of a shader I designed a while back. To give them the necessary variation I had to create a set of palettes for surface, atmosphere, cloud and posterisation colours - 37 palettes in total. It occurs to me now that I probably could have generated some or all of these procedurally as well.

Nonetheless, the art was the first place where my tools (and my failure to check them) sort of let me down. For some reason when I opened up Pixelorama, all the keyboard shortcuts had been cleared, including such basics as copy and paste, and save, and the layout had been changed significantly. I assume this is probably a problem with the Flatpak rather than the application itself. I carried on anyway and set some of the most important shortcuts as I needed them, rather than messing around with trying to reinstall it. I also found several other things about it bizarre and frustrating this time around, such as its treatment of palettes and the inconsistent way it decides what path to use for exports. It also kept opening certain files zoomed out tens of thousands of percent. Very annoying.

Sound Effects

I had a lot of fun recording the sound effects.

The typing sounds are just me typing on my keyboard, of course. I recorded a variety of keystrokes, put them in an array, and selected from that randomly every time a character is added to the console. It identifies spaces specifically and plays from a separate array of space key sounds, as those have a distinct sound. I’m not sure if this added much or not!

The HD crunches and ambient power hum are my NAS. I just recorded for a few minutes and cut out some individual crunches and a section of hum with no crunches. Again I stuck them in an array to pick from randomly on a timer which also has random timeouts. The big set of crunches at the start of the game is when my Jellyfin library is being refreshed, I just cut out a section of that and played it otherwise unedited.

The startup and shutdown sounds were generated in Audacity - just generated a tone and then pitched up or down over time. The engine sounds were also generated in Audacity, but from processed noise.

The UI sounds were done in LMMS, a couple of different short notes from the SID plugin.

My wife offered to do some voice acting if I needed it, which was a surprise! I thought there was a bit too much dialogue involved so I turned her down on this occasion, but now that I know she is up for that maybe she will star in a future game!

When I first went to record the keyboard SFX I discovered that I could not record from my microphone in Audacity on my desktop. I had to do it on my laptop instead, and I discovered that I didn’t even have Audacity installed there. I really need to be better about checking my tools before jams…

Music

I really wasn’t prepared for doing the music at all. Some months ago I started trying out a more “live” or improvisational workflow for music, but I never really tied it down. One thing I did take away from that was that I really liked Vital, which is an amazing and intuitive free software synth, and I definitely wanted to use that for this jam. However when I went to use old reliable LMMS I found that there was no way to embed Vital in it. My existing install was missing the VST embedding plugin entirely, and when I switched to the AppImage, which does include it, I learned that it only supports Windows VSTs? I tried embedding a Carla rack instead, but when embedded that also could not load Vital.

I maybe could have had Vital running in an independent Carla instance and piped MIDI and audio around in JACK, but I figured it would be too much work to get into messing with all that, so I resigned myself to a different instrument - the SID plugin I mentioned above, which is an emulator of the C64 audio chip. Seemed appropriate enough anyway. I hadn’t practiced with this and didn’t really understand all the options, but after clicking around for a while I was able to find a sound I liked.

Fortunately given the game’s premise I thought I would get away with something very simple for the music. Something forlorn and sparse and spacey was called for, so I took a similar approach to the one I took for Gophers and just spaced out the notes of a single chord, in this case a C major, and added a bit of delay. A spacey synth pad repeating the same notes completed the arrangement.

I wanted something a bit more exciting for the transitions between systems, but since those are so brief I didn’t think they were worth a completely new song. Instead I just added some kick drum beats and arpeggios of chords based on the already established notes using another SID instrument, and some high and low pass filter automation. These new tracks play continuously with the main track and are just faded up and down for the transition. I think I regret this in retrospect - the new instrument tracks are way too high-energy compared to the original ones, and they don’t really fit together at all. They just bury the original instruments. However their use is so brief I’m not sure it matters much.

All told I only worked on the music for an hour and twenty minutes, which is a lot quicker than usual for me, even with the initial messing around trying to get Vital working.

Results

Yeah I did alright.

It just edged out my last showing in terms of ratings by being slightly higher across the board aside from in humour and audio - but it had one fewer top-100 category placing. I’m surprised by the higher mood rating honestly, I thought Lovely, Dark and Deep was great in that aspect. I am very glad to have improved in fun.

The most notable result is that it is my highest ever placing in the graphics category, at 27. It is almost the highest rating also at 4.5, just beaten by Rattendorf’s 4.582.

Celebration of the placings must be a bit tempered by the fact that this Ludum Dare had the lowest number of entries in a long time at only 735. 112 out of 735 overall is nice, but it doesn’t really compare to Gophers’ 109/3576. My last two entries feel like a return to form after a couple of relative duds, but I definitely haven’t surpassed my previous best.

The Future

I just learned during this jam that it is permissible to use base code for the compo - I always thought everything for the compo had to be completely from scratch! I’m not sure if the rules changed or if I was just mistaken. In any case, I think I am going to enter the compo for the next few Ludum Dares, with a decent collection of base code to leverage. There are a couple of reasons for this:

1. For the jam I have to take two days off work, one for the third day and one to recover afterwards! For the compo I should only have to take one day off, which is a bit more manageable.
2. There seems to be somewhat more hostility to generative AI amongst compo participants.

On the latter point, it is disappointing that there has been no clarification to the rules about the use of generative AI in either part of the competition.

I’m sure some would argue that the use of this technology is no different from the use of randomised or procedural “content generation” tools, the use of which is explicitly encouraged by the rules. I think it is a fundamentally different thing. You can’t ask SFXR to generate you a game based on the theme and call it a day.

It is always going to be debatable where the boundaries of creativity are in game development. Why are participants allowed to use base code at all? Why are they allowed to use libraries? Should we not have to code our own game engines from scratch? In order to participate in Ludum Dare, maybe you should first have to invent the universe.

It certainly has always been possible to come to the jam with a completed game and just swap out the assets to match the theme. I think that’s a pretty boring idea, but at least you would be required to create the assets. Probably it is best for any base code to be considered a set of building blocks - not interesting on its own, but something that can be assembled into a game, and that is where the creativity lies on the coding/game design side of things. With generative AI, it is probably possible to create an entry without exercising any creativity whatsoever over any aspect of it.

At the end of the day I have always felt that the real competition is not against other people, but against my own previous performance, so the presence of slop amongst the entries is not going to stop me from participating. I just don’t really want to engage with games that were not created by people, or where the extent to which they were created by people is ambiguous. Why would I want to spend my time playing and rating and critiquing something that nobody put any effort into creating? If I enjoy a game, who should I credit for that, the developer, or Claude? If I don’t like it, is anybody even going to benefit from my critique, if they didn’t actually make the choices that I’m critiquing?

But how much longer will I be participating anyway? Mike has scheduled the final Ludum Dare for October 2028 - Ludum Dare 64 - but also confusingly announced that there would be an April 2029 event as well. However, there is also an initiative by some long-time community members to carry it on if he does actually call it quits. They have a new website up and a Mini-LD planned for January next year to try it out, which is all very exciting.

If that doesn’t end up working out, I will just have to find an alternative jam or jams. I should probably participate in more anyway. Ludum Dare has always just felt right - the right length, the right rules, the right community and vibe. But it would probably do me good to branch out a little. I have done really well in smaller jams in the past! Maybe I will finally participate in a Godot Wild jam, which is on every month. I don’t like that they are over a week long, but they already have explicit rules against AI-generated content, so they have an advantage over Ludum Dare there!