[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Adonthell-devel] Environment 'simulation'
[Adonthell-devel] Environment 'simulation'
Mon, 05 Apr 2004 13:15:53 +0200
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
* 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
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:
the character that uttered the command
the area where the command is audible. Calculated from coordinates of the
sender and the loudness.
the actual words that are spoken, so that the mapview can display a speech
name of the schedule method to call if a NPC is recieving the message
(of course, at least one of text or command must be set, otherwise the message
would make little sense)
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.
- [Adonthell-devel] Environment 'simulation',