Ludum Dare 30 postmortem: Onomo

I made a… thing in 48 hours for Ludum Dare 30. This thing, named Onomo, resembles a game, but lacks a win state and any effective mechanics.

During development I recorded a time-lapse that will hopefully be illustrative to the folk that want to see how jammers operate. There are certainly some hours missing as I forgot to start my script several times, but it's mostly all there.

Herein I go through the timeline of this jam from my perspective and talk about the development of Onomo.

Pre-jam

I forgot Ludum Dare was happening this August and was only reminded of it by my brother before I flew to California, where I have now been living for a hair over a month.

My plan was to furnish togo with enough capability to be usable. This did not happen. I had a pre-existing deficit of willpower and inspiration that prevented progress. Despite this, I managed to fold 69.3 hours of staring into the engine over the two weeks before Ludum Dare, although productivity and system relevance only returned during the second week (considering time alone: 45.1 hours, 65% of the time spent working on the engine over those two weeks).

Realizing that was futile, I shifted to renovating my project kernel for LÖVE during the week of Ludum Dare. These 27.5 hours were spent on 71 commits:

• Upgrading to LÖVE 0.9.1.
• Upending some weird structures and extending existing systems.
• Moving to a module and system structure that works with automatic reloading.
• Refactoring utilities and making them more consistent.
• Adding support for lurker (which was indispensable) and lovebird.

The previous (and first) time I used LÖVE (and my kernel) was during Ludum Dare 26, which resulted in Prisma. LÖVE already proved to be valuable and easy to distribute for the desktop trio of OSes. Automatic module reloading made it extremely powerful and eliminated iteration delay. I don't want to work without automatic code reloading now.

Even if togo were usable, I would've been in porting hell or never even bothered to port (which would've been bad for publicity and unfortunate for fellow Ludum Darians not yet initiated into the dark cult of Linux). This was apparent to me at the time, but I 'spose it just wasn't enough motivation to switch to the kernel immediately. The week before Ludum Dare would've been better spent intimating with my media tools.

LÖVE continues to be a good choice for game jams, and I suspect I will use it for many future jams until togo topples it.

Development

I had inceptions for three themes during the final round: Connected Worlds (the highest voted among all previous rounds), Lost in Space (my personal favorite), and Isolation.

Connected Worlds predictably won, and I ran to catch the 18:07 Millbrae-bound BART train. I worked out the platforming system and explored some mechanics in transit.

I met my brother in the city and we headed off to a meetup hosted by Apportable. There were few groups at the meetup, and we only stayed for 3 hours. In retrospect, as my motivation for visiting was primarily networking, it would've been better to stop by after the Compo had finished (the meetup included the Compo and the Jam, so there would've been 24 hours remaining once I completed my entry). Regardless, I don't work well on solo things around other people or in unfamiliar environments, so it was probably best that I didn't stay for any significant period of time during development.

Once we scuffled home through the crowded subways, I spent a decent while complaining that Lost in Space wasn't the theme. This involved making spacey whale-like sounds in SunVox, shifting through different degrees of slack-jawedness, and possibly some annoyed moaning. (I was very attached to my SPACE SEA idea.) I then (somewhat unintentionally) slept for 7.3 hours. This was the only time I slept throughout the Compo.

After waking, with truly stalwart discipline, I cast aside my attachment to Lost in Space and charged forward into the dark, ominous lands of Onomo.

The premise of Onomo came verbatim from the inception: two parallel universes (in representation), with otherworldly characters that the player can switch between. The characters were the first to be sketched, and the final top character is the closest to the original drawing; only the arms were removed. The original bottom character had four legs and was more like a mouth with appendages rather than a beetle-like thing (the final design).

Preliminary mechanics were very unoriginal: move objects around to effect change in the opposite world. The top character would've been slower and unable to jump, but could climb on top of things (butchered by removing its arms!). The bottom character could jump and move faster. I hadn't decided on using puzzles, but I had many ideas for mood. I thought the puzzles would turn out uninteresting, so I looked for ways to make the game interesting in an exploratory sense.

Hmm… A lot of the changes to each world could be subtle instead of explicit, requiring the player to pay attention and connect non-trivial dots. This was more interesting to me, but I suspected most people would not have the patience. Considering both that Ludum Dare is a short-form game jam and my lack of artistic vigour, the anchor of aesthetic was possibly a misstep. Despite this, everything I did was valuable in that I was breaking new personal ground. It was the first time I built a platforming system, the first time I tried character animation, and the first time I crafted coherent music for a purpose.

I'm unsure when, but eventually I decided the characters would be able to swap positions. That definitely would've been useful for the platforming aspect (e.g., one part of a world would only be traversable by a certain character due to size), but I think I was still viewing that avenue as uninteresting. This feature didn't make it into the game, and it would've required some work on top of the existing monoliths to make the transition clean.

