Sharpee Updates 1/13/2026

Technical Development Development Systems
1

For GenAI haters, you probably can skip this post. I use “we” in relation to using Claude Code.

If you’re not following my blog (https://sharpee.plover.net) (which does show up on planet-if), this is a little rundown of the work that’s transpired in the last two-plus weeks.

I had paused development on Sharpee in September and restarted in December after Christmas. I had another project sort of capture my attention and that’s released (https://ledga.us - not IF related).

In that short span, Claude Code improved its capabilities dramatically and the blockers I had in September just vanished in an hour of work. With the stdlib mostly ready, I decided to take on the task of porting mainframe Zork (DUNGEO) to Sharpee. If we’re going to prove the platform works, we have to throw the kitchen sink at it.

This work started fast. We had a working game, full map implementation, most of the objects and treasures, many of the puzzles, all in the first week. Then Sharpee’s capabilities started to show their true colors and we had quite a bit of refactoring to move forward.

This included how grammar→parser→vocabulary works, how events work, how to chain events, how to manage annotations and identity, story form, and finally text rendering in one of several clients.

We spent the next week working on VehicleTrait, IdentityTrait, ContainerTrait, and their composition to make the Frigid River puzzle work correctly.

SIDE NOTE: In the original Fortran, there are no actual “Vehicles”. It’s all flags and smoke and mirrors to make it look like you’re in a moving container.

We eventually got VehicleTrait to work the way you think it would. Really nice evidence that the overall architecture continues to hold up from core development and architecture principles.

We designed several ADRs to cover all the text rendering logic:

image
image304×328 5.85 KB

This was a natural pause from the port of Dungeo back to Sharpee platform requirements.

We’re now working on tying all the loose ends together into a set of clients (CLI, React-Web, then maybe JAWS or other screen readers).

I already know bundled Sharpee and Dungeo is very fast and will work in any browser.

I definitely see several WIPs getting completed this year using Sharpee. By using Typescript, I can generate all the code for any story I want to tell. Claude’s top tier developer platforms are python and typescript/javascript. I even have plans for an IDE that authors can “direct” their story development and generate a bundled sharpee app into CLI, React-Web, React-Electron, or others.

Much more coming this month.

4 Likes
2

Sounds good. Do you have anything we can play?

3

Very soon.

4

Side note to the side note: The orginal mainframe Zork is not the Fortran version. The Fortran version is almost similiar to the MDL one, but there are some small differences.

1 Like
5

I eventually turned to the MDL source.

6

Can you talk a bit more about what Sharpee is and how it differs from other JavaScript IF engines?

7

Can you talk a bit more about what Sharpee is and how it differs from other JavaScript IF engines?

I honestly am not familiar with anyone else’s JavaScript platforms, but there’s a reason for that. Here’s why Sharpee exists:

  1. I was hit by lightning around 1978 after discovering ADVENT and DUNGEO on paper terminals connected to Milwaukee Public Schools PDP-11.

  2. I was a huge advocate for Infocom and a fan of all of their games.

  3. When I saw a blurb about TADS somewhere, I bought it and was hit by a second bolt of lightning: a) you can make your own games, b) you can make your own platform to make games

  4. I made an editor for Inform 6 that ended up being an engine for someone else’s Inform 6 editor. Started understanding compiler and language concepts.

  5. I was always aware that although I am an excellent software engineer for business solutions, I am not a hacker or systems developer. Compilers, machine language, virtual machines: these were all beyond my patience and skill set.

  6. I have always been one of the many fools interested in making my own parser-based IF authoring platform. The complexity of grammar/parser/world model/standard library is very puzzle-like and that’s catnip to my brain.

  7. GenAI enabled me to research how to build an IF platform and take on the systems developer role.

  8. I have had nit-picky issues with existing platforms, but mostly Inform since that’s what I’ve used the most. The primary ones include:

  • separating text emission from turn execution: The entire logic of “say” and “print” are archaic in my mind. Managing punctuation and white space is goofy in this day and age.
  • virtual machines: they do serve a cross-platform purpose, but their invention was based on restrictions today’s computers don’t have
  • speed: I had wanted to build a simple fluid layer on top of Sharpee to speed up story development, but after working with Claude for a year, I realized that’s no longer necessary or even interesting. I’m now build an IDE (or will) that has a small language model trained on Sharpee and IF that will enable authors to write their stories and have Sharpee do all the programming heavy lifting.

What is Sharpee?

It’s a traditional parser IF platform that has all the usual elements with first-principle implementations for language, and uses modern data structures for the world model, events to track progress, text blocks to transform story data and text to templated output, vocabulary filters for punctuation, story form, and identity, and separate text service to pull it gather the text blocks and send it off to a client.

It still has grammar definitions that very similar to Inform and TADS. The parser and command validator handle validation to the world model, and the standard library has action traits and behaviors that follow a similar pattern to Inform 7.

Any questions?

8

I have no questions, but I do think the world needs new systems. Most people look backwards instead of looking forwards. Old systems were designed around hardware limitations. A new system today should be quite different. Copying how old systems worked could be a mistake.

9

There’s a difference between copying code/system design and using established patterns that work. My grammar and parser are very different in their implementation, but are familiar to anyone that’s used legacy platforms. That’s the patterns part, not the code part.

Grammar is still grammar whether it’s 1978 or 2026. Parsing a command still comes down to tokens, verbs→actions, disambiguation, etc.

The parts I made different are architectural using modern technology.

1 Like
10

I agree with you on virtual machines and significant whitespace is evil. Guess what I’m looking for is a sense of what it would be like to write an IF work in your system.

By the way, I’m working on my own IF system for JavaScript that is based on a semantic network, a fluent interface, and an event driven system that blurs the line between parsed input and mouse input. Was wondering how much overlap there might be between the two systems.

1 Like
11

If I understand right, the goal of Sharpee is that the author-facing interface is an LLM, and the actual APIs are designed for that LLM to work with, rather than a human? (Which is why the code samples are even an order of magnitude more verbose and explicit than Java—quite a feat!)

12

I found this presentation about designing the worst computer language and yes, the whitespaces are significant.

13

If that’s correct, it’s a very novel approach and worth exploring I think. I assume the author’s source code would look something like Inform, but the compiler (if that’s the correct term) would be far more forgiving and closer to natural language?

14

ok, i realise you’re not copying the way old systems worked but you are copying what they do.

So i do have questions:

  1. How will dialogue and conversations work in your system?
  2. How will media like pictures and sound work?
  3. Can you overlay pictures to make a scene or animate them?
  4. What about clicking on text and picture elements is, this a thing?
  5. Can you have choices as well as parser? Can you have both in a game?

Frankly, and i don’t mean to be disrespectful, but i think your plan of implementing Zork is a waste of time. Zork is there already. New systems should have a new game. What is that game? It should be something that the old systems cannot do and yours excels at. Otherwise why?

1 Like
15

Yes, this is the sort of thing a new system should do.

16

Maybe what this is doing new is providing a new way to create classic a classic genre. There’s nothing wrong with that and you have to start somewhere.

17

Implementing something like Zork or Adventure can be a good stress-test for a system as it’s being developed, so I understand the logic there—it proves that your system can handle all the classic features. But yes, a new system will generally need an original game to show it off.

18

I could be, but a new system doesn’t have to specifically cover all the classic features. Unless that’s what it’s all about. But then I don’t understand why you’d want to make a new system to author classic style games, when there are plenty of fully working authoring systems for doing just that.

1 Like
19

it might well be. But there’s a danger of being dragged into the design details of classic features at the expense of thinking about new, more modern, ones.

1 Like
20

So i do have questions:

  1. How will dialogue and conversations work in your system?

  2. How will media like pictures and sound work?

  3. Can you overlay pictures to make a scene or animate them?

  4. What about clicking on text and picture elements is, this a thing?

  5. Can you have choices as well as parser? Can you have both in a game?

  1. That will be an extension specific to the kind of conversation system one wants. See ADR-102 in the repository

2-4) I just wrote ADR-101 about matching Hugo’s GUI capabilities.

  1. Just added ADR-103. I was going to punt back to “Use Twine” but there are reasons to use Sharpee for choice-based (automated testing).