[MUD-Dev] Re: mud client development systems

[Sunny Gulati]

At 11:49 PM 12/6/98 -0600, I, Sunny Gulati <sunnywiz at radiks.net> wrote:
>
>Simple - I want to do this in small little steps.  Running it on top of
>telnet means, I could write nifty client-objects and test them in my
>current mud.   In fact, right now I'm implementing all this in an object
>I carry around in my inventory.  
>

Just to update y'all on the various ruminations and directions I seem to
be headed in. 

I realized I'm going to have a serious problem with input_to()'s slurping 
up my client->server communications.  I could either tweak the driver to 
treat a verb starting with ~ as a non-input-to thing (just like it does to !
right now), or I could skip worrying about it right now.  I'm going to chooose
the latter - and provide an input_to() client object instead.  

On the various people who are.. umm.. puzzled at my insistance on running 
this over a telnet session.. I took a close look at my motivation, and this 
is what I found: 

1. I'm not an awesome C hacker.  Playing around with a driver, dealing with
binary streams coming straight from a socket, scares me.   Especially when I
don't have a crystal clear idea of my communications protocols. 

2. I have to keep the project small and manageable with little itty bitty steps.
I simply don't have the bandwidth to do a large project (not while being a 
programmer for a living too).   My bandwidth is about an hour a day if i'm
lucky. 
Weekends I can squeeze in another 4-5 hours. :)  And I defintely want to have 
this get somewhere, rather than ball up into a big thing and stall. 

That being said, here are some further ruminations. 

My initial implementation may run over telnet; I'm hoping that further 
implementations will do exactly what Ben Greear (greear at cyberhighway.net) said:
run a telnet-like client over the link.   The link would be dedicated to the
messaging protocol (sans spiffy quoting rules).  Maybe even further development
to do compression on the streams and/or making the protocol heavily binary. :) 

3. My plan on what to implement has changed: (I go into LPC stuff here:)
 
  a. First, I will do the bootstrapping part and write a stub client and a stub 
  server;  I would get them passing dummy or ping messages back and forth. 

  b. Second, I will write an input_to type client; then wrap input_to into a 
  simul_efun on the mud.  This simul_efun will check to see if the player
object 
  has a client attached; if so it will initiate a client-based input_to.  
  
  c. I will then write a simple editor-type client, and a file viewer (ie, like
  more).  Once again, i'll try to wrap them into some sort of simul_efun where 
  necessary. 

  At this point in time, input_to's won't be a problem anymore.  The client
system
  would be integratable to any mudos-type mud (hopefully).  And people won't be 
  required to use the client; they can still use telnet stuff.  Makes for a
  friendlier development test bed - maybe I'll get more volunteers to write 
  clients :). 

  From here, there's a bunch of directions I could go. I could write that
background
  music object; I could write a spiffy chat channel thing to go with the
channel server
  we currently have on VH; etc etc.   But that's more sideways evolution. 

  Upward evolution would be: 

    i) write a telnet-like client side object.

    ii) clone the mud over to a development mud.  Start mucking with the
driver to 
    use the message passing algorithm as a primary means of communication.
I don't 
    know what this would entail, yet.  

    iii) start aiming in the direction of the 2d mud. 

4. Here's how the bootstrapping in my inventory-based object works/will work: 
(heavily LPC)

(well, okay, not inventory based anymore, since the cmd_hook is migrating 
to the player object)

The player object has an add_action that catches ~ messages.  This is
permanent. 

In the player object, I have methods query_servermgr() and a set_servermgr().  
If query_servermgr() is set to an object, then that player has a client at his
end of the connection which is alive and kicking.  

The player object also has a pointer to a bootstrapper() object.  

The mud initially clones the player a bootstrapper object, and tells it to
go boot. 

The bootstrapper sends out an initial ~BOOT<CR> message.  It set up a timer
to time-out
for the response. 

either there is no response: the bootstrapper times out and kills itself; or
there is a response; the cmd_hook notices BOOTOK - checks that there is a
bootstrapper - 
tells bootstrapper that yes, you booted okay. 

The bootstrapper clones a servermgr object.  The field is now set. 

                                 PLAYER
                      -----------------------------------------------
CLIENT                BOOTSTRAPPER          SERVERMGR      CMD_HOOK
------------------    ----------------     ----------      ---------
                      sends ~BOOT<CR>
sends ~BOOTOK<CR>
                                                           caught here. 
                                                           forwards to
bootstapper
                      gets BOOTOK, creates
                      a servermgr object
                                            this baby is
                                            initialized.


Note that I didn't want the servermgr object to exist until i was done
booting (and 
negotiating; that's where bootstrapper will come in handy).   That way
mud-side functions
have a single-step test to see if they can do nifty client stuff or not.  If
i had made
the servermgr have a seperate boot state, i would have to check

   if ((ob=player->query_servermgr()) && ob->bootok()) { ... } 

which i don't want to do. 

I haven't delved too deeply into how my clients get created.  I know how I
*want* it to 
look from a programming API viewpoint, just haven't actually drawn it on
paper to make 
sure all the ends are covered. 

Eyelids heavy.. must sleep.  It has been slow getting reaccustomed to LPC..
done too 
much Perl lately.  Will post linkages to code once its semi-barely-working,
if any 
are interested.  And/or more detail as to how things are unfolding, if any are 
interested.

Sunny

PS: I apologize for line lengths.  I'm guessing where 80 columns is; this
thing doesn't 
wrap by itself.  !#!%!#$.. 
 // Sunny Gulati 
 // sunnywiz at radiks.net (Home)