Another Refactor Bites the Dust

Note: This is me writing again. I heard from some of you and I will save the info dumps for the repository under /docs/blog. Going forward, the blog will be the tumbled chaos of my own brain.

We have another reveal, discovered when attempting to make a standard text service for a WebAssembly browser client. The interface in ISemanticEvent has a data property of type Record<string, unknown> and Typescript sometimes gets befuddled trying to convert that to an array of objects. This led to an initial refactor to change the type to any or unknown. That was very late last night. Today, I was thinking about it again, discussing it from the Desktop app without any direct knowledge of the project. I dropped some code and thoughts in and then mentioned, "what if the events were atomic?" and things got interesting.

This actually revealed a number of things:

• the current event source, on replay, could be inaccurate if there were entity description changes.
• without every event being atomic, the event source is not a "true event source".
• this would make testing much simpler.
• this would eliminate the querying interface of the world model and cut the cord in that tightly-coupled relationship.
• any text service is just a report. no more need for translation from layer to layer.
• events would be larger, but that's an acceptable outcome.
• we would need to ensure properties could be values or functions, which is something we've been wrangling with all along.
• we also had some legacy properties in ISemanticEvent that we can prune.

This is another top to bottom refactor that will touch nearly every file. I thought about doing a hybrid refactor, but this directly impacts my vision for dumb text services (read the events, organize the text by semantics, emit the text into a json object and send that to a client (browser or cli or whatever).

The weird part is removing the world model querying interface. That was something I thought was required, but with true atomic events, we have everything we need at the end of a turn.

Some of the questions I've gotten from the int-fiction forums will be added to unit tests, integration tests, or eventually what we're calling, story tests. Story tests seem to be needed to test complex capabilities, though it's possible atomic events will alleviate that as well.

I've also added to the wish list a full conversion to C#, but that's definitely coming after we have a few working games.