Memotica’s stimuli are part of the world trinity of actions, entities and stimuli. In Memotica, entities have state, actions change that state and stimuli report about it. I’m putting the finishing touches on how memotica handles complex stimuli. In fact, I’m just about ready to start coding the stimulus handling portion of the interpreter code and I need to work out the stimulus corner cases before I call it a day on design and go to code. What I’m looking for is ideas on how to accomplish the same flexibility with less complexity and additional corner cases so that we can do thought experiments before going to code.
The Memotica stimulus is a complex – but flexible – beast with a certain life cycle. A stimulus entity is created from a meme when something needs to be reported to a client. This client could be anything; a user, an AI superclient, another system, etc. This stimulus then goes through a series of life stages before seeing the light of day.
Filtering – A stimulus entity may contain “controversial” elements. A controversial entity is any entity in Memotica that is dependent on a condition being true. The very first step in bringing a stimulus to the light of day is filtering out untrue controversial entities.
Resolving – The filtered stimulus may undergo a process of “in context” transformation. “In context” means that it is subject to the state of any or all entities currently in play. Creating dynamic text strings must be done in context. The smell of roses is quite distinct from the smell of mold and it is possible to build both from the same stimulus by substituting different nouns. Which one is created is determined by the state the universe. Are there roses nearby? Is there mold nearby? It is not only text that may require resolving. Is the ball blue? Is the ball red? How big is the ball? How much does it weigh?
Resolving the stimulus may tell us that we have a blue ball, 30cm in diameter that weighs 100 grams. It tells us nothing about how we might inform the client of this information. That is handled in the next step, rendering.
Rendering – A resolved stimulus must now be prepared for a client. Rendering is out of context and does not require access to the state of any entity outside of the stimulus (or stimuli) at hand. Rendering the ball for a player’s 3D client might involve creating a COLLADA file with a ball mesh and a blue texture. Rendering the same ball for an AI engine might involve building a short message, [BALL, BLUE, 30, 0.1], that is readable by that particular engine. Rendering the ball for a text client might involve selecting the fallback text description.
Any particular stimulus may skip any of these steps. A stimulus with no controversial entities need not undergo filtering. The COLLADA renderer for the ball may be perfectly happy with the filtered entity and may not need any interim resolving. Resolved Unicode text probably needs no additional rendering beyond having its text string plucked out. A stimulus entity that is simply syndicating the state of an entity for another system may skip all of the steps between creation and being forwarded to its destination.
To delve deeper, first we’ll start with the stimulus metamemes. Stimulus is a simple switch with no attributes. Its children are AnchoredStimulus and FreeStimulus. If our child is a FreeStimulus, then it simply displays whatever descriptor (e.g. a text string, a mesh, a texture, etc) assigned to the free stimulus. A free stimulus is uncontroversial unless it has a ConditionalStimulus as a grandparent.
Anchored stimuli are a bit trickier. Their existence depends on their children. You would use an anchored stimulus if a supporting piece of information is required. One example is meshes. A mesh alone is useless. It needs a material. If the material can’t be displayed, then we wouldn’t even bother sending the mesh to the client. To find the materials, we would need to use anchors.
In general, this is how an anchored stimulus works:
- An anchored stimulus can have one or more free stimulus children. Any free stimulus children of an anchored stimulus are non controversial, but the anchored stimulus is itself inherently controversial.
- For the stimulus to be resolvable/renderable, at least one grandchild ConditionalStimulus must be true. The anchor member of an anchored stimulus is a collecting point for its controversial members. This Anchor entity may have 1 to n StimulusChoice entities. It is useful to note that FreeStimulus may have member StimulusChoice members by proxy as well, via the SuccessorStimulus; which I’ll discuss in a later post on creating text conversation trees.
- StimulusChoice is a mechanism for filtering controversial stimuli. A StimulusChoice may have one or more ConditionalStimulus member entities. ConditionalStimulus is the actual controversial entity. It is a pairing of a stimulus and a condition. As mentioned in my earlier post on names and aliases diagrams, when a stimulus group is filtered, only one of ConditionalStimulus’ members is flagged as true. This is the first one in the list that returns true on the condition check.
- SuccessorStimulus is a wrapper for additional stimuli that have conditions attached, allowing us to build recursive tree structures of stimuli; known as stimulus clusters.