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

nu.kanga.list.mud-dev

44: 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: Thu, 13 Mar 1997 10:34:47 -0500
Organization: Kanga.Nu
> This is kind of specialized, isn't it? You're making the basic nature of
> the client dependent on the kind of world the MUD runs. It isn't much
> harder (can be easier with the right tools, I suspect) to make a client
> that is more general, so that the layout of the screen, etc. is all
> controlled from the server. 
<snip>

Yes this is a specialized client.  It is designed to run on my server and
only
my server.   In fact it's quite impossible to connect to any other mud with
it.
The client app is actually part of the servers database and is
automatically 
updated if necessary by the mud web server.  As a standalone client it is
worthless.

The server only sends contextl tags if it is determined that it is being
accessed
by my client.  Once the client begins execution, only it knows the window
sizes,
colors and fonts available of the browser its running in.   There is know
need for 
the server to negotiate this with the client.  In fact this would be quite
a mess.

For instance the following might be sent:

[:T1 You are standing in the great hall of castle Grimm :]  -- room
description
[:T2 There is a large oak door set in the south wall :] - exit description
[:T3 A banquet table:] - object description
[:T4 Lord Grimm stands before you :] - player description
[:P0 <%H,%P>] - prompt configuration
[:P1 <100hp, 200pp> :] - prompt
[:B0 "Help %":] - button configurations
[:B1 "Inventory":] 

This is simplified but the muds output is basically wrapped with context
tags
and the client determines the placement and use.  The server and client
only need
to agree on what the general purpose of the tag is.    
All mud output is basically standard unless context is indicated, the
abscence of
context is also handled by the client.
      Session.Output("blah blah",context)

JL




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