[Adonthell-devel] Environment 'simulation'

[ksterker]

Hi folks!

While doing some rather boring 0.3 to 0.4 porting work, I had a nice 
inspiration. Maybe you remember that I wanted NPCs to be able to 'communicate' 
with each other. That is, one NPC would be able to activate a certain schedule 
of another one. This would serve two purposes:

* during battle, a 'leader' with better AI could control creatures with little 
intelligence to make them more efficient. He could make them concentrate on the 
most dangerous opponent, or call reinforcements from off-screen. Whatever. (A 
spell that would allow to gain control over a creature could also make use of 
such code.)

* outside battle, NPCs could be made to react to actions of others. For example 
if the player steals something, the victim may call "Thief" to call the guard. 
Or a fight breaking out might send people running away. All that should help to 
make the game world more dynamic, a point which I think is very important.


So far, I thought this could be implemented by directly calling a certain 
method of a character's schedule. But how do NPCs know who is near and what 
calls somebody accepts. Yesterday I had the solution. What we need is an 
environment class that represents the non-visible parts of the game world. All 
it does is carrying 'noises' from one character to another.

That means, if a character wants to utter a command, he utters it to the 
environment with a certain 'loudness'. Each round, any character can receive 
information from the environment that is 'audible' to him.

This thing gets really interesting once we add client/server functionality. The 
environment is of course a server class. It will not only collect 'commands' 
from NPCs and redistribute them to the clients, it will also receive any speech 
of the players, whether they type in something on the keyboard, or talk with an 
NPC. Like NPCs, the mapview will also listen to the environment and display all 
the speech that is audible in the area it displays.

That has numerous advantages:
* one point people complained about were the little speech bubbles that also 
displayed if the player was engaged in dialogue. With the environment class, we 
can simply disconnect the mapview from the environment while a dialogue or the 
inventory window is open and we get no interfering speech bubbles.

* in a multiplayer setting, if one character talks to a NPC, other characters 
in the area can follow the conversation, as each line that is uttered is also 
passed to environment.

* stuff that happens off-screen may still attract the player, if it is just 
loud enough. For example, if somebody is attacked off-screen and would cry for 
help, the mapview could display "Help!" at the corresponding edge of the 
screen, maybe with a little arrow indicating the direction from which the 
message came.


The implementation itself is really simple. Depending upon the loudness, a 
command will be audible in a certain area. Each listener - be it NPC or mapview 
- is also able to hear what goes on in a certain area. If both areas overlap, 
the listener will receive the command. All that needs to be done is to check 
whether two rectangles overlap. If they do, the command will be heard, 
otherwise it won't. We could even make that an attribute of characters. If 
players train their hearing ability, they will be able to notice events that 
are futher off-screen. (That implicitly means that ordinary speech bubbles 
should be uttered as silent as possible. We don't want the player to hear what 
NPCs mutter to themselves 3 screens away!)

A 'message' passed to the environment could have the following attributes:

* sender
  the character that uttered the command

* range
  the area where the command is audible. Calculated from coordinates of the 
sender and the loudness.

* text
  the actual words that are spoken, so that the mapview can display a speech 
bubble. (Optional)

* command
  name of the schedule method to call if a NPC is recieving the message 
(Optional)

(of course, at least one of text or command must be set, otherwise the message 
would make little sense)

* audience
  I'm not sure about this, but it might be desirable to direct a message to a 
certain character or group of characters only, without anyone else being able 
to receive it. For that purpose, the mapview should be able to recognize the 
player's name, so it can still display messages that are meant for him. 
Characters should be able to belong to a number of groups, to receive messages 
intended for a certain group.


The environment stores each message it receives, so that each character or 
mapview has a chance to query for its messages. The environment checks that 
only those within range and amongst the audience can get the message. Messages 
without text aren't passed to the mapview, and messages without command aren't 
passed to characters. If multiple messages are available for a character or 
mapview, all of them are passed.


Optionally, we could also add a sound parameter that tells the engine to play a 
certain sound effect. That would allow us to add audio sources to the game 
world. OTOH, this should probably done separately, though in a similar fashion.


A final word on 'loudness': in order to allow for something like magic spells 
that allow people to communicate across long distances, a loudness of -1 should 
make commands audible everywhere in the game. Together with a limited audience, 
this might be a very useful feature, especially in multiplayer games.


As usual, please tell me what you think. I won't code this for a while, as I am 
still about porting the event system (I split events into listener and event 
and renamed everything to match the input event code. I also improved 
performance, where possible and made everything more error-safe. Otherwise it 
remains pretty much the same as in 0.3.) Once I am finished with events, I 
might code the basics for the things discussed above: environment and message 
classes and a receiver interface to be used by characters and mapviews.

Hope I have motivated some of you to do some coding too. Would be cool! I 
definately plan to do some more coding, at least on the weekends.

Kai