An Entity is a construct with which other Entities and game constructs can interact. A successful interaction can only be the result of an "informed decision". It is therefore necessary to establish a way to obtain easily processable information about an Entity.
At a higher level, even if all interaction is done through game constructs, players will need to learn more about the world their Character will evolve into. It is therefore necessary to provide a way to describe Entities in an intelligible way.
Another issue is the need for more realism compared to older MUDs. Typically, descriptions were stored in text files, one (or sometimes several) description(s) per Creature type. This had several drawbacks. First, each Creature of a given type had exactly the same description as any other of the same type. Second, the description was static, i.e. it did not evolve at the same time as the Creature it was representing (no monitoring of health condition, growth, change ot clothes...).
An Entity receives the whole information about its environment thanks to Stimuli. For instance, on receiving a visual Stimulus from a Creature, the Entity could get its identity, its size, its race, its rough age, its rough weight... A sound Stimulus could also give the Entity some other information. This raw data is sufficient for a bot but for a human player, it must be laid out in a textual, graphical, sound or some other way... This is the objective of the dynamic description mechanism. We'll now show how it works for textual descriptions, but it can be adapt in most cases to other descriptions types.
Example 4. An Entity with some attributes and the descriptions which could be generated
identity: EntityID race: wolf size: 2m colour: grey position: x y z (3D coordinates)
The description generated on the fly is: "A huge grey wolf is standing a few meters in front of you.". If the wolf was already known as "Medor" by the Character (that is if the EntityID Entity was in the character memory), the description could become: "Medor is standing a few meters in front of you.".
A Stimulus carries therefore a certain amount of information which can be used afterwards by the Entities which receive it. However, we have seen in previous sections that a Stimulus could be more or less well received. So this information will not always be accessible and could also be distorted. Some information can require first-rate perception too whereas another will be easily obtained.
Example 5. Example with an action
Subject Entity: EntityID (Raoul) Action: ActionID (eat) Object Entity: EntityID (bread) ...
The description will be: "Raoul is eating some bread."
If a Stimulus is badly received, this description can be replaced by one of the following:
"Somebody is eating some bread." "Raoul is doing something with bread." "Raoul is eating something." "Somebody is doing something with something." ...
Or the description could even be completely wrong:
"Raoul is threatening you with bread." "Raoul is eating some wood."
The problem which appears is how to know which part(s) of descriptions are altered. The problem exists not only for players but for bots too, because it concerns attributes at the source. We associate a minimal reception index to each attribute. The Stimulus reception level should be greater than this index value to have an optimal reading of the attribute.
To better understand, let's continue with the previous example:
Example 6. Example with an action (2)
Subject Entity: EntityID (Raoul): 0.01 Action: ActionID (eat): 7 Object Entity: EntityID (bread): 1 Reception 10: "Raoul is eating some bread." 1: "Raoul is eating something." 0.1: "Raoul is threatening you with a bread". 0.01: "Raoul is eating some wood."
but, contrary to this example, it won't be as simple to practically give a wrong value to attributes, except to numerical values (size, length, weight...). We could in theses cases determine the wrong value in an interval centred on the real value and with a diameter increasing when reception level decreases.
Now see an other subject. In these examples information is reduced and descriptions are therefore short. Nevertheless, with state Stimuli, descriptions (at least textual ones) may well be too long. As a consequence, a detailed (long) description and a shorter one have to be generated. The short description is the default one but the user can consult the long one at leisure. This can apply as well to texts or other description types. For example, we can imagine a graphical interface where an Entity appear as a picture (short description) and clicking on it displays a window showing additional information on the Entity.
Example 7. Example with an action (3)
short description: "Raoul is standing behind his counter."
long description: "Raoul is standing behind his counter. He is a stout man of medium height. He is wearing a 'marcel' and white trousers held up by a pair of braces."