Improve partial perception of SensoryMessage targets

[DavidRieman]

One thing that was a bit impacted recently by the large refactoring to target .NET Core and remove a bunch of dependencies (e.g. NVelocity) was the ContextualMessages often pass target objects that were entirely unused. A few areas that were a bit more context sensitive were simplified a bit. We didn't lose a lot of these cases but it did bring attention to how inconsistent we were, and that we don't seem to have a common target bar here to aim for.

To summarize what we're up against, often the SensoryMessage involves multiple targets, which may have different perception traits. For example, from the "knock" command today supplies a ContextualString like:

var thisRoomMessage = new ContextualString(sender.Thing, this.target)
{
  ToOriginator = $"You knock on {this.target.Name}.",
  ToOthers = $"{sender.Thing.Name} knocks on {this.target.Name}.",
  ToReceiver = $"{sender.Thing.Name} knocks on you.",
};

and then send the Request and subsequent Event with a SensoryMessage like:
var thisRoomSM = new SensoryMessage(SensoryType.Sight | SensoryType.Hearing, 100, thisRoomMessage);

While this is leaps and bounds above traditional MUD code which would typically hard-code handling of the messaging and any one-off interactions from the command (like spell effects like immobilization that prevent you from knocking) directly in the command code itself, making for a large mess... It still leaves some things to be desired. Namely, handling of partial perception scenarios. The code we have currently will raise an event that will produce just one of those 3 exact strings, regardless of your perceptive capabilities, like "a goblin knocks on the iron door" even if one of them is invisible, or you can hear the event but not see it (how do you know it's a goblin?), etc. Because the code considers it sufficient to either have Hearing or Sight in the same room to receive the full message.

In actuality, there are lots of permutations with infinite potential complexity, which could have better output. Some examples:

• Sender is invisible. ("someone knocks on the iron door"?)
• Other target is invisible. ("a goblin knocks on something"?)
• Watcher cannot hear. ("looks like a goblin is knocking on the iron door"?)
• Watcher cannot hear, and target is invisible ("looks like a goblin is knocking on something"?)
• No aspects perceived at all (no message whatsoever?)
• Basic heat vision only detects shape of sender. ("a humanoid is knocking on the iron door"?)
• Etc.

This is one thing that I think NVelocity was trying to handle (but did so only a little, and did so poorly) - being able to figure out if "a goblin" should actually be "someone" for the event receiver, etc.
How many of these scenarios can we support, with a given system, without getting too complex for the consumers of the contextual message code (like the Knock command in our example)?

Perhaps we could strike a good balance where we pass a few references to the common actors (the one doing the action, the one targeted by the action) and have a token replacement system that knows to print either the short name of the target or "someone/something" if ill-perceived by the receiver, and so on. Then allow the contextual string to have multiple states (honored in priority order that they are provided in) like "if heard, use these base messages... else if seen, use these base messages", and so on? I think it would help to try to pseudo-code some scenarios, but I'll have to come back to this later. Maybe this'll look scary and too complicated in the end. Being able to opt-in to complex sensory scenario handling may help, but if so, at least the Core should probably strive for consistency across the board (probably handling the best supported options wherever possible).

We should think critically and discuss how far we want to take this though. Maybe the existing system is "good enough" through v1.0 and we should constrain any improvements against complexity vs benefit analysis. Or maybe we can find a better bar, and file Issues to reconcile existing actions to meet that bar, and document some Best Practices here.

[DavidRieman]

This seems like a good place to drop the related historic archives on this topic as well for extra context.
This thread contains restored content from prior forums; see #134 for details.

[May 2009]

I designed the sensory system, so that we can add non-standard senses to entities. So say you are in a dark cavern, and you are the only one that has "low light" or "infrared" vision, you'll be able to see in the dark just fine. So there are sensory messages sent on various sensory channels in the room; normal sight, infrared, and even smell. Just think of the possibilities. The main push for this design is to help in creating less code for expanded play. This is pushed onto the entity class, so that a lot of stuff can be dealt with automatically. This can greatly enhance quests as well. Say you need somebody with good sense of smell in order to finish the quest. The party won't find any clues unless they have somebody with either enchanted sense of smell, or somebody with natural abilities.

Anyways, I hope you get the gist of what I'm trying to say.

If you're on it, I'd recommend an enum, but also a string parameter that is null most of the time. That should future-proof the reliance on an enum.

• BasicSensoryEvent(EventType.Yell, null);
• BasicSensoryEvent(EventType.Unknown, "heatvision");
• BasicSensoryEvent(EventType.Unknown, "pheromone");
• either/or there might be only two mobs that can do the pheromone thang, so adding to the Enum would just confuse up sensory development.

This also allows the rapid addition of sensory 'channels' - a mob type could have a 'hivemind1' sense that responds to: BasicSensoryEvent("hivemind1") events with no chance of cross-communication with other hiverminds (BasicSensoryEvent("hivemind2"). Whereas, BasicSensoryEvent(EventType.Hivemind) - would resort to string parsing instead of a simple string compare, if we had multiple hiveminds.

If someone is making a pheromone or heatvision based sense, it should be properly done systemically, not limited to one mob in one area having access to it. What happens when another developer comes and adds an infravision? Now mobs that have heatvision don't see infravision events, even though they are arguably the same thing? There was no discovery mechanism for a suitable existing mechanism, since it wasn't added to an enumeration. A developer can search references and see how it's used after discovery. But that part really comes down to the SensesManager, not the Event...

IMO we can change the SensesManager to be based on an enumeration rather than strings. The list of what senses someone can have really should be a well-designed set, and changes should takes some consideration of the existing system before bloating it with yet more types; when adding a new sense, one should think about updating all existing sensory messages that would actually apply to that sense. Anyway, if we move to a more bitfield-style approach, we can suddenly gain SensoryMessages that specify multiple senses without having to create new List objects all the time. A magical explosion might be perceptible by sound, sight, infravision, tremorsense, etc, so an entity with any of those senses intact could get the event.

(And an enumeration should be made extensible so new values could be added/used without having to modify Core to do so.)

As for complicated things like hivemind events: This is in no way a "basic" event. One probably should not use BasicSensoryEvent for purposes like orchestrating hivemind mobile AI. You're talking about a complex, custom system; Perhaps derive your own event types for that, a game-library level "global" event housing, and if it makes sense to have a string parameter there, knock yourself out. I see no reason for us to complicate BasicSensoryEvent with more than the enumeration for type though. We're not inventing new events (nor senses) at runtime, so using strings doesn't really make sense to me. It allows typo bugs and encourages non-discoverability IMO.

Ok. Revision 224 has the aforementioned Enum changes - touched a lot of files, so it's a separate Submit from the BasicSensoryEvent - which is not done, but I have a skeletal file representing it...

One thing to note, if it's not known - the static methods of System.Enum allows one to go back and forth from the value to the name.

Hearing = 2

You can get a string representing "Hearing" by passing in a '2', which is not possible in most other languages. This makes enums useful on a run-time level, not just while staring at code itself.

Should be bitwise capable:

SenseType Human = SenseType.Hearing | SenseType.Sight | SenseType.Touch | SenseType.Smell | SenseType.Taste;
newPlayer.Senses = Human;

---

On SensoryEvents over multiple senses

Hi all!
I'm currently looking into handling SensoryEvents that span over multiple senses.

Imagine a knock, for example. It should send a visual and auditory SensoryEvent in the room where the player knocking is. If another player is inside this room, and is also blinded, he shouldn't be able to see who's knocking, but still hear someone knock.

After scurrying around the code, the most obvious way (to me) would seem to be to pass a collection of SensoryMessages to an event, send it down the event chain, and eventually resolve it in the EventProcessor (where single sense events resolve today).
This also leads to the question of sense priority, i.e. which (available) sense is the most information dense? One might assume that sight is always superior to smell etc., but you could also consider races (other than human) that might have other preferences.
I would like to hear your thoughts on this, before I go to work.
Hope this made any sense. (Pun intended.)

It's been a while since I looked at that piece of code... What do you mean by "resolve" above? I thought that the messages get resolved in the entities themselves. Meaning that the entity's makeup decides what it can process and what to throw away.

On sense priority: One way to handle this, is to work with the MessageStrength property. Ultimately, this should be handled at the entity's processor, since different racial templates would call for different things.

Yeah I can see MessageStrength playing a key role here, and having racial modifiers and whatnot adjust things. I think blindness/deafness type effects should basically reuse an AlterSenseEffect with a max dampening value, while there could also be spells which give you a moderate temporary boost.
Anyway, lately I've been architecting sensory messages in a pattern like:

var arriveMessage = new SensoryMessage(SensoryType.Sight, 100, new ContextualString(sender.Entity, targetPlace)
{
  ToOriginator = @"You teleport to $TargetThing.Name.",
  ToReceiver = @"$ActiveThing.Name teleports in.",
  ToOthers = @"$ActiveThing.Name teleports in.",
});

The code that takes SensoryMessages from events is EventProcessor.cs. Perhaps SensoryMessage should support multiple senses itself rather than trying to make an alternate AggregateSensoryMessage or whatnot, but it should still be possible to construct single-sense messages based on the constructor you chose. One idea, to expand on the example above, would be to add syntax like:

arriveMessage.AddSense(SensoryType.Hearing, 50, new ContextualString(sender.Entity, targetPlace)
{
  ToOriginator = @"You teleport to $TargetThing.Name.",
  ToReceiver = @"$ActiveThing.Name teleports in.",
  ToOthers = @"$ActiveThing.Name teleports in.",
});

Somehow the EventProcessor would figure out the best matched sense among the player's current senses and display that message. Of course the messages needn't be the same per sense and often wouldn't make sense.

ToOthers = @"You see $ActiveThing.Name pull the lever." vs

ToOthers = @"You hear the creaking of a lever being pulled." (but can't tell who did it just from the sound alone in this case)

Another thing to consider eventually is the resolving of variables through the contextual string builder based on the final perception strength - IE if it's really dark and you can barely see someone's silhouette maybe it should say "You see someone enter the room" rather than "You see Bob enter the room"... just more food for thought.

Actually an AggregateSensoryMessage which houses SensoryMessages would work too if we have both that and SensoryMessage itself inherit from an interface which defines a method to do the "can I be perceived by the specified sense collection, and if so, here is the message" processing instead of that being done externally. Maybe something like:
string GetProcessedMessage(SenseManager perceivingSenses)
and EventProcessor would call that and ignore nulls (IE if no senses were sufficient to perceive the message).

It's been a while since I looked at that piece of code... What do you mean by "resolve" above? I thought that the messages get resolved in the entities themselves. Meaning that the entity's makeup decides what it can process and what to throw away.

True. In the case of a player object, it has a member EventProcessor, and calls this.eventProcessor.ProcessEvent(IEvent theEvent).

Actually an AggregateSensoryMessage which houses SensoryMessages would work too...

I currently like this idea the most. What do others think?

That looks good. Go for it! Sorry that I haven't been more involved. Been way too busy, and trying to catch up on my sleep.

The idea with senses is to allow the ability to have more realism with regards to the messages we display. For instance, if a character in the room turns on a new flashlight but another character is blind, we don't have to add crazy blindness logic to the flashlight functionality to make sure the blind person doesn't get any output... we just issue a SensoryMessage whose only applicable sense is vision. But then maybe the flashlight switch has some sound to it but not enough to hear it if we just had a loud BANG semi-deafen us, or if our race isn't particularly good at hearing... we add a Sound component to the SensoryMessage with a low value. Thus only good-hearing characters who don't have any sound-dampening Effects placed on them will get that message, and only if they're blind. "You hear the click of a small switch nearby" whereas if they can see they'll get the more detailed "You see Bob turn on a flashlight" message; the click is generally irrelevant in such cases. There are probably cases where it would make sense to have a "you see X and hear Y" pattern that only prints if you satisfy multiple conditions but the question is whether or not it's worth the complexity. We could always add variants later if/as needed.

Of course your description is 100% correct, however there was always a nagging issue at the back of my mind with our implementation that I had always managed to ignore and that is. How do we envisage the downgrading of messages depending on the receiving entities sense "threshold".

Someone is blind in a room and someone switches on a torch (flashlight for you non UK guys) they do not see the Visual Message, someone is partially blind and they see "the room increases in brightness slightly" and someone who can see sees "Bob turns on a torch".

I know that the message sent to the entity can have a collection of sense messages, but do you think it is up to the builder to write each of these 3 sensory messages each with a different threshold to trigger them?
I love the fact that we can do this, I have just always been slightly concerned that it is very labour intensive and will probably be a feature that gets overlooked by builders.

Yes that's why builders should always be able to use a simple version and only opt to go crazy with such cases if they choose to. The system should allow as much or as little detail/granularity as desired. Implementing multiple levels of sight-based message for different qualities of ending sight would be a matter of using the AddSense (or whatever syntax we settle on) to add another entry of the same sense but with a different threshold. Most builders would probably only bother with "you see X turn on a flashlight" vs no output which is still supported well.

But Core code should endeavor to keep it easy to specify multiple sensory situations, and generally model Core SensoryMessages in a detailed way as the best possible "default" user experience for any applicable games.