Ludum Dare 36 Postmortem: Conor & Harley

This is the postmortem for my game Connor & Harley made in 72 hours for the Ludum Dare 36 game jam.

Yes, you’re reading that right–there’s no Ludum Dare 35 postmortem. Although I was involved in making music and audio for that particular jam, I felt separate from it, and my work was sporadic rather than constant. For that reason, I never got around to doing a postmortem because it felt wrong doing it for a disjointed event rather than a specific project.

For the 36th edition of Ludum Dare, which was my third and the second one in which I attempted the compo (working alone), I decided to make a text adventure. I know the modern parlance is to call it interactive fiction, and in fact the game did veer in that direction, but I can’t bring myself to call it anything except a text adventure, because to me these games owe their legacy to Crowther’s Adventure and Infocom’s Dungeon (Zork series).

No, I don’t think the thing I cobbled together in 72 hours come anywhere near comparable to these. Actually, I won’t even call it a finished game (story) until I’ve had at least three or four more releases in the distant future. However, these games are a deep part of my childhood, even though they were around for decades before I was born.

I won’t bore you with a historical account of my experience in interactive fiction, except to say that I owe a lot to Campbell Wild’s ADRIFT system. Not only did this system get me making my first games, it also taught me many things about programming, including the revelation of the mysterious things known as “variables.”

And now we move on to the fabled Two Sections of a Game Postmortem.

What Went Right

The decision to switch to the jam (72 hours instead of 48) in the middle of the competition.

I also mentioned this in my Ludum Dare 34 postmortem, and it was exactly the same situation. I figured because I wouldn’t be spending time creating assets, I wouldn’t have this problem again. I was very wrong, for all the reasons outlined in “What Went Wrong,” below.

But it was a good idea. I came to a point in the middle of the second day where I realized my game had potential. This left me with two options: cut corners now to get the game into a finishable state, or continue on to the third day. There weren’t really any cons to adding on the extra day, other than being out of the competition. Since this Ludum Dare doesn’t have rankings it didn’t make a huge difference.

The jam option allows additional benefits, such as working in teams and not sharing your source, but I decided to stick to the compo rules and tack on the extra day as a sort of hybrid challenge to myself. The end result is much better than it would have been otherwise, especially because:

Someone who wasn’t me play-tested the game.

Watching this play-test, taking notes, and seeing the resulting transcript led to a huge number of changes in the last four hours of the jam. These ranged from simple typos like “your hair rubs against your ceiling” to huge, game-breaking situations like the player being able to magically hop into the ending without solving the second-to-last puzzle.

Even though this meant finishing the game before the deadline and taking time out to watch the play-test on-fold, the benefits were huge. I had always heard it’s a good idea to finish at least half a day early for play-testing even in a severely limited event like a game jam, but now I’ve experience it first hand, and I truly believe it. I only wish I had left more time for testing, or had more testers to try the game.

Eating, sleeping, and generally looking out for myself.

This one is a given which I learned was a good idea in my first jam. Although Conquistaquest ended up being rather impressive since I was learning the tech as I went and didn’t have any prior completed-game experience, I basically blew off the last 12 hours in a blind daze and couldn’t solve some of the more killer bugs late in the jam. This led to us dropping a couple features which could have been fun, and which I could have implemented quickly after some proper sleep and nourishment.

Using good tech designed specifically for what I wanted to accomplish.

You’ll see my decision to use Inform 7 as a pro and a con. It’s a pro because the system is hugely intuitive. Inform 7 uses a “natural programming language” which means most of the code reads like a book. Some of it can be a bit weird–which I’ll get into in the “What Went Wrong” section–but generally it’s as smooth as writing a novel.

Here’s an excerpt of actual code from the game which reads like normal English:

The crystals are part of the chandelier. They are scenery. Understand “crystal” and “pearls” and “glass” as the crystals. “Glittery balls of glass held together by nearly invisible string or chains. Some are more globular than others, and a bit cloudy. You wonder if they’re pearls or simply meant to look like them.”

Although some of it is a bit stilted and technical, you can get a good idea of what’s going on here. You can see more by browsing the game source and learn more about the language on the Inform 7 website.

Going out of my storytelling comfort zone.

I have a long history of jumping on fantastic worlds, magic, the traditional (cliché) medieval setting, and the like. I used a bit of this as a crux in this adventure, but the idea of setting it in a modern, real-world (ish) place would normally terrify me.

The leap out of my comfort zone was intentional: by doing so, I created a brand new universe to explore. Although the game isn’t set in a specific, real place, it involves college students in a renaissance-era palace and I did a significant amount of research in the short 72-hour development period. I think this led to a more believable and interesting experience, but it may have also led to some holes and inconsistencies. We’ll get to that soon.

