Grim Rejoiner - postmortem and musings

A first: no design document.

The story of Grim Rejoiner begins at the end of our 7DRL entry for 2023, Grift & Grind. Not long after we submitted, the cogs began turning as to what we would do for the 2024 challenge. The way this often works is that I'll have a murmer of an idea - something elusive and half-baked which I excitedly bring to Voxelate in a series of hyperbolic short statements. Grift & Grind was something like: what if we did an evil office simulation? Portlligat, which sadly didn't get far enough to be released in any meaningful way (not because we didn't do a lot of work on it - we did - but the scope was wild, more on that later), was spawned by me uttering: what if we did a Salvador Dalí roguelike? Usually the outlandishness of my suggestions is enough to get the ball rolling for us. They serve as the jumping point, and Vox and I make something out of it. That didn't really happen this year. I remember at one point suggesting we make a roguelike that was based on material for another project I've been working on-and-off on for a while. It would serve as a kind of tie-in, in which the player character would have to utilise lots of specific real-world techniques from traditional European sword martial arts to control their positioning against hordes of weak but potentially overwhelming monsters. The player would need to hack their way through to a boss, defeat it, and that would win the game. But something about this didn't quite hold our attention, or at least, I didn't think about it for very long. I got as far as beginning research, and then ...

My second idea was a bit more interesting, much more vague, and also significantly closer to the start of 7DRL24. "What if the player polymorphs into the last monster they killed?" This was an idea that had some legs! The immediate gameplay implications were probably what excited us the most. The fundamental interaction common to most roguelikes, that of defeating and enemy, was now the core strategic component: you become what you kill, so you better be careful! Imagine if you manage to defeat some pretty intimidating monster through cunning and guile. Your reward is a significant boost in power, and puts you on a good footing to tackle the subsequent challenges that the game is going to throw at you. You're ready to fight the dragon, take the prize, and win the game. Except on your way to the dragon you kill a rat, and you're in a worse position than you were a few turns ago. That's an interesting idea, and we were interested in it. But then nothing happened. Let's go back to Portlligat.

The first version of the Portlligat design document that I can find dates to February 13, 2021. The contest began on March 5th that year. By March 2nd, the word count for the design document was around 9650 words, over 38 pages. It had chapter headings such as 'Visualising Dalí’s Surrealism 1: Rationale and colour' and 'Visualising Dalí’s Surrealism 2: Themes and encounters - Psychosexual anxiety', as well as a a Rationale-Methods-Analysis on colour theory in reference to Dalí's canonical three periods.

Pages and pages of example flows, what happens when a player gains a level; what happens when to do this roll, or engage that foe. The scope at this point seemed big - certainly a monumental challenge - but not quite absolutely impossible. Absolutely impossible came later, during the challenge, when I began - outside of the scope of the design doc but not contrary to anything inside it, and outside of conversation between us - to start working on an absurdly intricate and extensive crafting system for player gear. The weapon crafting, and the opportunities it promised were a thing of beauty. I remain proud of the crafting system and the ideas around it, and the game as a whole. I keep thinking 'one day', but I've thought that about many projects over the years. We did/do plan still to work on it, and then...

We thought we were doing polymorphing as the main idea for our '24 entry. Bear in mind that Vox and I had discussed the polymorphing idea. It didn't quite get to the design document stage, but it was fleshed out enough to give us direction and vision. Then February 6th of this year rolled around, and I had one of those half-ideas. I wrote:

Another idea for the game is that rather than you polymorph into the creature you just killed, you graft one of its body parts onto yourself 😮
It could get a lot more weird
Some interesting mechanics could arise from it too
Deliberately dismembering parts you don't want for a HP cost etc

Some discussion ensured; the ideas and implications began to percolate; we even got around to thinking about graphical style for the game: a nice, classic isometric projection. We haven't done that for a 7DRL yet! No design doc, but an idea. We were set.

Then, at around 11am on the 3rd of March, I had the idea that if we were going to go for an isometric projection, it would actually be easier and more efficient to just go with a 3D environment.  Amazingly, Vox agreed, and with literally a few hours to go before we started (we were beginning at 8pm), we had pivoted from a domain that we were familiar with and comfortable in (2D pixel graphics),to one that we had never worked in before: 3D environments.

Wiggle room

You'll notice that I wrote a fair bit about design docs in a portmortem for a project that didn't have one. But I think it was because we didn't have a design doc that we were able to make some of the best decisions that we made during the jam. If we had of had our design bible that was a work in its own right dictating the progression of the project, we likely couldn't have pivoted towards the big changes that we needed to. The biggest change, and I think the most impactful was the pivot from a comfort zone, 2D pixel art, to an uncomfortable one, 3D rendered environments. Grim Rejoiner certainly isn't the most complicated or sophisticated example of 3D graphics, but we were - or at the very least, I was- operating at the extents of capability. Trying things in a way that I hadn't before, search for and finding solutions to problems that I didn't know needed solving. And now we have this approach in our proverbial toolkit, upon which we can build and iterate in the future.  

Finding what is important

With no design doc to guide us, just a few conversations that functioned as notes on a napkin, we had to search for other ways to locate and define what was important. It became clear to me almost immediately that the environment and experience of the game, or demo, or proof-of-concept, or whatever it is, would be the thing that endures from it. You're this gnarly little grub guy, that goes around grafting the body parts of other creatures to yourself in ways that don't quite make sense, and don't quite work. Like a fractal, it became itself no matter what angle you looked at it from. The game wants you to experiment, make rash decisions, regret them, try them again, be surprised, amused, and horrified, and have fun doing it. I tried to make decisions that would maximise those possibilities wherever possible. And wherever possible is the key part of that sentence. Possible.

Possible is generally a question of perspective, I find. Possible depends on scope, resourcing, ability, motivation, and so on. What is possible in a 7DRL is a very different thing to what is possible in a 30DRL, or a 365DRL, or a AAA-RL. A lot of things can seem possible, until you run out of time to do them. For me, I thought it would be possible to have some kind of fun or questioning title screen. I always tend to spend more time than I should on title screens, and try and do too much. I've always composed full tracks for each of our games' title screens, knowing that the likelihood of anyone sitting through long enough to hear the whole track was slim. I have to do it. To me that's important. So often I make choices, or push ideas that don't make the most sense in terms of productivity or economy of time, but I always try and maximise the thing I'm doing when making those choices. Having a title screen with an original track isn't going to make your 7DRL substantially better than one that doesn't, but it maximises the thing in the moment. The title screen. One of your opportunities to hello to the person playing the game.

Interlude: why a 7DRL

To date, Vox and I have worked on six 7DRL entries together: Geiger A.D '42 (2011), Slumber (2020), Portlligat (2021 - unreleased), Battletier Ascend! (2022), Grift & Grind (2023), and now Grim Rejoiner (2024). Most of our work happens on games outside of the 7DRL though. Some of those games go back twenty years. Almost none of them have any code, graphics, writing, or formal documents. They're scraps of ideas that have come out of 'I'd love a game that did...', or 'wouldn't it be cool if...'. The 7DRL Challenge gives us the opportunity to move some of those scraps outside of the hypothetical and into the real world. We didn't have a design doc for Grim Rejoiner, but really our mutual interests in games, and the friendship we've shared exploring those ideas over the years, has created for us a kind of a living design doc.  

What is fun

One of my favourite gaming experiences ever comes from the old-and-classic roguelike, Ragnarok. It was one of the first video games I played, not long after I got my first computer as a child. I remember in the game being able to wish for seemingly anything I wanted, and I through some combination of will and luck, I managed to polymorph myself into a gorm in the early game. Perhaps not the best use of a wish - certainly not the worst - but I think it set my expectation and desires in gaming. I found myself the biggest sandbox that I could. It was great. Unfortunately I haven't been able to build so grand or wonderful a sandbox as was given to us in Ragnarok, but that's what I'd like to do. In some small way, we did that in Grim Rejoiner. You can put whatever body part you find wherever you want - it might not be the best decision you can make, or give you the most optimal build, but you can do it. The body part grafting system is the scaffolding upon which we've tried to erect play and playfulness. It's an odd one, but there were a few times I couldn't help but grin at the grotesque humour that unfolded as a result of a botched attempt to place an limb in its right place, only to have a foot appear on a head.

Into the fray: implementation and tooling

Godot game engine

Grim Rejoiner, like all of our entries since Slumber, was made in the Godot game engine (4.2.1-stable, specifically). Godot has many things going for it: open source, ease-of-use, flexible, powerful, and on the whole it's performant and has great cross-platform support. We've leveraged Godot's built-in scripting language, GDScript, in all our entries. Sometimes we've discussed using C# instead of GDScript, and while C# is a very attractive language, it hasn't yet proposed a usecase that isn't currently better fulfilled by GDScript. As Godot has become more mature over the years, GDScript has too. Since Godot 4 released, GDScript now has anonymous and first-class functions, so we have certainly found it to be sufficient for our needs. Of course, C# has a broad ecosystem of libraries that certainly could be useful in specific situations, but that gap has largely been filled by our own small library of utility functions that we've been growing since Slumber.

One of the advantages to our continued investment in Godot is that we've built familiarity with the engine and its nuances, as well as GDScript. Each entry we've created has slightly expanded our in-house pseudo-library of classes and functions. The most enduring code in the codebase is Vox's ProcSen, which actually was first devised back in 2011 for Geiger A.D. '42 - originally written in Python 2, and now primarily living in GDScript (Although, it has been ported to HamsterSpeak for the OHRRPGCE, and also to C# by yours truly). We've developed an expanding library of code that gives us the basis for inventory management, map objects and entities, some basic stat management, among other things. Last year's entry, Grift & Grind, had no combat, and instead we created a highly sophisticated system of interactions and tasks which were versatile and powerful, but sadly had no place in Grim Rejoiner. Now we have a library of functions for the highly specific task of attaching and sever body parts from an eldritch monstrosity, which is probably a bit too specific for future use. Maybe the severing code might come in useful. >=D

Which brings me to one of the central points for this postmortem. Representing the interaction of an eldritch beast that strengthens itself by attaching the body parts of other creatures to itself isn't the most obvious system to code. One thing that became clear quickly was that the game should revolve around the managing of this system, and that required a way of representing the beast and its growing collection of body parts.

The first thing I did for this year's entry was work on the BodyPart class, and finding a way to represent it to the player. The system I devised for this can be nicely captured in the immortal words of the Johnson brothers:

Foot bone connected to the heel bone
Heel bone connected to the ankle bone
Ankle bone connected to the leg bone

While I didn't model a system of connected bones, I knew that body parts more or less connect along their bones. And so I set about writing a class that at its core was really just a tree: each body part can have one parent, but many children. When attaching limbs to the player, the idea is that they gain stats and extra slots for equipping items, as the more hands you have, the more weapons you can wield. However, that's a system in which the game's balance could quickly disintegrate. There is nothing to stop the player from getting as many limbs of whatever utility possible, connecting them in whatever way they feel like, and launching themselves at the enemies. In the interest of balance, there needs to be a way to encourage or dissuade body parts from being used in specific ways, while also never getting in the way of letting the player do what they want to do. To this end, I came up with the instability system, where the more outlandish the combinations a player could thing of, the more unstable and prone to failure it would become. Attaching body parts together in the ways you would expect produces minimal or no instability. Hands connected to arms connect to a torso don't add instability. But attaching a head onto the end of a leg that it attached to another leg of a completely different type, well, that creates a bit of instability. Instability was meant to be a much more significant part of the gameplay, but it didn't quite get as fleshed out (or functional) as I hoped. Alas.

This whole thing did result in my favourite piece of code in the challenge. As the player's body was modeled like a tree, it made sense to use Godot's Tree UI node to represent it. But at a glance, a tree of body parts wasn't particularly informative, so I knew I needed something to have visually parse the complex information. I drew a few icons to help with this. The scar shows that the body part has other parts attached to it (it's a parent with children). A hollow circle shows that the limb has an empty slot in which an item can be equipped. A filled circle shows that the slot has something equipped in it. It gives the player at a glance a quick overview of what limb is doing what. A nice feature. The reason for it being my favourite piece of code is because it had to take a slightly circuitous way to achieving a very simple task: changing icons on a tree. Because Godot's Tree supports one icon per leaf, and I needed a combination of different icons depending on the structure of the tree, I would have to generate the specific combinations of icons on the fly and combine them into a single texture so that the Tree would be happy with the icon I gave it. It worked beautifully, and satisfied me immensely.

Graphics

I contributed almost nothing to the graphics programming this year. My one small contribution was a barely fit-for-purpose concept that ended up being a reasonable timesink for Vox: SnappingSprite. The idea behind the snapping sprite was simple: you take a Sprite3D, and you give it a few Marker3D children. One of these acts as an origin point for 3D transformations performed on the SnappingSprite. The other Marker3Ds act as 'snapping points' for other SnappingSprites to ... snap to, from their origin point. The idea was that we could set up the various body part sprites so that the connections that were being made in data could be represented dynamically for the player to see. I am not the most mathematically articulate individual around, so the fact that I was able to get anything approximating this working in the first place was quite the personal achievement. After much modification by Vox, it became the system that it is now, and the source of much of the visual interest the game offers.

Graphics tools

I used a fairly unimaginative combination of Blender, Aseprite, and SpriteIlluminator for creating the graphics for the game, but with a twist. Our project required lots of assets, of which I had very little time to actually create. And so, I decided to leverage the hottest and most hyped tool available to me, generative AI. I decided to go with a service called PixelLab, which runs as a plug-in for Aseprite. They offered a trial of 20 generations, which I had a go with and figured that the results could be good enough for my purposes. This was not a replacement to doing actual pixel art (perhaps unsurprisingly, the art which I am most fond of had no AI involvement at all), but it was a tool used as part of my workflow. Perhaps 1 in 10 of the generations was suitable enough to be the basis for something else, and at times the tool required quite significant cajoling to get anything usable out of it, although that may well have been user error.

Like the pivot from 2D to 3D, I think not having the design doc is what pushed me to making the spontaneous decision to adopt a tool like PixelLab. My design docs, while not a full project plan, usually give a good sense of asset requirements, and without that, the requirements for Grim Rejoiner were left wide open. PixelLabel was a useful tool for experimenting with visual ideas in a low-time-commitment way. I treated PixelLab as a very poorly paid intern that required constant supervision and occasional berating. Virtually all of the outputs had to be worked in some shape or form. But then again, I don't think my use of the tool was typical, and indeed, I can imagine for certain kinds of projects it being an absolutely integral part of a workflow. I think the service is reasonably priced. I guess this is a recommendation of sorts. I'm sure your mileage may vary.  

 Interlude: The problem with devlogs

I like writing. I like writing devlogs. But my track record of writing them is poor. Usually after the first couple of days my ability to make time for them diminishes to the point where I am unable to get anything written at all, especially in the face of mounting time pressures and fire-fighting requirements. This is a shame, because I think devlogs are part of the spirit of the challenge, and are a useful exercise for reflecting on what you've been doing, and why. I want to experiment with the format in the future, finding a way to capture the essence of the devlog, but to minimise on time spent writing them. Stay tuned.

Audio tools

All of the music composed was composed in Ableton Live, using stock plugins and features. Even the sound design, which sadly didn't make it into the game, was done in Ableton, sometimes requiring me to flex my Max for Live skills (which are sadly rusty to the point of non-existence). Ableton is a great tool, as would be expected from one of the industry standards for electronic music. I'm quite a basic user of Ableton in that I use it as a traditional DAW without making much use of many of its 'killer features'. It does have great automation controls though, which I try and make the most of. While Ableton is geared toward electronic music, most of the music I produce with it doesn't really fit into that genre. The soundtrack for Grift & Grind was a demented jazz tango combo, a soft piano interlude, and an industrial breakbeat glitch title track. The title track for Grim Rejoiner, which also sadly didn't make it in, was a Straussian orchestral overture. Ableton can do what you want it to.

Approaching a deadline and time management

 The final thing I want to touch upon is the nature of deadlines, what happens when they approach, and time (mis)management. In the very final hours of the challenge I focused on adding props to the game world. This might not have seemed like a good use of time when so many bugs were outstanding, and gameplay was still incomplete, but I think it was actually the best choice possible at that time. There really wasn't enough time left to fix the root cause of many of the bugs (largely my poor codebase), and continued work on the gameplay wouldn't have significantly advanced it. Making the decision to focus on props actually added the most impact for the time that was left available. It added a degree of jueje to what is one of the most important areas of the game: the point where the player enters the game world.

 Finally, expectations, which thematically brings me back to my opening comments. I think typically our expectations as designers have been set by our design docs. And as those design docs accumulate into their own things, the expectations that go along with them accumulate too. The 7DRL Challenge is precisely that -  a challenge. And sometimes that challenge it limiting scope, and sometimes it is broadening it - scope not just in terms of how much game you want to produce in seven days, but also how much scope you can afford yourself as a game maker.

Epilogue: the 7DRL Challenge challenge

The biggest challenge for me during the 7DRL Challenge is one that I haven't found a way to navigate yet. I'm so focused on making my game, and working on my idea, that I fail to engage with the community around us during the challenge. And it doesn't end there. Seeing the numerous very interesting and exciting games, and wondering how I'm going to investigate them all is daunting in itself. So, another part of the challenge for me next time will be engaging with the community better as we go, and certainly after the seven days have ended.

So, that's my portmortem for Grim Rejoiner. It turned into a general discussion of unpreparedness, but I hope something in there is useful, interesting, or entertaining. Thanks for reading! And if you'll excuse me, I have to start a design doc for 7DRL Challenge '25.