Implementation

StimuliDispatcher

A StimuliDispatcher is an intermediary between Entities emitting Stimuli and Entities receiving them. There is a StimuliDispatcher associated to each Place.

The operation is the following: when an Entity come into a new Place, it is registered to the local StimuliDispatcher as a new Entity able to send Stimuli (we consider that any Entity can potentially emit Stimuli even if it could be not always the case), and able to receive them with each of its Senses. The StimuliDispatcher asks then to all registered Entities for emitting Stimuli again in order for the new Entity to have a glimpse of its environment. Afterwards, when a Stimulus is emitted by any Entity, the StimuliDispatcher dispatches it to all registered Senses which can receive it. So the StimuliDispatcher role is limited to Stimuli delivery only; on no account does it have to modify Stimuli.

PerceptionState

PerceptionState

The PerceptionState is a cache containing state Stimuli emitted by an Entity (one Stimulus per Medium). Each Entity should have a PerceptionState.

The PerceptionState prevents ever recreating the same Stimuli for and Entity before they are sent to any StimuliDispatcher. Assuming the content of the Stimuli will not change quite often, the benefits should be important.

Descriptions

Before going any further in this section, the Entity-RFC should be well known by you. If you do not know what an Entity, a Property, a Type or an Influence, are please read the Entity-RFC.

In earlier sections, we have introduced Stimuli. Here we deal with how to fill them. To do that, we define a set of description Properties besides the usual Properties which we may qualify state (or internal) Properties. The description Properties are calculated from the state Properties.

Example 8. Raoul the baker

      State Properties:
      -----------------
      identity: EntityID
      race: human
      name: Raoul
      job: baker

      Description Properties:
      ----------------------
      identity: EntityID
      race: human
      perfume: odor of bread.
      

In this example, there are 3 descriptions Properties. 'identity' is necessary because it allows Bots to identify other Entities. Then there is 'race' that is equal to the state Property of the same name, and 'perfume' which was created from the state Property 'job'.

Now we must sort the description Properties by Medium because every description property cannot be perceived through all Media. In the same time, we associate an intensity to each of them. The result is a table. We may call it the Low Level Description because it contains any necessary information to build a description (text, sound, ...) of the Entity.

Example 9. Raoul the baker (2)

            View                    |           Smell
      -------------------------------------------------------------------
      identity: EntityId     1      |  identity: EntityID             1
      race:     human        2      |  race:     human                1
                                    |  perfume:  odor of bread        5
      

Every Entity will have such a table. Entity editors (or zone makers) must of course provide how to build it in the Entity Type and Influences.

The last step is now to create the Stimuli that will carry data through Media. It is quite simple: we just have to put the content of each column in a Stimulus related to the same Medium than the column. The Stimulus will take place in the PerceptionState. The only issue is if we should copy the column by value or by reference? The only flaw that can happen with references is when the description of an Entity is modified after the Stimulus is send. When the Stimulus will be received, it will contain the new value and not the old one. But this is not really a problem. On the other hand references avoid the creation of lots of Java objects and this is a rather great advantage. That is why we decided that Stimuli will contain references on a column.