[vworld-tech] Verb/action handling
ceo
ceo at grexengine.com
Sun Jan 25 10:50:05 PST 2004
Bruce Mitchener wrote:
> Brian Hook wrote:
>
>> I'm trying to come up with a scheme that handles verbs uniformly that
>> isn't a kludge or incredibly slow or error prone.
>>
>
> This depends on details that you haven't provided at all. :)
>
> You may also find it interesting to read up on the various bits of
> research regarding management of areas of interest and all of the other
Sections on this in Agora use the term "spatial" to describe some
relevant approaches, IIRC (?).
It would also be helpful to have an idea of what rate you expect to see
events generated at. For instance, a long time ago (read: I haven't
looked at this for ages, and am now rusty :)) I implemented a roomless
MUD based on subscribe/notify semantics for each major "sense" (not
hard-coded; if you were concerned about performance, one approach was to
increase the number of "senses" you were using, which would have the
effect of reducing the number of subscribers to each).
Although I've seen references in recent years to experimental MUDs that
have gone much further, FYI tHe basic scheme I used was that every event
was delivered to everything interested in that "sense". The slighltly
more advanced version :) used quadtrees and event-radiuses to
efficiently reduce the number of potential subscribers that needed to be
checked for each event-notification to a manageable number.
(...As an aside, I went from there into MMOG systems, where the rate of
events is often so high you need to be considerably more cunning...)
For a low rate, and a design decision to do no "heavy" processing in the
event-callbacks, there's no problem with doing a basic circle-based
collision-detect on who/what needs to be informed. IME, for a "normal"
MUD, there's no need to use any of the cunning techniques of RTS's etc
(e.g. incremental notifications - retain data structures with the
answers to "who can see THIS" pre-calculated and updated automatically
whenever individual objects move).
Adam
More information about the vworld-tech
mailing list