Room coding

[Nathan Yospe]

On Wed, 12 Mar 1997, Furball wrote:

:This will be hard to correct...
:Transparent exits, imagine this:

I'm gonna forward this to the mud-dev list. Everybody, Furball here is a
lurker with a lot more to offer. I've been chatting with him via email for
a bit now, and he's got some good ideas. Furball, you might want to
introduce yourself with a short post. 

The discussion so far is this: we are assuming an alternative system to
the generic room with defined rectangular dimensions, and want to
implement visability from one room to the next. Exits can transmit visual
pictures to a virtual location on the other side of the exit position,
thus creating an accurate image description to be transmitted to the
viewer.

:An assassin waits in an airduct above a corridor looking down waiting for
:his target to stroll pass, he unholsters his rifle, gets settled and
:waits...

I assume the assassin's visibility is limited by the airduct... perhaps a
reduced region in the display function? My version of the function is

String Item::display(coordinates& viewerPosition, charState& viewerPerception){
  // condition handling to return a select String... shame I cannot have
  // an alternate version that returns a const String& not to be
  // discarded at a later date. On the other hand, with any luck, the Lazy
  // copying will take care of that.
  String tempString = showDesc; // lazy copy.
  tempString.descSubstitute(viewerPerception, location.getConditions());
  if(transparency > 0)
    tempString.descSubstitute(viewerPosition, viewerPerception, transparency);
  // . . . more irrelevant stuff.
}

Unless I miss my guess, this situation would have whatever your equivalent
of a very low transparency is. (Approximating slits through which the
assassin looks.)

:Ross looks down the corridor and notice there is a red spot just below a
:vent in the ceiling.  After some thought, he decides to make a pact with
:the devil and runs down the corridor!
:
:Zzzip!  (some other sound effect)

Hmmm. OK, this really depends on how your run works. Mine does a stage by
stage movement. If the assassin were watching the corridor, there would
have to be a waiting state event for anything intersecting that part of
the corridor. Run should just do a faster update through the corridor,
polling each segment moved through for verification that the move was
successful. Now, if there is a successful "go ahead and move"...

:The assassin waits patiently...

The assassin should have recieved a message when Ross zipped by, triggered
by the request to the room to move Ross from point A to point B in the
assassin's corridor. Now, if the event waiting state of the assassin was
tight on the trigger, fire on the first thing that moves, there should
have been a toss up between Ross and the assassin, no typing needed on the
assassin's part, in that permission to move request.

:Ross, now on the other side, whistles tune 'I will survive!'.

In my version, he's whistling out of the hole in the top of his head.

:The reason I present such a weird scenario is coz, if there are
:transparent exits and characters run, in my system, the characters would
:appear in the mudworld at certain points skipping the intervening space...

Right, noticed this.

:Any ideas on this one?

Running should poll ahead, not just for assassins, but for covered pits,
loose gravel, etc, etc, etc. Of course, this does work better in an event
driven system with sleeping events, a concept I borrowed from threads. My
events are very much based on threads, in fact. Aside from that, perhaps
smaller, faster steps? If you are running on a pulsed cycle, that may not
be possible....

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu