A maze of twisty little passages...

It's been 9 months since I was in the midst of porting Dungeon (aka mainframe Zork) to Sharpee as a dogfooding process. Of course the infamous maze is within the game and works as expected.

A couple of months ago I started working on Chord, a more natural IF modeling language that builds on top of Sharpee, now know as "the platform".

And yet one simple Sharpee/IF concept escaped Chord's implementation. In 3.6.0 of Chord, you cannot create multiple rooms with the same name. The Id and Name are properties of every object in Sharpee, but Chord doesn't surface them in a way that would allow you to create multiple rooms (or objects) with the same name.

So I started digging through the code, thinking this would be a simple change. And then I went down another rabbit hole.

The way I constructed Sharpee and Channel IO left the template client with two different values: one is room name and one is location and even though they derive from the same underlying value, they are brought to the web page in totally different ways.

So I said to myself, "That can't be good."

Long story short: I ended up digging through 10 layers of how text gets to the web page and defined a new primitive: IFElement. An IFElement is something you read on the web page as a part of the game. It can be the location name, the score, the turn count, the time, the room description, and even the prompt.

I have channels! Yes, but channels are different than IFElements. The analogy is something akin to HTML and the DOM or TCP/IP and HTML. I don't know. There's an analogy in there somewhere.

The scenario that bit the hardest was the status line location name vs the inline location name. Those can be two different outputs.

Status Line might get:

The Well Room (in the bucket, filled with water)

While the inline text might be:

The Well Room

In this case, I have two text blocks derived from the same IFElement, but in one case it has an amendment and the other it does not.

What is an amendment? I don't know. So I drilled down into how this concept of an IFElement could be amended and that really broke my brain (and honestly it made Claude make a lot of really bad guesses at how to proceed and this is where people who think we're all vibe coding are dead wrong - this is hard work).

I had to model several different scenarios to find determinism from previous stories and then find a path that makes sense to authors in both Sharpee and Chord.

I am NOT getting into those details YET, mostly because although I wrote several ADRs on this rabbit hole, I am only implementing one of them now, so Chord gets multiple rooms with the same name. But this change is a part of a potentially much larger change that I need to ponder for a bit before deciding whether I want to do another golden test refactoring (touching 80+ files in the world model package).

But the rabbit hole did lead to the concept of IFElement that is different than an output Channel and different than a TextBlock. They are all primitives with their own use cases. Just not sure how to throw all three in the air and have them land elegantly.