[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

50: Re: Just a bit of musing

[Full Header] [Plain Text]
From: "Jon A. Lambert" <jlsysinc@ix.netcom.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Fri, 14 Mar 1997 00:20:26 -0500
Organization: Kanga.Nu
> I assumed your client would only work with your server, but I guess I'm
> not used to the concept of a server that only runs one scenario! I was
> thinking that all of the stuff about what meters, etc. exist would be
> defined in the database, and so subject to change.

Hmm, I'm not sure what you mean by 'scenario'.  
The server is designed to run fantasy/sci-fi/modern/historical RPGs.

User hits web page and mud's http port, mud pushes HTML page across.
Users browser automatically checks objects against cache and only DLs
new objects.
Client executes in browser and attempts to connect to mud's playing port.
Client tells mud that he is special.
When a character is obtained/created, mud sends body tags and prompt tags.
and continues to send context tags with mud output.

Everything sent to the user exists in the mud database, including the
client
program itself.


l 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@hawaii.edu