Author-Enabled Client Architecture

Back in January/February in the midst of porting Mainframe Zork (Dungeon) to Sharpee and burning the rough edges off of the platform, Claude did something weird. It inferred a working version of my envisioned Text Service that was not really my vision. But it was weird because it actually worked extremely well. I let it go because that success allowed me to focus on Sharpee the platform.

In the last week I was doing a little R&D on a multi-user client that would allow multiple users to play a single game, including chatting. This follows a similar pattern used in Club Floyd on ifMud. I wanted this to be something anyone could deploy, so I made it a docker container with both the server and the client components. Claude wanted to use web sockets to provide the communication and a part of my interest in GenAI is sometimes letting it do things I'm not entirely comfortable with as a solution. We actually got to a working version, but there were issues. Save/Restore wasn't working properly.

Then we discovered that web sockets are not very reliable in the configuration we'd setup.

Let's take a time machine back to my Textfyre/FyreVM days. At the tail end of my interests in FyreVM (fyrevm-web, fyrevmweb-react) I had managed to evolve the Channel IO system to include dynamic creation of channels with defined data types.

When I had envisioned the Text Service of Sharpee, it included an updated, Typescript version of Channel IO. I forgot to tell Claude that and it did its own thing (that as I said, worked). The multi-user web socket implementation exposed the need for Channel IO and to reimplement the Text Service properly.

I started with Claude, explaining Channel IO and giving it the old Inform 7 fyrevm-web extensions. I suggested we create a new Channel-Service. We got through the design of that and then I asked Claude if we retain the current Text-Service and it did a thorough audit of all of the current platforms (Zifmia, CLI, Platform Browser) and it came to the conclusion I expected: Text-Service would be replaced.

Another aspect of the current client architecture was Claude also assumed the clients were "hardened". I ignored that little misunderstanding too. Until now. I explained to Claude that user interfaces should allow authors to design their own thing. The banner image above is an alternate UI element that requires Sharpee to provide logical content to set borders, background colors, and alter text as the player works through the mystery. The Alderman has its own set of custom actions to allow the player real detective capabilities.

So here we are. Circling back on a technology I designed 18 years ago for Textfyre (with Tara McGrew's implementation in C#).

The result will open up author-designed user interfaces, including graphics and custom HTML designs like the banner score card.

I've attracted one IF community member to pitch in with the tutorials and to build other stories in Sharpee. I'm always happy to add more collaborators to GitHub.