What Went Wrong

Very minimal outline before starting development, which led to all sorts of problems.

Here’s a shortlist of the problems this cause:

  • I was way too blabbery in the beginning, and as I started to run out of time, the game text grew terser.
  • I didn’t leave any time in the beginning for research because there wasn’t any idea specific enough to research. This was especially a problem in a modern setting.
  • The work went from start to finish. As I suggested to myself in the LD34 postmortem, it’s always best in a tight deadline to get the thing done from start to finish as quickly as possible, then fill in the complexity and details of the middle. Didn’t do that.
  • A lack of focus as to what the game was going to be. I started making an event-based story but had it in my head that I wanted a traditional text adventure, so the game became this weird collection of both and sometimes a hybrid.

Limited prior experience with Inform 7.

Although I worked through the entire tutorial book several years ago, Inform 7 has changed drastically since then. I’ve also only made a single, very small game with the system, so I wasn’t familiar with all that it took to build a larger project from start to finish. Sometimes I tripped on the more obscure pieces of the compiler.

For instance, you can’t use “if, otherwise if, otherwise” unless you’re using the “big if statement” format. This means that the following won’t work.

If the player is tall, say “You hit your head on the ceiling”;

otherwise if the player is short, say “You pass through with ease.”;

otherwise say “You pass through, but your hair brushes the ceiling.”

Instead, you have to phrase it like this.

If the player is tall:

say “You hit your head on the ceiling”;

otherwise if the player is short:

say “You pass through with ease.”;

otherwise:

say “You pass through, but your hair brushes the ceiling.”

Notice the semicolons, colons, and indentation here. Those are all super-finicky, including the periods, so it took a long time to get used to these rules. No matter how natural Inform 7 appears, it’s still a programming language. That means it abides by very strict, very technical rules.

On this same note, finding a specific phrasing of something can be very difficult. The functionality to search through the documentation searches broadly and has no advanced features. So if I’m trying to find what the word “called” does, I get every single instance of the word “called” in the documentation, including the ones in the main text (not in code examples).

These problems largely went away later in the jam as I grew more familiar with the system’s quirks. I also started to find answers more quickly as my vocabulary began to match that which the system expects. It’s kind of ironic how using Inform 7 can be like playing a frustrating text adventure sometimes, where you’re stuck trying to guess the verb, like when the action is “using it with” instead of “using it” or “using with it”.

No codebase to work from.

Related to my lack of experience with Inform 7, I didn’t have any code for it lying around. Before the jam, I pulled together as many extensions as I could so I could make my starting point super-flexible. However, I found that many of these extensions use obscure language just like the core language, so trying to figure out all their technicalities on top of the language itself only made things worse.

Now that I have some more code under my belt, I can start creating my own personal extensions. The next time I write an adventure I’ll have a lot of the technical bits from this specific game already implemented in a way that makes sense to me. That’s a huge boon over starting from scratch.

The adventure blew way out of scope.

This is something I need to continue to work on, and I think it’ll get better as I do more of these jams. You can’t do a lot in 48 hours, or even in 72. There’s no getting around that. So instead of trying to do more, you should find a way to accomplish more in less actual content. Hence the popularity of procedural generation at Ludum Dare.

The scope getting out of hand was largely a product of not having a complete outline. I didn’t know the ending, I didn’t see the bigger picture, and I kept changing course as I went along. I started with large swathes of text, spending the entire first day on what I thought was going to be nothing more than the introduction to the game. Possibly I should have cut my losses at that point and made the introduction the full game. In that case, I might have finished in 48 hours.

In the end, the game has a lot of empty space and things which don’t exist because it was too big for me to handle in this short period of time. Next Ludum Dare I’m going to think so small it hurts, and then build from there. Much easier to do that than to think big and cut down.

Conclusion

My initial thought was to do procedural generation, but when I went down the text route, I had to familiarize myself with the language. Now that I’m more clear on how Inform functions, maybe I could pull off something a little more procedural. The problem with text is that it can’t be abstract enough to really be generated without insanely advanced natural language processing.

Maybe at the next Ludum Dare I’ll do something procedurally generated, more abstract, more programmery. Or maybe I’ll try another crack at a text adventure. My next big project is going to be NaNoWriMo, so it could go either way: I might be burned out from writing my novel, or I might be so into writing that I want to keep going with it.

In any case, I feel like I succeeded again at this Ludum Dare. I made a game that is playable–and winnable–in a period of 72 hours, on my own. Got to give myself credit for that.

1 thought on “Ludum Dare 36 Postmortem: Conor & Harley

Leave a Comment