Previously, I half-assedly theorized that, given a timeline on which I'd store state mutations, with each mutation being an action taken ingame by either the player or computer, I could feasibly construct a somewhat generative narrative engine.

Basis: the system reads the current state, builds [some structure] holding possible choices, and prompts the player to take an action from those choices. The action modifies the state, and the loop begins anew, save that now it's the system "prompting itself", so to speak.

Utterly barebones and abstract as it may be, it was useful to build this concept in my head as it gave me a way to reason about what I wanted to build. But there were two problems which I had to grapple with:
- What would [some structure] even be?
- How would the computer make choices based on an instance of [some structure]?

I found myself striking the philosopher pose for long hours on the toilet, deeply pondering these questions which I couldn't help but merge into one due to the shared incognita; silly brain wanted trees but I kept figuring out that's not going to work as the relationships between symbols are sometimes but not always hierarchical. Shhh, silly brain, it's not trees.

So what is the answer?
Well, can you guess it?

Graphs, of course it's fucking graphs. Specifically, a state transition graph. It was right in my face the whole time and I couldn't see it. Well, close enough.

It's ideal as the system in question is a finite state machine with strong emphasis on finite -- the whole point is narrowing down choices, which now that I think about it, can also come down to another graph. Let me explain.

A 'symbol' or rather SIGIL is an individual in-game effect. To this FSM, it's an instruction. Sigils are used to compose actions, which you can think of as an encapsulation of some function, or better yet, an *undoable transaction* which causes some alteration in the game world.

But to form a narrative from a sequence of such transactions, and to allow the system to respond to them coherently, relationships need to be established between sigils in a manner that can be reasoned about in code. You may not realize this yet but this is both a language processing and text generation problem, so fuck me.

However, we have a big advantage in that we are not dealing with *natural* language, that is to say, each sigil is a structure from which we can extract valuable information on the nature of the state transformation applied.

This allows us to find relationships between sigils programmatically: two words are related if some comparison between the underlying structure -- and the transformation it describes -- holds true. Therefore, if we take the sigils that compose the last transformation in the timeline, fetch relationships for said sigils according to a given criteria, then eliminate all immediate relationships that are not shared between all members of the group, we end up with a new one that can be utilized as starting point to construct a reply.

More elimination of possibilities would have to be performed as this reply is constructed [*], but the point is that because the context (timeline) is itself made of previous transforms, the system *could* make such a reply coherent, or at the very least internally consistent.

Well... in the world of half-assed theory. I don't know whether I'm stupid, insane, both, pad for alignment, or this is an actual breakthrough. Maybe none of the above.

Anyway, it's another way to mentally model the problem which is very useful. New challenge would be the text generation part, extremely high chance of gibberish within existing vision; need more potty-pondering.

[*]: I'll break it into bits OK.

0. Determine intention. That's right, the reply isn't actually _fully_ generated, it's just making variations on a template. So pick a template depending on who is taking a turn and replying to who (think companion relationship score bullshit)

1. Sort the new group according to the number of connections the constituent sigils had to the context from which they were extracted, higher first.

2. Pop from the sorted group (least connections). If there are other nodes left in the group, and it doesn't connect back to any of the other nodes (sigils) up to a certain distance, then discard it and repeat. Else keep going.

2. Unshift from the sorted group (most connections). If can traverse up to another sigil in the same group, then go for it. Else derive search criteria from current context (including intention), so as to look for another sigil to concatenate. Some form of weighting would be needed here, need to think about that.

3. Decide when to stop. Probably some chance, as in the more sigils you have, the lower the chance a new one will be added maybe. Need to think about this too.

4. Send transform, loop begins anew.

And that's it. So alright brb I'm going to take a dump on the Agora.