Our Lady of Thorns: A Retrospective
Hi, all — it seems like it is a good idea to write this, so: backstory and design decisions of Our Lady of Thorns.
This is long; I’ve divided it into useful sections.
Also: don’t read this as “here’s everything I did right”; there are lots of fails/questions/calls-for-advice here. This is my first work of IF and, while received well by some, I want to learn more and do better.
A bit about me
I’m a software engineer and teacher. I live in San Francisco, California USA.
Like some others here, my first exposure to IF was as a kid playing Infocom games in my parents’ basement. I grew up in the later half of the D&D/Fantasy boom of the 80s, so that dovetailed nicely with the “text adventure” vibe of many games of the time.
I’ve been a lurker here for over a decade; I read posts about games, and played with new versions of Inform, making proof-of-learning games that I’d share with a friend or two.
Where OLoT started
I was visiting my Mom on the east coast of the US for her birthday and to help her convalesce from a fall. Since she wasn’t able to get around, we had a lot of free time on my hands. I’m a fan of cozy-style murder mysteries, so I introduced her to Cadfael, the TV adaptations of the novels by Edith Mary Pargeter (as Ellis Peters).
The central character is Cadfael, a middle-aged, world-wise herbalist of a monastery. He unravels mysteries, sometimes with the support of the prior and abbot, and sometimes clandestinely, against their orders. He’s often helped by his novice.
Clearly, this mirrors a lot of OLoT: a wise, kind older herbalist and a young novice. The big difference is that, rather than the Cadfael-like Aelred solving the murder, he is the victim of the murder, and the novice must solve the crime with only a bit of help from others.
I was also influenced, though to a lesser extent, by Umberto Eco’s novel The Name of the Rose.
The 1980s film adaptation had a big influence on me when I first watched it as a teen. It is partially told in flashbacks and has moral questions at the ending, as well as a bittersweet parting of the main characters.
Like some others, I always wanted to write IF but kept hitting the stumbling block of “what will it be about?” Re-watching Cadfael and remembering Eco’s morally complex ending pushed me to write something in that kind of setting, with elements of both.
Language choice
I respect the CYOA/branching-style games, but they’ve never been my thing. The idea of “I have to figure out what I can do,” rather than selecting from explicit options, has always appealed to me more. I knew this would be a parser-based game from the start.
While I learned Inform 7, I’m not won over: it feels like translating my programmer-procedural brain into a very specific English that is then turned into the programmer-procedural logic again. I prefer something that has syntax and conventions that are more familiar to me and also easier to debug, since there are far fewer abstractions. So, while I followed Inform 7, I’ve always had a fondness for Inform 6.
I started asking questions here about some other I6 things I didn’t understand (and thanks to all—particularly @fredrik, @Draconis, @andrewj, and @vaporware—for their patience and help)
I tinker with 8-bit hardware (mostly in designing and debugging new 8-bit systems, rather than working on actual retro hardware). Having just finished a long Z80/CPM project, I thought it would be fun to run any game I wrote on it. PunyInform was the choice—it’s actively maintained and runs on old, limited hardware of the era.
The monastery
Part of the interest for me was the monastery and monastic life. I’m not a Christian, so I have no personal background in it, but the focus, community, and ritual are deeply intriguing (and maybe for many others here too; I got a lot of early enthusiasm for the setting). Since I lacked that background, I had to research it, which ended up being one of the parts I enjoyed most.
Books that particularly helped:
Early on, I decided this would be a priory, not a monastery (priories tend to be smaller and lonelier). This would trim the NPCs down and enforce the “abandoned” feel of the space.
(In reality, even a small priory would have more people; typically at least as many servants and lay monks as vowed monks. While realistic, I didn’t go this direction.)
I drew the map very early on: this was a setting-heavy project. The original map was bigger (including a calefactory, a heated “warming house”). I tried to strike a balance between including realistic spaces and keeping the map playable, especially within PunyInform’s constraints.
(This proved controversial for some people, who expressed some annoyance at rooms that didn’t feature in puzzles or plot, like the lavatorium (used for washing one’s hands before meals) and the necessarium (bathroom). I’ll defend them only by saying that having these kinds of places helps with the realism of the setting and it’s always fun to include a creepy bathroom.)
I decided to use only N/S/E/W/U/D directions (no diagonals); this wasn’t a technical constraint (PunyInform can use them), but:
- I sometimes find diagonal directions difficult when keeping a game-map in my head
- Monasteries are deeply structured spaces: laying things out as squares might help reinforce this feeling
I divided the cloister into 8 sections; it’s the center of the priory and I thought it deserved more than a single room. This would also let me attach many things to it, and also allow for “you can see other people in the cloister, but they’re not in your space”.
Some commenters wish the cloister could be navigated diagonally (saving two moves in getting from corners); if I did this again, I might include it—but this would be less traditional, since the corners are exactly the places where there wouldn’t be an entrance to the garth.
Making the graphical map early helped prevent needless churn and proved very useful (Inkscape for drawing it).
The crime
It was easier to find the setting than the mystery itself. Early on, I knew the PC would be the novice, and the mentor would be the victim. But why was the crime committed? Who did it?
Early on, I was considering embezzlement, with two monks being the plotters. Having two bad guys would let us eavesdrop on conversations, see communication between them, and even see them meeting when they shouldn’t. However, I realized I could pare this down to one monk malefactor, helped by an outside agent who is off-screen. The cellarer, Hugh, seemed the easiest to fit into a crime, since he would have access to the outside world more than many and have plenty of places to hide things in the cellar.
Poison was the choice for the death; it tied into the herbalist-and-novice setting. I did some research on medieval monastic medicine, and found plenty of choices of things that would feasibly be grown in a monastery and also deadly when misused.
One thing I never quite resolved was how the crime happened, exactly:
Did Hugh force Aelred to drink poison? Did he offer him some heavily-spiced mead? It turned out that since the murder happens off-screen, I didn’t need to know the details, but I probably should have thought it out. I’m still considering adding a broken clay cup elsewhere with traces of poison on it; Hugh would have crushed it and tossed it somewhere it wouldn’t be noticed.
The monks
I decided to make 6-8 monks (I ended up with 10, including the victim and the PC). My original sketches for them were:
-
Aelred, our mentor. Heading toward old age, kind, modest, and wise.
-
Anselm, the cantor (lead of monastic singing). Young and somewhat innocent and gossipy.
-
Benedict, the infirmarer. Kind of classically “monk-ish”, round and friendly and with a set role.
-
Cuthbert, the sacrist (takes care of religious objects, also manages the bells/hours). I think of him as thin, old, and judgmental.
-
Hugh, the cellarer. He’s been in the monastery since he was young and is strong and clever.
-
Martin, the cook. I never quite fleshed him out; he ends up sort of generic-cook.
-
Oswald, the prior. He was going to be an interferer for the player, keeping them out of certain places and from certain behaviors.
-
Remigio, the lay monk/kitchen assistant. I wanted there to be an outsider to the culture, and someone who could be lonely as the PC, but for different reasons than youth.
-
Wilfred, the elderly librarian. He was intended to be the moral backbone of the story, and a helper to the PC.
Since I was aiming for PunyInform and a z3 file, I kept interactions with the monks limited—there was no room for huge conversation trees. Having some monks follow a code of silence also helped.
I ended up with a compromise: you could talk to about five of them, but their responses had limited depth, so asking the same question produced the same answer.
(Some have lots of topics of conversation, though, and some of my favorite writing was in the dialog they did have. In particular, Remigio and Wilfred, from whom you can learn a lot about their feelings.)
I decided that the conversations might provide some backstory for the crime or possibly help explain things, but that these wouldn’t be the main source of clues. As an example: you can learn from a few people that Hugh was “volunteering” in the scriptorium and that this gave him an opportunity to steal items from it.
The cat
I’ve always had cats; I like them. But I hadn’t considered one in the priory.
Instead, my close friend was one of the very earliest testers of the game. She’s not an experienced IF player; it took some convincing to get her interested, and she thought there should be a cat (she really likes them), so I added one, mostly for her.
However, it became useful for giving a little weight to Remigio and Wilfred: they both helped care for Pax (as she was named), and helped reinforce their kind roles. Later, as I added “second solutions” for puzzles, Pax became one: in addition to putting Wilfred to sleep using the burning mandrake root, you can also carry Pax to him, and he’ll drift off to sleep with her on his lap.
It turns out Pax was a favorite for many players, particularly when they found a way to win her over with the smoked fish from the kitchen.
The puzzles
Puzzles were the trickiest thing for me: I thought that puzzles for games required some huge clever leap and innovation. I wanted puzzles; I just didn’t have confidence about them.
Many of mine ended up in the “carefully observe” vein: search things, look under things and read descriptions closely to spot details alluded to but not in glowing “You can also see …” text.
There’s also some “what do I do with this?” puzzles: (the mandrake root, the smoked fish, the pole in the undercroft, the basil) as well as four “locked-door” kind of puzzles:
- the infirmary medicine cabinet (figure out the combination)
- the prior’s door (same)
- the cellar (as it turns out, you never get the key, so this perhaps is a red herring lock; you need to get into the cellar through the secret door from the FitzAlan chancery )
- the restricted garden: a pretty straightforward find-the-key
The more complex puzzles (putting Wilfred to sleep to get into the scriptorium, escaping from the crypt, opening the secret passages into the FitzAlan crypt and the main crypt) were other kinds of puzzles, requiring a bit of cleverness and thought. A few things had clues in Latin, but I tried to make sure these were either translated for the player or were easily Google-able.
The hardest puzzle to get right was the crypt escape, for which the main solution is pretty complex, with lots of timing constraints for the player but also the world model: what happens if a service starts during the escape? or right after? This proved to be a long series of bugs; for some testers they could waltz right by Cuthbert and escape the crypt without solving anyth ing
Two solutions
As a GM for a roleplaying group, I’m a big fan of “multiple solutions” as a design: you shouldn’t make finding one thing be the lock for the next stage. I tried to find workable second-solutions for some of the puzzles:
- there are two ways to put Wilfred to sleep (Pax or mandrake)
- there were two ways to find the restricted garden key (on Aelred’s body or under the pot in the herbarium)
- there are two ways to find the combination for the infirmary cabinet: on the face of the church door or in the Registrum Fratrum)
- there are two places to hide in the crypt (behind Ezra’s tomb, or in the FitzAlan crypt)
- there’s even another way to escape the crypt, through the magical prayer-to-St Jude method.
One of these was a “quantum clue”: the same key could be in either location; wherever you searched first, it was there. I thought that was a good idea, but it puzzled testers: on one round of playing, they’d find it in one place and not find it in the same place later, because they “found it elsewhere” first. I reduced it to one place, but added a strong clue to the one place from the other (if you look under the pot, where Aelred typically hid the key, it isn’t there, but the message tells you that he probably was using it that day, which hopefully leads the player to searching the bo dy)
Evidence and solving the mystery
IF mysteries often have an ACCUSE verb: assemble clues and accuse suspect.
I didn’t do this. I don’t think OLoT is really much of a mystery. After one key clue, it’s clear who the killer is, and most won’t find it challenging as a whodunit. There’s no need to follow people, compare statements carefully, and so on, all of which are classic mystery conventions.
This was designed so that:
-
the game could be won in one play. You may need multiple plays to win, because you run out of time, but you shouldn’t need to play multiple times so that you can observe the same thing from different places, or need to be in this exact location at a certain time.
-
it simplified the structure a bit: there’s no need for you to list the evidence at the end, or have plausible other suspects
-
it moved the plot/writing toward the “why”: why would this person have murdered Aelred and what should you do about it
The last became interesting for me: Cadfael sometimes let murderers go (and sometimes not); justice was always tempered by understanding. I wanted that as a possibility. This was borne out by some testers, who wanted the “mercy for the killer” ending to even include giving them a small amount of money to donate to his ailing sister and nep hew.
I came up with four “main pieces of evidence” and about four more minor ones; the game is winnable with 3 pieces of main evidence and one minor, or two main and all the minor pieces. I wanted the game not to hang on finding one thing—though, of course, you’ll understand the motivations and crime more as you find more.
Game size and PunyInform
PunyInform is a well-designed and well-documented library; it’s been a pleasure to read its code and work with it.
I originally chose it so that my game could fit in a z3 file, for retro purposes. For a while, it could. Soon, the amount of text became a constraint (while the game is smaller than Infocom-era z3 games, it has far longer text for item and room descriptions, and there are many more examinable objects in a room than typical of these games).
For a while, I “solved” this by tightening text and putting lots of things in #Ifv5 conditions; some rooms were eliminated for z3 and even one of the NPCs. This worked, but the main mechanics of the game (NPCs moving around the game automatically, people noticing you carrying things or doing things you shouldn’t) meant that there was fairly complex code that had to run each game turn. This started to make it sluggish to play on retro hardware, though it works fine on a modern-ish 8-bit computer, like some of the relatively fast z80 machines.
In the end, I tore out the conditionals; they made the code complex and, while there could be a z3-playing game, I wouldn’t have recommended it: without the rich descriptions, it would always pale against the better version.
The Spring Thing version comes close to the limit for a z5 game; using the Standard Library instead makes it too big a z5 game; it would need Glulx or z8.
I’m not sure if I’ll build my next game in PunyInform: with more space, I could have made some things richer, and not worrying about space and execution time would avoid some code-base compromises. I may build in standard-library I6.
Code challenges
I had to come up with a simple dialog system; it’s not innovative.
I had to come up with a simple “scene” system. I ended up with a Scene class and scene subclasses (like DeathInSlype); these stay in scope and can influence what the player can do during each scene.
I made a few “one-more-round in this scene” decisions, which proved to be a magnet for bugs: for example, the DeathInSlype scene has one final turn after Aelred dies but before you’re whisked to the chapter meeting, and the chapter meeting has one free turn after the meeting before all the monks leave. This leads to lots of things to watch out for: things you might do with Aelred-dying are quite different than Aelred-dead, and a lot of reactions have to have conditionals for that.
Dead bodies or statues also had challenges: they’re kind-of-animate (you can kiss them, for example), but also not living. I made them animate, and then had to block lots of things. I probably should have gone the other direction, and changed the grammar for a handful of verbs, so some inanimate things can be given things or be kissed.
Design choices & questions about them
SEARCH / EXAMINE / etc
Since you’re an explorer, I did draw distinctions between EXAMINE, LOOK, and SEARCH (and even LOOK UNDER). I know this is controversial for some people. Opinions welcome.
Invisiclue Hints
I personally really like Inivisiclue-style hints: they’re can be fun to write and read, and can give staged hints. Having a general “give me a hint” command would be difficult in an open-ended game like this; there are lots of puzzles that can be open at most points, exactly what you want a hint on would be difficult.
PC Identity
Classic text adventures often had no player-identity (the AFGNCAAP trope); I wanted a real character identity. I flirted very early on with a priory/nunnery kind of switch, so you could play as one of two genders, but I realized quickly that monastic life was very different between them, right down to the architecture of the buildings. I chose to make a male monastic setting. (This is mildly ironic to my friends: my post-undergrad education has focused in gender studies, but yet I’m building this all-male game). I’ve tried to give our PC some flavor (and a name, mildly hidden), a backstory found with research in a book, and some restrictions on what he’ll do.
Player Agency
In the classic Zork-ian style fashion, you can do anything you can physically do: steal everything not nailed down, attack anyone with your trusty sword, etc. This made no sense for this game: you’re a novice in monastic life: you are strictly regulated in where and what you can be. Our PC can’t leave the monastery grounds because (in addition to the world-expanding downside!), he’s not allowed to. You can’t desecrate things or steal sacred objects or shout randomly, and get warnings preventing you from even dancing or talking in some areas.
Solving a mystery with limited agency can be tricky, so I made it so that you can “do” more as you discover more. Once you’ve ascertained that Aelred was poisoned, you can search other monk’s personal property or enter some rooms that tradition would forbid you from.
I also made it so that you can’t do some things where other could observe: you want to solve the death of your mentor, but still: you dare not climb on that altar in front of Brother Cuthbert.
This also leads to both a meta-puzzle and an irritation for some players: you have to cover your tracks when doing things you shouldn’t: don’t leave the door to the library open—you shouldn’t have been there. You shouldn’t have stolen a candle; carrying it around leads to trouble from to others.
Initially, the game was very strict here, which felt unfair and lead to a lot of tester death: I loosened it to “one warning for a careless thing and a few warnings for carrying things you shouldn’t” and made “where to hide things you carry” into a puzzle. I’m not sure I nailed this properly, though: quite a few players reported enjoying the game but felt caught out by losing unexpectedly for failing to hide something.
If there were no prohibitions, it wouldn’t feel realistic to me. I’m not sure how I’d solve this if it came up again.
Structure and services
In some ways, I can press this game into a three-act structure:
Act I
The opening service, the limited exploring, the death scene, the meeting.
I wanted to make the services a central background for the game: these are the very backbone of the monastic life. There are seven or eight daily (depending on your order) and happen at strict times and attendance is mandatory for most.
I thought, however, that “you must go to all services” would be flat and repetitive (even if “repetitive” is exactly what they were in life!), so decided that, given Aelred’s death, you’d have required work in the gardens and therefore had special dispensation to do such (leaving space to solve the crime). Remigio, as a lay monk (as opposed to a choral monk), would also be free from services, so you could interact with him during services. This is also why he’s unusually built out, dialog-wise.
However, if you appear during a service, you have to join it (clearly, you weren’t in the middle of your garden-inventorying work you were assigned!). So finding a way to see the schedule of offices, tell the time semi-accurately, and know how to get around without appearing in the quire is a kind of meta-puzzle.
I needed a way to make what the offices (aka services) were and how long they lasted and what happens in them very clear. So I made it mandatory to go to the first one, and open the game there: this does what explicative text couldn’t: you have to know where they are held, you will learn how long they last, etc. This led to a forced-scene (you have to go, have to sit, have to sing), but left plenty of time for you to get some bearings on the NPCs: you can examine each, inventory yourself, etc., during the service. This led to some annoyance at players who want to leap from bed and explore everything, missing the clues that you should following everyone else to service. It used to end the game if you didn’t; now, you’re simply dragged to service. Apologies to @andrewj, my very first tester, who had a short and losing battle against the game at its worst and cruellest; he probably lost 8 times in a 5 page transcript for not doing exactly what I thought the PC should do. Fortunately, his reaction gave me a strong impetus to loosen this up.
You then are given some time to explore, in a limited sense. You’re cut off from some areas because other monks are these; this was designed to give a smaller map to get your bearings in the church area, but also to allow time for the murder to happen off-scene. After a while, Remigio finds you and leads you to the death scene. This involves some restriction: you don’t have to follow him, but he’ll follow and pester you, and if you continue to avoid going toward your dying mentor, the game will end. I need the player to be at the death scene, after all, both dramatic and investigatory reasons.
The death scene is similarly-locked down: you can’t leave it. You can shout for help (none comes), you can try to aid Aelred but (no great spoiler): he dies anyway. Such is the need of a murder mystery.
The chapter meeting comes next: this is exposition about what is happening today, what you can and can’t do, and it puts you in an important room with time to kill so that you can examine the statue and the office times, both important .
I don’t love that the game has so much restriction on Act I (shades of Zork Zero, ugh). But I don’t know how to solve this otherwise. Ideas welcomed.
Act II
Wide-open exploration
After this, the game is pretty wide open (with some limitations on player agency, above). Most puzzles are independent and don’t gate other puzzles, so there may be 5 or 6 things open at a time.
In retrospect, I should probably have staged a little more here: sneaking into the undercroft probably should only be allowed when you already have good reasons to suspect Hugh, and this could move into Act III, making it a bit ri cher.
Act III
Revealing the killer, choosing the ending
By the third act, you’ve gotten enough “evidence points” (an internal variable, used to gate whether or not you can reveal your suspicions).
As mentioned earlier, there is no ACCUSE and find-out-if-you’re-right. At this point, surely the player will know who is the murderer. That’s by design.
There are a few ways to do this:
- confront them privately in their space (leading to you being the next victim, in a particularly Victorian Gothic novel way!)
- confront them publicly during service (leading to the “Justice” ending)
- talk with a trusted monk, leading to two possible endings
Moving around
As mentioned earlier in the Monastery section, I intentionally don’t use diagonal movements (not a technical limitation, a design choice).
I don’t supply a GO TO ____ command, even though some have become quite used to that in modern IF. The game requires time-tracking and also who you run into along the way, and how they react to you. Teleporting the player to somewhere would break some of that.
I do give the player both a graphical map and in-game maps. You’re playing someone who lives in the space, so there’s no mystery about how to get from A to B for the PC. I was surprised how often testers (and even some players, from the comments) didn’t use the maps. Perhaps they think of these as solution-aids rather than something I expected players to be consulting normally throughout the game? I’d probably make that clearer in the intro.
ASK/TELL vs TALK TO or menus
I don’t like dialog menus in general: for me, part of the fun is having to figure out what to ask people and not choosing from a menu (which at least for me often turns into “try all the choices one after another”). I like that you can do non-obvious things that don’t have a ton of game meaning, like ask everyone about the cat , leading to feeling like a little win that you thought of that.
There is the obvious downside of “oh no, maybe I just missed the right verb” kind of problem. I tried to ameliorate this by having lots of adjectives for conversational things (there are about 15 ways to ask about murder/poison/etc), but it remains a known problem of open-ended questions.
I might consider in the future stealing from systems like Lost Pig, where you must stumble across some things, but as you get answers from some questions, some are prompted for you.
Things I cut
I wanted to have a dining scene (partly inspired by the dining scene in Christminster): this would have expanded the size too much and provided too many converation points.
I wanted to have a reason to get onto the roof: from there, you could witness something important. I had a puzzle for how to get on the roof, but I just couldn’t work in the “witnessing” thing, so I cut it.
Automated tests
I don’t think I did anything innovative here, but I did have to patch together something from hints other have had about their systems.
Early on, I tested things manually with some helpful debugging verbs to GOTO ROOM or PURLOIN THING to get rid of tedium. I also allowed a tester to find the exact time or even set it, as well as start/stop scenes programmatically. That served fine in the beginning.
At the point the game could be played to a good ending (even if terribly fragile), I played it, cut the transcript into ~20 pieces, numbered them, and made those the unit tests for the game. Over time, alternates appear: 7-wilfred-sleep led to 7a-wilfred-asleep for the other way to do that . My Makefile concatenated these into playable streams, which I fed into Makefile-driven bocfel, and diff’d the output against the previous text.
@zarf has a much more powerful solution for this (which I don’t remember the name of, sadly), but his has a different design goal: you write expectations with things like regexes; mine just blindly compares text and shows a nice diff. I want every text change to appear; Inform programming can have so many tiny nits like “oops, I need to move the end-sentence-period outside of the ‘if’” and so on, that I caught lots of those by textual comparison rather than ‘tests’ per se.
I did add a GOCHECK ROOMNAME debugging verb that checks if you’re in the expected room, rather than moving you there, and violent dies if you’re not. That makes it a lot easier to tell when a playthrough test goes off the rails, rather than noticing 17 moves later that you weren’t where you thought you were.
I don’t know if it’ll be useful to anyone, but I’m committed to releasing the full source code for the project. If anything here sounds useful for your games, please steal, repurpose, staple, and mutilate!
Tooling & my attempts to improve
While VSCode isn’t my favorite editor, the Inform6 plugin for it was very helpful for color highlighting.
However, I really missed things like “jump to this symbol”, debugging-with-breakpoints, rename-symbol, and other IDE-like qualities.
I’ve started working on a more complete Inform6 workflow: a language server that offers color highlighting, symbol recognition, renaming, code structure, and debugging. It’s currently usable and works for me, but isn’t yet polished for easy installation by others (and, as a warning that unlike most of my other coding, it’s co-developed with AI, so if you strongly oppose using AI-assisted software, you probably shouldn’t use it). It works with VSCode and VSCodium, and should work with other editors/IDEs.
I also wrote a system, Flutterbug, to let friends play IF together without needing a server or Zoom-like screen sharing. This let me play Thorns with friends and filled a gap for me: I don’t want a Zoom call or MUD-style setup, but I do want to play IF with friends in different places. It works well, and I’d be happy for people to use it.
They’re minor, but I also wrote some Python packages for the IFDB API and Babel data formats; these are used by Flutterbug for extracting game info.
Flutterbug Terps: Flutterbug by default uses Dannii’s “emglken”, JS-compiled terps for common formats. I wanted to be able to cooperatively play other formats than emglken uses, so I started a project to compile other formats to binaries against RemGlk-rs; this allows you to use Flutterbug for formats like ADRIFT or Magnetic Scrolls. This is heavily based on the work for Gargoyle/garglk (so thanks for that!)
I’m also writing a “build a website for my IF game”, like a much-expanded version of I7’s “Release with a web site”. There are already some efforts in this direction by others, but I’m aiming for something a bit broader and YAML-driven, and including things like nice HTML output for associated markdown files, transcripts, and so on. Ultimately, I’ll switch over my hand-coded site for Our Lady of Thorns to this.
I’m pleased that the process shook some bugs out of PunyInform—particularly one involving games at the upper bound of file size. Hopefully, this can help other people build medium-sized games with Puny.
Thanks to everyone who’s been so patient with my new-author PRs and bug reports to their libraries and systems, and their kind advice on my work. You’re a really welcoming bunch, and I really appreciate it (particular shout-outs to @Dannii and @fredrik and @vaporware)
Also: while it seems like some IF projects are ‘cathedral’ style, one-author-releasing-to-the-world, I’m more used to open sharing of rough things and would welcome anyone who wants to critique or contribute to these. Please do!
The future
I’m done with the game as far as new plot points or rooms or such. I’ve fixed a few bugs and will release a post-Spring Thing game in a bit. I’ll let people know.
Overall lessons and thanks
I really enjoyed this process, particularly the research, dialog writing (even if sparse), and playtesting. I entered Spring Thing because @Ally suggested it; I wouldn’t have thought that I was writing something competition-worthy, and her enthusiasm for the project, even at the earlier phases of testing, was enormously helpful.
I’m deeply flattered to win Best of Show; my ambition was simply that a few dozen people who weren’t already my friends would play the game. Getting positive feedback and audience awards is really wonderful.
I can’t overstate how helpful the community has been—I arrived with lots of questions and scattered energy, and the level of help I’ve received has been so encouraging. I had so many testing offers, including from IF-famous testers. People like Ally, Draconis, Rovarrson, AERobert, Warrigal, AndyG, tmack, and Doug_Egan deserve extra thanks for surviving several rounds of testing and providing pages and pages of feedback.
Fredrik answered many PunyInform/I6 questions with patience, as did Draconis, zarf, andrewj, vaporware, Giger_Kitty — and many more! Thanks to Warrigal for supplying some fine code for better handling locking and unlocking doors.
Will I do this again? Absolutely. I’m already planning my next game. I look forward to sharing it with you all!
Love, Joel