David A Cornelson

In a previous post I got a little carried away with all the great testing results, but that ran into an expected wall. Unit and integration tests are meant to validate your architecture and code and expose gaps. Well we discovered a few gaps and it took us a minute

Now sure if this is true in other platforms like Inform or TADS, but while designing Sharpee it became clear that the Parser makes a ton of assumptions about vocabulary and command structure that are directly tied to the language the author is using to tell their interactive story. I

In the midst of testing the platform (everything is building and Core, IF Domain, Event Processor, World Model, lang-en-us, Standard Library, and Engine all compile), there were some actions without clear implementations. For scoring, where do we keep that data? In the player entity? In the world model at some

I've copied the ADRs to the GitHub repository. You can view them here: https://github.com/ChicagoDave/sharpee/issues

So we ran into a goofy problem that would only happen in a modern architecture. Encapsulation is something IF development has rarely adhered to and Sharpee leans into it. The event source and spatial indexing (the implemented world model) have event-based interfaces and you currently can't change things

There were some challenges here, specifically visibility. I have about 10 ADRs (Architecture Decision Records) that I'll share that address complex issues like lighting. We implemented a baseline standard isDark lighting system and this can be replaced with future extensions. PASS tests/unit/world/visibility-behavior.test.ts (18.

Rewind A little over three years ago I started playing around with elements of a new IF Platform built in C#. The vision included a graph data store, text service, and not much else. Then when ChatGPT arrived, I was able to make some progress, especially learning new patterns, but