January 1998
- Mail from mud Zoran's final Imp Stephen Zepp
- Mail from mud Zoran's final Imp coder@ibm.net
- Mail from mud Zoran's final Imp Shawn Halpenny
- Mail from mud Zoran's final Imp JC Lawrence
- Mail from mud Zoran's final Imp Shawn Halpenny
- Happy new year Marian Griffith
- Totally OT... Marian Griffith
- Totally OT... (Or is it?) s001gmu@nova.wright.edu
- Mud-Dev FAQ Ling
- Mud-Dev FAQ Jon A. Lambert
- Mud-Dev FAQ JC Lawrence
- Mud-Dev FAQ Adam Wiggins
- Who's bugging who? : was- Wild West Jon A. Lambert
- my bio (was Mud-Dev FAQ) Mike Sellers
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- request for comments (was: Mud-Dev FAQ) Jon A. Lambert
- request for comments (was: Mud-Dev FAQ) coder@ibm.net
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) s001gmu@nova.wright.edu
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- OT: Suomi Finland Ola Fosheim Grøstad
- OT: Suomi Finland ##Make Nylander
- Totally OT... (Or is it?) (yes it is ;) Marian Griffith
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Adam Wiggins
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Mike Sellers
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Journal of MUD Research, Vol. 3, No. 1 [TEXT] coder@ibm.net
- World Seeding (was Task Parsing) Ling
- World Seeding (was Task Parsing) JC Lawrence
- World Seeding (was Task Parsing) Stephen Zepp
- threaded servers (was request for comments Mike Sellers
- MUD Economy Shawn Halpenny
- MUD Economy Adam Wiggins
- MUD Economy Shawn Halpenny
- MUD Economy Ling
- MUD Economy Brandon J. Rickman
- MUD Economy Marian Griffith
- MUD Economy Shawn Halpenny
- MUD Economy Shawn Halpenny
- MUD Economy JC Lawrence
- MUD Economy Koster, Raph
- MUD Economy Matt Chatterley
- MUD Economy JC Lawrence
- MUD Economy Jon A. Lambert
- OT: Jobs available Koster, Raph
- OT: DCOM and RMI Jon A. Lambert
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Miroslav Silovic
- OT: DCOM and RMI Alex Oren
- OT: DCOM and RMI Chris Gray
- request for comments Miroslav Silovic
- request for comments JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
On Fri, 9 Jan 1998 13:51:24 PST8PDT
s001gmu <s001gmu@nova.wright.edu> wrote:
> On Fri, 9 Jan 1998, Vadim Tkachenko wrote:
>> s001gmu@nova.wright.edu wrote: > > On Thu, 8 Jan 1998, Vadim
>> Tkachenko wrote: >
> *nod* our end goal is to not make it obvious to the player that the
> game is turn based, but the underlying mechanics will be. The more
> that I think about it, the less I like the 'tick' idea... Why
> artificially impose a less granular clock on top of the system
> clock? Why not just let the system clock determine the timing?
> Situations where the character's speed should be far faster than the
> players typing speed (IE: combat, etc), can (and should?) be handled
> by the computer (IE: the computer is generating the events, not
> player commands). All other commands don't need to be turn-based,
> as speed has already been deemd uniportant by the designer (me), by
> that system not being coded as an auto-generated event.
This sounds very much like the the argument I went thru with myself.
>>> but when I tell my character to "cast fireball at bubba", it
>>> becomes trivial to implement the delay inherent to the action by
>>> scheduling the event to go off 3 ticks down the road.
>>
>> By the way, this is exactly the point where extra threads appear in
>> my model. Every time-based action is asynchronously handled by the
>> separate thread, which allows to handle effects like spell
>> backfires, concentration, partial force release, accumulation
>> rules, side effects with extreme ease.
> *nod* I think I see where you are going.. the event, "cast spell" is
> plunked on the queue, and handled as quickly as possible. Handling
> means calling a method which may "sleep" for a while, to take care
> of the delay.
Ouch -- that's a very expensive route. Cheaper:
The initial event parses the "cast fireball" command and logs an
event to try and cat the fireball.
That event then runs aaaaaaaaand determines if a fireball can be
cast, and when. It then logs a new event to cast the fireball then.
That event then ripens in XXX time and the fireball is cast.
Nothing goes to sleep, no resources are wasted, all the events are of
minimal size and resource loading.
> If it's interrupted while sleeping (someone interrupts bubba casting
> the spell), you have some sort of 'interuppted' method which handles
> the results of someone busting up bubba's concentration. Right?
This gets tricker. THe above format forces all events into the
structure of:
1) Check that the event is still valid (the event is to do X, and X
is still possible? ("Hit Bubba" and Bubba is no longer present)).
2) Do the deed.
In the case of sensitivity to interruption I currently handle this
poorly (almost not at all).
However, previously I discussed having the system track the osers
activities, and from that attempt to determine that they user's
_intentions_ are. From there it can appropriately attempt to filter
the available data against a dynamic LOE (level of expectation) filter
which changes as the system changes its understanding of the user's
goals.
This may be extensible to handling interruptions. Essentially (all
Wiggin's solution) the server would track the activities (of duration)
that the user is engaged in, and dynamically remove and add entries as
the world changes. Some things would get deleted from the list (you
cease to dig the Panama Canal as the world is obliterated by a passing
Vogon fleet), and others would merely be surpressed temporarily (you
pause in digging the Panama Canal to eat a vegemite sandwhich before
returning to digging).
> That being the case, I'd still prefer to let events spend their
> delay time on the queue, instead of in a thread. Each sleeping
> thread is a thread that could be used by something else. Why
> allocate a scarse resource before it's 100% needed? Again, this
> harks back to my initial goals, of building a non-cpu intensive
> game... well, at least, less so than other games... ;)
Precisely.
> mmm.. I dunno that that is really a valid concern... I am leaning
> more and more towards JC's Spoof/Watcher model, which allows for
> such things nicely (definately planning on spoofs.. still thinking
> about watchers..
Spoofs and watchers have different function, altho their capabilities
can cross. The intent of a watcher is purely to tragger on sate
changes. This allows objects to react to changes in other objects:
Bubbaa stands on the end of a balanced see-saw. You give him a
rock, and the see-saw will topple his way. The cannonical scenario
here was Bubba and the Crystalline Tree where the challenge was making
the tree suitablely fragile for all the ways that Bubba might be able
to get into it including counting the ways his weight might change
while he was in the CT. eg:
Bubba teleports into the tree (can't do the weight check in the
"climb" process).
Bubba is hanging onto balloons while he climbs the tree, which he
then lets go of once in the tree (same as before, but the climb
process validated the weight, which has now changed).
Bubba is lighter because of a "fly" spell which is then cancelled
(variation on teleport and "entry checking" ala climb process).
Boffo teleports a heavy object into Bibba's pack.
The gravitational constant changes for that part of the world
_after_ Bubba is ine the tree.
etc...
I wanted a general solutionw hich could elegantly handle all of these
without special casing.or requiring bizarre design or coding rituals.
> dunno if my design goals necessarily coincide with
> the ones you chose that lead to spoofs/watchers, JC).
I presume this means that requirement that any feature must be able to
be programmed without requiring source access to any objects other
than the ones embodying the featuer?
> W/O using
> watchers (to watch the phase of the moon), I would schedule an event
> to go off at the beginning of the time the lycanthrop should morph,
> to trigger the morph, and then one to go off at the end of the time,
> to morph the poor bastich back.
What happens if Bubba manages to delay or accellerate moon-rise/set?
What if this was thru administrative errors (Admin reset the time and
forgot some details)? You are creating an indepedant system which
does not rely on or react to the data which it pretends to be
dependant on.
There are two base approaches: watchers and messages.
In the watcher case all lycanthropes merely matain a watcher on the
relevant moon object and respond accordingly. The moon
sets/rises/whatever, the watcher is triggered and they have a chance
to react appropritately.
In the message passing case the moon state-changes and realises that
other objects may be dependant on that state change, and thus sends a
message to them, or directly invokes their methods to make the changes
itself (ugly).
There really is very little difference here from the watcher model
except that it is now the object itself determining that the state
change is relevant, and the object itself also now needs to maintain
its lists of who to send the state-change messages. Watchers just
virtualise this model by having external generic non-invasive objects
do all the work of triggering and sending the messages.
The programmer for the mood doesn't need to know a thing about
lycanthropy or wolves howling, he just needs to account for the moon.
Similarly the programmer for the were-wolves doesn't need to hack the
source for the moon, he just has his were-wolf objects put a watcher
on the moon (a very standard, on-line command), and then writes a
couple lines of code to look for the state-changes he is interested
in.
> No real worries about multiple
> events targeting the same data at the same time, as the events would
> occure once a month! :)
Until Superman gets that moon spinning faster in a lower-orbit.
> I'm thinking the best solution might be to fall back on DB
> backups... every <so often> the program dumps a 'current state' of
> the pc to the DB. if a crash occurs, the last 'current state' is
> loaded. Current states would include enough info to reconstruct the
> events for the character in question. Some events would have to be
> handled seperately... combat type events, etc. mmm.. definately
> requires some thought. Mayhaps I shall go dig up my concurant
> software design notes, and DB notes on rollback techniques.
One of my early design had the DB do periodic saves to backups. The
problem as you note was maintaining logical consistancy for changes to
the DB __during__ the backup procedure without requiring the entire
game to halt during the backup.
It can be done. The solution consists of two parts:
1) for object in DB, write object to backup DB.
2) for object change during backup where object has been written to
backup DB, flag object in backup as deleted, write changed object to
current running DB __and__ backup DB, and update indexes appropriately.
> Bubba and Boffo are fighting. Bubba and Boffo are on different
> clocks for their 'db backup' events. Combat is interrupted by a
> crash / termination / reboot / whatever. If all events are stored
> in the db backup, Bubba and Boffo will have different pending combat
> events, based on the different times at which their last backup was
> made.
True.
> Easy solution, put everyone on the same clock. problem: large db
> writes, all at once. slams system pretty good with a lot of ppl on.
See above. You can make the backup thread quite low priority.
> definately a DB rollback issue.
Nooo. A consistancy issue.
> Any comments from the peanut gallery? :)
More salt please.
--
J C Lawrence Internet: claw@null.net
Internet: coder@ibm.net
----------(*) Internet: jc.lawrence@sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - Event handling (was: request for comments) Matt Chatterley
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- request for comments JC Lawrence
- Text vs Video; Movies, Books & muds. Nathan Yospe
- Unique items (was: Graphic MUDS/Ultima Online) Vadim Tkachenko
- Unique items (was: Graphic MUDS/Ultima Online) JC Lawrence
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Marian Griffith
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Chris Gray
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Unique items Richard Woolcock
- Unique items Jon A. Lambert
- Unique items Vadim Tkachenko
- Unique items Jon A. Lambert
- Unique items JC Lawrence
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Two Tiers Ling
- MUD Development Digest Dr. Cat
- FAQ Ling
- Clients Matt Chatterley
- Clients JC Lawrence
- Clients Shawn Halpenny
- Clients Matt Chatterley
- Event handling - some definitions Jon A. Lambert
- Event Handling Jon A. Lambert
- Simulations - was: 'A flamewar startingpoint.' Jon A. Lambert
- Formatting apology Stephen Zepp
- OT: Insane Wordwrapping Caliban Tiresias Darklock
- OT: Insane Wordwrapping Alex Oren
- Summary Marian Griffith
- Clients Andrew Wilson
- Vast areas in muds Ling
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- Vast areas in muds Mike Sellers
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- META: Web futures for the list JC Lawrence
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Chris Gray
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Caliban Tiresias Darklock
- OT: Socket programming - platform specific Chris Gray
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Nathan Yospe
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Koster, Raph
- Graphical mud perspectives Mike Sellers
- Graphical mud perspectives Koster, Raph
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Nathan Yospe
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads Chris Gray
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads coder@ibm.net
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Vadim Tkachenko
- CORBA, RMI, threads Caliban Tiresias Darklock
- CORBA, RMI, threads coder@ibm.net
- Clients based on Netscape 5? Greg Munt
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Marian Griffith
- Clients based on Netscape 5? coder@ibm.net
- OT? The impact of the web on muds Mike Sellers
- The Anti-Mac Interface JC Lawrence
- 3D graphics (Was: The impact of the web on muds) Jon Leonard
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) Mike Sellers
- 3D graphics (Was: The impact of the web on muds) Chris Gray
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- VRML Becomes ISO/IEC International Standard (fwd) Nathan Yospe
- Arctic's Project? Brandon Cline
- Arctic's Project? Adam Wiggins
- Arctic's Project? Brandon Cline
- Arctic's Project? Chris Gray
- FAQ Marc Eyrignoux
- Java and Javascript Greg Munt
- Java and Javascript Chris Gray
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Chris Gray
- Java and Javascript Jon Leonard
- Java and Javascript Matt Chatterley
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Mike Sellers
- Java and Javascript J C Lawrence
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Travis Casey
- Java and Javascript Jon A. Lambert
- Java and Javascript Sauron
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Alex Oren
- Java and Javascript Chris Gray
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- MetaVoice, MetaFont Ling
- MetaVoice, MetaFont Richard Woolcock
- MetaVoice, MetaFont Vadim Tkachenko
- MetaVoice, MetaFont JC Lawrence
- MetaVoice, MetaFont Chris Gray
- The MLI Project Vadim Tkachenko
- The MLI Project Marc Eyrignoux
- The MLI Project Vadim Tkachenko
- The MLI Project coder@ibm.net
- The MLI Project Ling
- The MLI Project coder@ibm.net
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Travis Casey
- The MLI Project Travis Casey
- The MLI Project coder@ibm.net
- The MLI Project s001gmu@nova.wright.edu
- The MLI Project Vadim Tkachenko
- The MLI Project Travis Casey
- The MLI Project Stephen Zepp
- The MLI Project coder@ibm.net
- The MLI Project Travis Casey
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Andrew C.M. McClintock
- The MLI Project Ling
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Niklas Elmqvist
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Caliban Tiresias Darklock
- The MLI Project J C Lawrence
- The MLI Project Chris Gray
- The MLI Project Koster, Raph
- The MLI Project J C Lawrence
- The MLI Project Vadim Tkachenko
- Races and stuff (was: FAQ) Vadim Tkachenko
- Races and stuff (was: FAQ) Marc Eyrignoux
- Races and stuff (was: FAQ) Vadim Tkachenko
- OT: I'm moving again! JC Lawrence
- MUD Development Digest Dr. Cat
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Adam Wiggins
- Administrative Responsibilities Greg Munt