July 2001
- [TECH] Open Source oodb/object persistence toolkit library alpha release Brian Price
- In-game email (was On socialization and convenience) Gavin Doughtie
- In-game email (was On socialization and conveni ence) Freeman, Jeff
- In-game email (was On socialization and convenience) Caliban Tiresias Darklock
- TECH DGN: Single user MOB arena Trevyn
- TECH: CRPGs vs. RPGs, Way Back When... Michael Tresca
- TECH: CRPGs vs. RPGs, Way Back When... Matt Owen
- TECH: CRPGs vs. RPGs, Way Back When... J C Lawrence
- TECH: CRPGs vs. RPGs, Way Back When... Michael Tresca
- (no subject) Alan Unsworth
- (no subject) Edward Falconer
- (no subject) J C Lawrence
- (no subject) Bruce Mitchener
- (no subject) Travis Casey
- (no subject) J C Lawrence
- (no subject) Travis Casey
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Freeman, Jeff
- Libs for 3D Client/Servers Trump
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Matt Mihaly
- Libs for 3D Client/Servers Matt Owen
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers Bryce Harrington
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Madman Across the Water
- Libs for 3D Client/Servers Richard Aihoshi aka Jonric
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J Todd Coleman
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Bruce Mitchener
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Bryce Harrington
- Libs for 3D Client/Servers Alistair Milne
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Travis Nixon
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Timothy Dang
- Libs for 3D Client/Servers Alistair Milne
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Gavin Doughtie
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Daniel.Harman@barclayscapital.com
- Libs for 3D Client/Servers Joel Chestnutt
- Libs for 3D Client/Servers Richard Aihoshi aka Jonric
- Libs for 3D Client/Servers Aaron Mulder
- Libs for 3D Client/Servers Max Gilead
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Caliban Tiresias Darklock
- Libs for 3D Client/Servers Luke Carruthers
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers Adam Martin
- New polls claw@kanga.nu
- virtual mind project Phillip Lenhardt
- [TECH] Data-transfer protocols for MUDs Adam Martin
- Chatbot Michael Tresca
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- GPL (was:Libs for 3D Client/Servers) Travis Casey
- GPL (was:Libs for 3D Client/Servers) ghovs
- GPL (was:Libs for 3D Client/Servers) Vincent Archer
- GPL (was:Libs for 3D Client/Servers) Max Gilead
- GPL (was:Libs for 3D Client/Servers) Bobby Martin
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- GPL (was:Libs for 3D Client/Servers) Patrick Dughi
- GPL (was:Libs for 3D Client/Servers) Matt Mihaly
- GPL (was:Libs for 3D Client/Servers) Koster, Raph
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- Graphical Mud-in-a-box musings Brian Hook
- Graphical Mud-in-a-box musings Justin Rogers
- Graphical Mud-in-a-box musings Rob Bartel
- Graphical Mud-in-a-box musings Adam Martin
- Chatbot, NLP and explaining away NPC limitations Erin Mulder
- Server hosting Brian Hook
- Server hosting Corey Crawford
- Server hosting Daniel.Harman@barclayscapital.com
- Server hosting Valerio Santinelli
- Server hosting Madman Across the Water
- Server hosting Frank Crowell
- Server hosting Alistair Milne
- Server hosting Brian Hook
- Server hosting Freeman, Jeff
- Server hosting Matt Mihaly
- Server hosting fred@clift.org
- Chatbot, NLP and explaining away NPC limitations Robert Zubek
- Edged weapon damage John W Pierce
- Player characters as a prey species Jon Leonard
- Player characters as a prey species Justin Rogers
- Player characters as a prey species Ling Lo
- Player characters as a prey species J C Lawrence
- Player characters as a prey species lhulbert@hotmail.com
- Player characters as a prey species Dan Shiovitz
- Player characters as a prey species Justin Rogers
- Player characters as a prey species Matt Mihaly
- Request to mailing list MUD-Dev rejected J C Lawrence
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs Derek Licciardi
- Chatting in MMPORPGs Matt Mihaly
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs Eric Lee {RAT}
- Chatting in MMPORPGs John Buehler
- Chatting in MMPORPGs lhulbert@hotmail.com
- Chatting in MMPORPGs Adam Martin
- Chatting in MMPORPGs Eli Stevens
- Chatting in MMPORPGs Dave Rickey
- Chatting in MMPORPGs Vincent Archer
- Chatting in MMPORPGs Adam Martin
- Chatting in MMPORPGs Kevin Littlejohn
- Chatting in MMPORPGs Hans-Henrik Staerfeldt
- Chatting in MMPORPGs Lee Sheldon
- Chatting in MMPORPGs Madman Across the Water
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs J C Lawrence
- TECH: Mail (was On socialization and convenience) Chris Jones
- [TECH] String Classes, Memory Management, and Fragmentation Derek Licciardi
- [TECH] String Classes, Memory Management, and Fragmentation Sean Kelly
- [TECH] String Classes, Memory Management, and Fragmentation Justin Rogers
- [TECH] String Classes, Memory Management, and Fragmentation Chris Dern
- [TECH] String Classes, Memory Management, and Fragmentation David Bennett
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Kwon Ekstrom
- [TECH] String Classes, Memory Management, and Fragmentation Bruce Mitchener
- [TECH] String Classes, Memory Management, and Fragmentation Adam Martin
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Hans-Henrik Staerfeldt
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Derek Licciardi
- [TECH] String Classes, Memory Management, and Fragm entation Bruce Mitchener
- Mudpie Matt Mihaly
- strong encryption for authentication Fred Clift
- strong encryption for authentication David Bennett
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Derek Licciardi
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication shren
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Ben Tolputt
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Ben Tolputt
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Vincent Archer
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Tamzen Cannoy
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Tamzen Cannoy
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Ola Fosheim Grøstad
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Matt Mihaly
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Freeman, Jeff
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Bruce Mitchener
- strong encryption for authentication Brian Price
- strong encryption for authentication Kevin Littlejohn
- strong encryption for authentication Brian Price
- strong encryption for authentication Kevin Littlejohn
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Robert Fleck
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Fred Clift
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Fred Clift
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Daniel.Harman@barclayscapital.com
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Oliver Jowett
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication F. Randall Farmer
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Dave Rickey
- strong encryption for authentication Jon Lambert
- strong encryption for authentication Dave Rickey
- strong encryption for authentication J C Lawrence
- Toward a Craftier Dragon Paul Schwanz
- Toward a Craftier Dragon Maximus
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon Matt Owen
- Toward a Craftier Dragon Michael Tresca
- Toward a Craftier Dragon Travis Nixon
- Toward a Craftier Dragon Paul Schwanz - Enterprise Services
- Toward a Craftier Dragon Andrew Reisse
- Toward a Craftier Dragon J C Lawrence
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon J C Lawrence
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon Richard Aihoshi aka Jonric
- Toward a Craftier Dragon Michael Tresca
- Toward a Craftier Dragon John Hopson
- Toward a Craftier Dragon yospe@kanga.nu
- Grief players with ip/dns spoofers Tand'a-ur
- Grief players with ip/dns spoofers Sean Kelly
- Grief players with ip/dns spoofers J C Lawrence
- Grief players with ip/dns spoofers Greg Underwood
- Grief players with ip/dns spoofers Robert Fleck
- Grief players with ip/dns spoofers J C Lawrence
- Grief players with ip/dns spoofers Tand'a-ur
- Grief players with ip/dns spoofers Adam Martin
- Grief players with ip/dns spoofers J C Lawrence
- character transfer in EQ Matt Mihaly
- character transfer in EQ Derek Licciardi
- character transfer in EQ Dave Rickey
- character transfer in EQ Derek Licciardi
- character transfer in EQ S. Patrick Gallaty
- character transfer in EQ Michael Tresca
- DGN: Craftier dragon and players as GMs Mathieu Castelli
- DGN: Craftier dragon and players as GMs Matt Mihaly
- DGN: Craftier dragon and players as GMs Mathieu Castelli
- DGN: Craftier dragon and players as GMs Travis Nixon
- DGN: Craftier dragon and players as GMs Marian Griffith
- Biz/Media Peter Tyson
- To good to be TRUE, in an MMPORPG? David Loeser
- To good to be TRUE, in an MMPORPG? Kwon Ekstrom
- To good to be TRUE, in an MMPORPG? Xuri
- To good to be TRUE, in an MMPORPG? Adam Martin
- To good to be TRUE, in an MMPORPG? Justin Rogers
- To good to be TRUE, in an MMPORPG? David Loeser
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Caliban Tiresias Darklock
- To good to be TRUE, in an MMPORPG? luke@rocketship.com
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Joe Andrieu
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? John Hopson
- To good to be TRUE, in an MMPORPG? Steve {Bloo} Daniels
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Travis Casey
- To good to be TRUE, in an MMPORPG? Joe Andrieu
- To good to be TRUE, in an MMPORPG? Dave Rickey
- To good to be TRUE, in an MMPORPG? Marc Bowden
- To good to be TRUE, in an MMPORPG? Sean K
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Dave Rickey
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Michael Tresca
- To good to be TRUE, in an MMPORPG? Trump
- To good to be TRUE, in an MMPORPG? Kristen L. Koster
- To good to be TRUE, in an MMPORPG? Sean Kelly
- To good to be TRUE, in an MMPORPG? Caliban Tiresias Darklock
- [NEWS] New MUD Magazine Derek Snider
- Real-world skills Was: strong encryption for authentication Travis Nixon
- Real-world skills Was: strong encryption for authentication Hans-Henrik Staerfeldt
- Something in the water Koster, Raph
- Something in the water Dave Rickey
- Something in the water Koster, Raph
- Something in the water John Hopson
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Sean Kelly
- Something in the water rayzam
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Travis Casey
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Joe Andrieu
- Something in the water Sean Kelly
- Something in the water Caliban Tiresias Darklock
- Something in the water Hulbert, Leland
- Something in the water Caliban Tiresias Darklock
- Something in the water Hulbert, Leland
- Something in the water Matt Mihaly
- Something in the water Jon Morrow
- Something in the water Trump
- Something in the water Matt Mihaly
- Something in the water Matt Chatterley
- Something in the water Sparrowhawk
- Something in the water Matt Mihaly
- Something in the water Ola Fosheim Grøstad
- Something in the water Tamzen Cannoy
- Something in the water Matt Mihaly
- Something in the water Tomas Clark
- Something in the water Matt Mihaly
- Something in the water Marc Bowden
- Something in the water Koster, Raph
- Something in the water Jessica Mulligan
- Something in the water SavantKnowsAll@cs.com
- Something in the water Miroslav Silovic
- Something in the water Travis Casey
- Something in the water rayzam
- Something in the water Travis Casey
- Something in the water Ian Hess
- Something in the water Marc Bowden
- Something in the water J C Lawrence
- Something in the water Marc Bowden
- Something in the water J C Lawrence
- Something in the water Dave Rickey
- Something in the water Marc Bowden
- Something in the water Travis Casey
- Something in the water Marian Griffith
- Something in the water J C Lawrence
- Something in the water Eli Stevens
- Something in the water J C Lawrence
- Something in the water Adam Martin
- Something in the water Dave Rickey
- Something in the water Dan MacDonald
- Something in the water Adam Martin
- Something in the water John Hopson
- Something in the water rayzam
- Something in the water Caliban Tiresias Darklock
- Gearing up against GEAR Ted Milker
- Gearing up against GEAR Dan MacDonald
- Gearing up against GEAR Sean Kelly
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR Kevin Littlejohn
- Gearing up against GEAR Sean Kelly
- Gearing up against GEAR Justin Rogers
- Gearing up against GEAR Sean K
- Gearing up against GEAR Alistair Milne
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR J C Lawrence
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Daniel.Harman@barclayscapital.com
- Gearing up against GEAR Sean K
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Sean K
- Gearing up against GEAR Dave Rickey
- Gearing up against GEAR Derek Licciardi
- Gearing up against GEAR Caliban Tiresias Darklock
- Gearing up against GEAR Marc Bowden
- Gearing up against GEAR J C Lawrence
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR F. Randall Farmer
- OT: Writer needs help from people in the gaming industry Alex Oren
- What is cheating? [Was: Strong encryption for authentication] Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) J C Lawrence
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Sean Kelly
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) Sean K
- TECH DGN: a few mud server design questions (long) SeronisROTv3@aol.com
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) J C Lawrence
On Mon, 23 Jul 2001 09:57:00 -0500 (CDT)
Robert Zubek <rob@cs.northwestern.edu> wrote:
For most of this I'm going to be writing about what I do or have
done rather than the more interesting general case.
BTW: I'd much prefer it if you lost the e e cummings bit and used
proper capitalisation.
> assuming that each event in the world gets parsed down to a
> standard representation, such as: { action: HIT, agent: PLAYER123,
> patient: NPC456, modifiers: ... } (not necessarily as a data
> structure, but in that the relevant information gets extracted on
> what the action is, who performs the action, and what/who the
> action is performed on.)
Not continuing the original perversion of the definition of "event"
that I ignorantly popularised on this list some years ago, I define
event^H^H^H^H^H^Hmessage as a structure that contains a target
address (who the message is to be delivered to), a message
body/data, and a time at which a delivery attempt is to be
attempted.
> now, how should these events get handled? presumably there's a big
> switch statement somewhere (or better yet, a data-driven dispatch
> table) directing the messages to subroutines that handle them -
> but what would be a good first-cut division of how these messages
> should be handled?
You might like to search the archives for the discussion surrounding
my dispatchor/executor/thread_pool model. Briefly:
Messages are generated by various sources, encluding player
actions and the execution/delivery of other messages.
Messages are received by the dispatchor and stored on a priority
queue ordered by time and sub-ordered by priority. When a message
expires the dispatchor pops it from the queue and sends it to the
executor.
The executor adds it to a local pool of pending messages (this is
actually slightly complex, but the details are beyond this
conversation) which it then hands off as possible to a ready
member of the a thread pool which delivers/executes the message.
The guts are actually minorly messy and somewhat intricate,
especially below the executor. If you're interested hit the
archives and look into the whole business of the Compare&Commit
model and event rescheduling, etc, or if you're really interested,
ask.
As to how to determine the target address of an event, I actually do
that in one of two ways:
For parse events (eg player messages which need to be parsed) I
generally log a parse event to the dispatchor with the command as
body. That event executes and parses the command into an
objectified form and then logs that back into the dispatchor as a
new message.
Messages which are generated by other message deliveries generally
don't need the pre-parse step, and so are pre-objectified and thus
ready for ultimate delivery.
As for how the look up is done, how message-to-XXXX is translated
into either f(XXX) or XXX(), well, that's pretty simple: function
pointers are your friend and tables of function pointers are even
better.
All message targets devolve to object methods references, which
gives my a simple tuple of ObjectID, MethodName, and
MethodArguments. Each object carries a hash table of mappings from
MethodNames to entry points so a simple hash dereference gives me
the entrance point to the method code to start the soft code
interpreter on.
> ie., should the agent who performs the action have the code that
> actually performs the action? should the recipient (ie. patient)
> handle the action it receives? or maybe all actions should be
> handled by global handlers? perhaps a mixture of all three?
I've been (was mostly) a fan of contextual binding and so restricted
all object methods to only being able to mutate their parent object
(I transparently exposed exported object attributes via hidden
accessors). As such everything else devolved to message passing
among objects. I did this explicitly so as to provide a clean
abstraction layer for database distribution, modeling off CoolMUD's
YO protocol.
> for the first example, we may wish to hang event handlers off of
> the patient of the action - so that when i hit another player,
> their handler will subtract the appropriate amount of hit
> points. this makes it very easy to add new objects that support
> novel kinds of actions (eg. adding a beverage to drink), but
> breaks in case of actions that have no patients (such as emotes:
> wave, say, etc.)
<nod>
Notice that I explicitly do not define event handlers. Events are
messages. Messages are purely an encapsulated form of an object
method invocation and the arguments to be provided to that method.
There are no event handlers. There are messages and first class (ie
exposed/public) methods on objects. That's all.
> having event handlers hooked to the agent will solve the problem
> of patient-less actions, but complicates the object model - now
> when i add a new target object with a novel action (such as a
> beverage), i also have to go and change all the classes that can
> use it.
Object inheritance denoted method inheritance. I used multiple
inheritance with a depth-first dynamically built method tree.
Certainly not the way I would do it now, but it works (now I'd go
for something akin to Java's interface concept or at least a much
more lightly defined object model).
> in addition to imposing unnecessary code dependencies, this also
> encourages me to cut up the object hierarchy according to the
> differences of which objects can perform what actions - and i'm
> not convinced that's a good way of organizing an ontology.
Bingo. There are quite good arguments for all object actually being
of the same compound type and only differing by internal attribute
state.
> finally, selecting the event handler based on just the action is
> probably the simplest, but i would imagine has the worst effect on
> extensibility - since now we have to change all actions when we
> add new types of possible agents or patients. perhaps some sort of
> mix is in order - global actions for certain general types of
> events (such as combat), and then action handlers local to the
> agent (or the patient) for the more specialized actions.
Given an inheritance model, or at least a uniform object aggregation
and namespace derivation model I don't see much reason to worry
about this. You end up implementing an indirection table to refer
to non-locally defined methods, and then running all lookups against
the set of that and the locally defined table. Its really just a
question of namespace definition and namespace determination. No?
> which of these gets used most often in actual muds? my suspicion
> is that it would be the last one (mix of global and local actions)
> - but wouldn't it also complicate extending the world?
Have a look into the various runtime morphic servers, in particular
Cold and LambdaMOO. It might be particularly useful to read up on
the various times that base objects in both servers were edited,
critically crippling the object hierarchy, as well as their methods
of recovery.
> 2. how to handle long-lasting events
Do an archive search for "digging the panama canal". Historically
that was our base scenario for discussing long-lived player-based
in-processes. Most of your concerns and questions have been
addressed there.
> in this architecture, how does one elegantly handle temporally
> extended events - for example, a spell that takes several minutes
> to cast? the handler obviously can't block while waiting for the
> event to finish.
I took the multi-threaded way out as I considered that easier and
more elegant than either going for cooperative yield models, or an
in-system pre-emptive scheduler with all the related concerns
surrounding context push/pops, re-entrancy, etc.
> one could imagine a number of solutions inspired by operating
> systems research - perhaps implementing a fake
> continuation-passing style (as a kind of non-preemptive
> multitasking: a temporally-extended action would be expected to
> initialize itself, do a fraction of the necessary processing, then
> put a new fake event on the queue saying "continue the spell
> event", and exit).
Which is what I did. There are second order questions which arise
there in regard to what operations may continue in parallel with
such a long lived operation, and when and how conflicts are both
detected and addressed.
> or, if threads were cheap on that system, one might consider
> actually spawning a new thread for each call to the handler, and
> let those that take a while just run quietly in the background
> until they finish.
Thread fork times are rarely cheap. Its easier to build and
maintain a thread pool that you fork once.
More interesting, and likely far more complex once you go the thread
route is the transactional model. How do you guarantee logical and
data consistency across multiple threads competing for r/w access to
shared objects?
It was in solving that latter problem that I adopted the C&C model.
> i'm also curious what are some standard ways of propagating
> messages in a mud engine. for example, when the player performs an
> action, the engine processes the event, returning some result
> value. at that point the involved parties (agent, patient) will
> need to be informed of the result of the action and then, if
> applicable, others in the area may be informed of what happened as
> well.
<nod>
> but once the handler figures out the return value for the event,
> what are some standard ways of propagating this value? does the
> handler send the result to the closest binding container (such as
> current room) that propagates it among its elements? does it
> return it to the agent and the patient, who propagate it
> themselves? or would the handler actually manually figure out the
> list of proper recipients for this message, and hand it to them
> individually?
For me every method call has the potential for generating two or
more messages:
1) to the parent object.
2) To the object that sent the message
3) To any objects in the parent object's containment lists (there
are multiple forms of containment and so there may be many
messages here)
And as a second order effect, upon process compleation, via the
watchers (state-change monitors) to any objects that are interested
in state changes in the local object.
> each has a drawback: for the first (container passing the
> message to its elements), there are cases when these messages
> should be propagated further down to elements-of-elements
> (eg. people in a cage in a room should be able to see what the
> people in the room around them are doing), but it could grind the
> server to a halt if all of the contents of everyone's pockets
> would be getting all the messages about what's going on in the
> room.
Not really. A message gets sent to the room. The room sends a
message to the cage. The cage sends a message to the prisoner. The
prisoner sends a message to his pocket. The pocket sends a message
to the coin, the whistle, and the small stone. Each one of the
layers can me executed as a separate message independently scheduled
through the dispatchor and executor (which is what I do, along with
the appropriate short circuit logic).
The interesting case is not the multi-level case, but the case of
10,000 players all in a single room, all moving about and talking
loudly.
> for the second one (agent doing the propagation) and the third one
> (handler manually propagating the result to relevant parties),
> it's a matter of maintaining abstraction boundaries - the agent
> and the event handler really shouldn't be worrying about making
> sure everybody saw what happened, it should be handled by some
> separate component.
I send the messages. Each recipient is responsible for determining
whether or not they are interested. Filter objects (which are
really just mostly-transparent containers and a fairly simple
variation on spoofs) intercept those messages which the target
object should never receive for whatever reason.
--
J C Lawrence )\._.,--....,'``.
---------(*) /, _.. \ _\ ;`._ ,.
claw@kanga.nu `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly - TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Sean Kelly
- TECH DGN: a few mud server design questions (long) Adam Martin
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Jon Lambert
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Kevin Littlejohn
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- Real-world skills luke@rocketship.com
- Real-world skills Mathieu Castelli
- Real-world skills J C Lawrence
- Real-world skills Kwon Ekstrom
- Real-world skills rayzam
- Design patterns for game database implementations Caliban Tiresias Darklock
- Design patterns for game database implementations Sean Kelly
- Design patterns for game database implementations J C Lawrence
- Design patterns for game database implementations J C Lawrence
- Real-world skills Caliban Tiresias Darklock
- Real-world skills Chris Lloyd
- Real-world skills Justin Rogers
- Real-world skills Koster, Raph
- Real-world skills Travis Casey
- Real-world skills J C Lawrence
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills R.Fry
- Real-world skills Dave Talk21
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills Bruce Mitchener
- Real-world skills Ola Fosheim Grøstad
- Mud Clients (was Real-world skills) Kwon Ekstrom
- Mud Clients (was Real-world skills) David Bennett
- Real-world skills Dave Talk21
- Real-world skills Justin Rogers
- Real-world skills Caliban Tiresias Darklock
- Real-world skills J C Lawrence
- Real-world skills Caliban Tiresias Darklock
- Real-world skills J C Lawrence
- Real-world skills Dave Talk21
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills Adam Martin
- Players playing NPCs Vladimir Prelovac
- Players playing NPCs Christopher Allen
- Real-world skills Koster, Raph
- Real-world skills Bruce Mitchener
- Real-world skills Andrew Wilson
- Game Survey Michael Tresca
- Game Survey Richard Aihoshi aka Jonric
- Game Survey Hans-Henrik Staerfeldt
- Game Survey J C Lawrence
- MMORPG Construction Kit Koster, Raph
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Ola Fosheim Grøstad
- MMORPG Construction Kit J C Lawrence
- MMORPG Construction Kit Brian 'Psychochild' Green
- MMORPG Construction Kit Ola Fosheim Grøstad
- DNA Game Patent [was Randy's Resume] Christopher Allen
- DNA Game Patent [was Randy's Resume] Caliban Tiresias Darklock
- DNA Game Patent [was Randy's Resume] Adam Martin
- DNA Game Patent [was Randy's Resume] Hulbert, Leland
- DNA Game Patent [was Randy's Resume] Chris Gray
- DNA Game Patent [was Randy's Resume] David Loeser
- DNA Game Patent [was Randy's Resume] Dave Rickey
- DNA Game Patent [was Randy's Resume] Jon Lambert
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Travis Nixon
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Kevin Littlejohn
- DNA Game Patent [was Randy's Resume] Jessica Mulligan
- DNA Game Patent [was Randy's Resume] Caliban Tiresias Darklock
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Frank Crowell
- DNA Game Patent [was Randy's Resume] Adam Martin
- DNA Game Patent [was Randy's Resume] F Farmer
- Re[4]: Something in the water Travis Casey
- Population divisions (wasTo good to be TRUE, in an MMPORPG?) Matt Mihaly
- Community feeling (was: To good to be TRUE, in an MMPORPG?) Alex Kay
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Koster, Raph
- Community feeling (was: To good to be TRUE, in an M MPORPG?) J C Lawrence
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Vincent Archer
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Koster, Raph
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Daniel.Harman@barclayscapital.com
- Community feeling (was: To good to be TRUE, in an MMPORPG?) Ola Fosheim Grøstad
- Re:DNA Game Patent [was Randy's Resume] Jessica Mulligan
- Multi-threading ( was: TECH DGN: a few mud server design questions (long)) Jon Lambert
- Wilderness Freeman, Jeff
- Wilderness Trump
- Wilderness Caliban Tiresias Darklock
- Wilderness Edward Glowacki
- Wilderness Dave Rickey
- Wilderness Sean Kelly
- Wilderness John Buehler
- Wilderness Brian Hook
- Wilderness John Buehler
- Wilderness Koster, Raph
- Wilderness Ling Lo
- Wilderness Freeman, Jeff
- Wilderness Nathan F. Yospe
- Wilderness Ling Lo
- Wilderness Nathan F. Yospe
- Wilderness John Buehler
- Wilderness Ola Fosheim Grøstad
- Wilderness Hulbert, Leland
- Wilderness John Buehler
- Wilderness Kwon Ekstrom
- Wilderness Ola Fosheim Grøstad
- Wilderness Matt Mihaly
- Wilderness Freeman, Jeff
- Wilderness John Buehler
- Wilderness Nathan F. Yospe
- Wilderness Travis Casey
- Wilderness Hans-Henrik Staerfeldt
- Wilderness Ola Fosheim Grøstad
- Wilderness Koster, Raph
- Wilderness Dave Rickey
- Wilderness Ola Fosheim Grøstad
- Wilderness Brian Hook
- Wilderness Ola Fosheim Grøstad
- Wilderness Brian Hook
- Wilderness Freeman, Jeff
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Freeman, Jeff
- Wilderness John Buehler
- Wilderness lhulbert@hotmail.com
- Wilderness Matt Mihaly
- Wilderness John Buehler
- Wilderness Matt Mihaly
- Wilderness John Buehler
- Wilderness Matt Mihaly
- Wilderness Freeman, Jeff
- Wilderness Madrona Tree
- Wilderness Nathan F. Yospe
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness John Buehler
- Wilderness Adam Martin
- Wilderness Koster, Raph
- Wilderness John Buehler
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Adam Martin
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness David Loeser
- Wilderness Matt Owen
- Wilderness Peter Tyson
- Wilderness Adam Martin
- Death among Friends Jon Morrow
- Death among Friends Tommy Wang
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends shren
- Death among Friends Michael Tresca
- Death among Friends John Buehler
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends Michael Tresca
- BSD licenses Ross Dmochowski
- Hoping for more... (interfaces) Tommy Wang
- Hoping for more... (interfaces) Matt Mihaly
- Hoping for more... (interfaces) Ling Lo
- Hoping for more... (interfaces) Matt Mihaly
- Hoping for more... (interfaces) Jon Morrow
- Hoping for more... (interfaces) Kwon Ekstrom
- d20 shannon hall
- Group sizes and MUDs as sport? Ola Fosheim Grøstad
- free release of graphical MUD Chris Gray