Without having decided what to really do about mechanics, I set about building the platforming system, world editor, and aesthetic. I wasn't granular with my time logging during the jam, so I've no exact numbers on how much time I spent on code vs. media, but the latter took surprisingly little, especially audio (judging by the time-lapse). I think I spent only a few hours in the final day creating the music, and a disproportionate amount of the time on art was spent unconstructively seeing what would happen with the tileset under certain blend modes. It felt like the monoliths (especially the large ones) took forever, but the time-lapse proves otherwise. (P.S. I used an actual script for the monoliths; they're probably legible enough for a linguistic adventurer to decipher.)

Speaking of monoliths,¹ they were a late final-day idea that initially had no purpose. I realized the lighting was going to be the driving force for the mood of Onomo, so I spent a lot of time toying with it. The monoliths came from wanting a lit world feature that would draw attention. Glowing glyphs were an obvious choice, and the idea to link them came even later in the day. It was fairly obvious at this point that I was not going to be able to fit in any concrete mechanics, so I just focused on making the world look consistent and slapped on (spoilers!) activation of linked monoliths by triggering their chimes together. That's the only thing you can do in Onomo.

Code-wise, I probably spent the most of my time tweaking the lighting and figuring out how to do character animation, character movement, and platforming (all of which I had never done in this form before). I included in-game world editing from the very beginning because I didn't want to have to convert or read data from a tile editor (which I hadn't scoped out beforehand). The in-game editor proved to be very useful and I think that they are generally a good idea. However, the save function was broken for far too long due to my ill-informed attempt to pre-optimize. I was attempting to avoid outputting rows that were empty, but I neglected that table length in Lua is zero if items are not continuous or have non-integer keys. The optimization was hardly even an optimization, and it wouldn't've mattered in the end since there were only a few rows of tiles in each world. Pre-optimization is the root of evil!

Another large mistake I made was not separating game controls from editor controls clearly enough. I changed the controls for the editor mode on the final day to absolve this issue, but I failed to adapt to them. This is probably the gravest misstep as the sudden change was the largest barrier to world building, which I had already been neglecting. Also, since the monoliths were a late idea, I was only able to place them in code. The biggest takeaway I have from this is that you should plot out the control schemes and don't tangle the two in code.

The name “Onomo” came about in the last few hours. Its origin or inspiration is utterly inexplicable. I spent the last 30 or so minutes building a Windows package and submitting the entry.

All told, I worked on Onomo for 34.7 hours.

Post-jam

In the following hour or two after the Compo ended, I built and uploaded Linux and Mac packages. I also managed to play and rate a few entries before the 37 hour mark without sleep, which was curtailed by questions such as “how are you still awake?” and realizing that I was still awake.

After 11.5 delicious hours of sleep and some business in the city, I went on my usual spree of critical analysis, punctuated by asking for Linux-supporting entries on the Ludum Dare IRC channel. There were a few entries that simply blew me away (stay tuned).

Anyhow, I feel it's a bit disingenuous to be critical of others where evermore could be piled on my own work, so I will now offer a critical analysis of it. (I'm too honest for my own good.)

On the surface, there are a few issues of aesthetic and motion:

1. The characters feel like they are sliding in motion. A weak link between character velocity and animation.
2. The worlds are too empty. There are large swaths where there is no non-uniform backdrop to give the player a sense of motion. This easily breaks immersion; an unfortunate misstep for something with aesthetic as its driving force.
3. The world isn't detailed enough, and the majority of the world doesn't give feedback or feel alive. It's very static and unmoving. Even if the large swaths of emptiness were filled in, it wouldn't have any depth to it. I can only walk along a single plane in both worlds!

As for the monoliths, the chimes mostly stand out, but at least two of them blend in too well to the background music. These chimes can be more easily heard during quieter sections of the music, but their corresponding monoliths should perhaps not have been placed so close to the spawn points. Giving the player a reason to stay (alas, this is a jam) in the game world for a longer period of time, to see what it has to offer, should've been more important.

The monolith activation mechanism is unclear and tedious. It practically requires the player to position both characters next to the linked monoliths and move one immediately after the other to ensure the second chime occurs while the first is playing (yes, this is exactly how it works). It would've been better and easier to understand if there was a continuous sound as the player stood in front of the monoliths. That way the player would not have to scramble between worlds and time the chimes.

Obviously this is a jam “game”, and I only worked on it over 48 hours, but these are all valid criticisms. I make these points for all of the entries I rate. My reason for doing so is to help developers improve their skills and hopefully observe things about their work that they may have never considered. Of course a large part of learning in game jams comes from the process of creation, but I think hearing different perspectives is also very important. If more Ludum Darians offered their thoughts, the experience would be all the better.

Onomo has become yet another concept I'd like to expand and explore, just as with my Ludum Dare 26 game, Prisma. I've been building togo not only to learn about data-oriented design and engine structure, but also to have a scaffolding on which I'd feel comfortable placing a proper Prisma (and now a proper Onomo). togo will remain my focus for a long while into the future, and I think Prisma will still be its primary motivator, though I envision other ideas will come along as it matures. No concept is perfect or inherently better than any other, so I'm not worried about this prospect. Every concept can be “better” than another with enough attention and development. When I feel that I can build something complete, I will also have a better picture of my abilities and what ideas are most compelling.

I suspect I will be writing about excellent Ludum Dare entries around the time the ratings are posted. Until then, go forth and critique, fellow Ludum Darians!