For the past two weeks, I've been working on a little Interactive Fiction side project. It has been a nice palate cleanser between all the daily routines and longer-term projects like Lagrange.
There's something about Interactive Fiction engines that has fascinated me for a long time. I bought a copy of TADS version 2.2 back in ~1994 and had some fun times building little games with it.
TADS is effectively a programming language where one can define a bunch of places, objects, actions, and behavioral logic, and the engine handles the parsing of natural language input for you. It's quite a powerful system, but of course very complicated as well. I think my early attempts to create a game using TADS where thwarted by the complexity. It's easy to get bogged down by the minutiae of defining all kinds of objects, their descriptions, and the verbs they respond to.
In contrast, my project is a little IF engine that drops the natural language input but retains a sufficiently rich object tree for gameplay to be more than a simple choose-your-own-adventure. At any given time, the set of possible player actions is a mixture of procedurally generated and manually defined ones. My hypothesis is that this is enough for creating a compelling game where one can focus on the story and have sophistical puzzles without having to try all permutations of foobar frobnication on various items in the game. As an analogy, compare the original Secret of Monkey Island (from 1990) to the recently released Return to Monkey Island. In the former, the interaction is based on chaining together verbs, items, and places of interest in the current location. It's a GUI for putting together a natural language sentence. However, modern audiences will find this very cumbersome. The new Monkey Island is much simpler in that it's primarily based on drag-and-drop without any specific verbs. (Granted, it still has different actions for left and right mouse buttons.) It also helps the player see where the interactive bits of the current location are by highlighting them. The end result is a friendlier, more modern, and more streamlined experience.
In my engine, the player's available actions are presented as a menu of choices, plus the always-available actions to manage inventory, look around, and view the map. This makes it very much compatible with Gemtext. While you can do the traditional free-form input with Gemini (and it has been tried with Zork et al.), the result is clunky: you have two network requests for each player action, and text input has its challenges on mobile devices. While the engine currently runs in the terminal, I fully intend to make a version that plugs into GmCapsule so it's possible to play using a Gemini client, and have the game be saved persistently on the server.
The two weeks I've spent on this so far have largely focused on coming up with a story and building the engine itself (for now in Python). Now that the system is up and running, the focus will shift to actually writing the Fiction part of the IF. However, like many programmers, I'm a sucker for starting up new and exciting projects but when the true scope of the remaining non-programming effort starts to become clear, the excitement may start to vane. We shall see what happens this time. I do enjoy occasionally writing some fiction, though, and there's a definite appeal in escaping to this little world that I've been building, and fleshing out the gameplay, story, and minigame puzzles.
The original Gemtext version of this page can be accessed with a Gemini client: gemini://skyjake.fi/gemlog/2023-02_side-if.gmi