[MUD-Dev] Mud / Web Integeration

[Nathan F. Yospe]

Lee Hulbert <hulbert at superior.net> said:

>  The idea of help files available on web pages ahs given me an
>  interesting idea.  Has anyone thought of giving new players a web page and
> a
>  graphical
>  (Java,cgi,perl, whatever) interface for creating a new character?  Put the
>  basic character creation functions into a web form, and allow the players
> to
>  adjust their choices at will before creating a final character file.  Maybe
>  even a graphic that changes based on player choices.  When final tweaking
> is
>  done, the page could submit the completed character to admins(if that's a
>  required step) or directly to the game server, to activate that account.  A
>  user-friendly character creation scheme, and a (slight) load off the game
>  server, by relgating that function to the web server.  Sound feasible?

>  Admittedly, I am a lurker, and not even capable of coding a standard MUD
>  engine, but the idea has merit(I think)

Take it a step further.  Let me expound upon a method for coordinating a
web page and a mud (using an imbedded non-telnet text client-server with
either java or java applet architecture) in such a way as to allow parts
of the game to be run from the web interface without serious penalty and
with minimal slowdown.  It does require three machines in the same local
network, which means it would be far more appropriate for the commercial
market, but...

Let's start with the servers.  Technically, they don't have to be on the
different machines proposed.  A smaller version could run comfortably on
a single headless Linux box...

The servers are as follows:  
Engine/Database - Compiled core with database architechture of choice, a
means of communicating between that database and the web server.  Should
not require extensive control of data integrity... a clone method would,
given a good design, suffice to allow collision resolution without large
discrepencies.  Don't allow the web server to update anything that would
not be player-motivated - eg, if the player submits a change of armament
from the plasma rifle to the trumpet of ragnorak, the action queue would
be a database object and would get updated; alternately, the web changes
would be realtime, but would perform a check between removing the plasma
rifle and placing the trumpet to make sure the trumpet exists.  If there
is a game event that destroys the trumpet, it should be destroyed at the
next point checked.  Simple locking would solve the potential problem of
the trumpet getting destroyed, then reappearing weilded, having been, in
the wake of two colliding events, checked and found, destroyed, added to
the hand, and removed from the inventory sack.  Of course, architecture,
ultimately, determines what potential problems might arise.

Web/Applet server - Applets link directly to the engine and sockets with
characters on them.  They provide text I/O (possibly compressed?) and an
assortment of triggers to the pages themselves, possibly.  A second set,
given the deign to support it, might be a downstream only trigger to any
number of graphical elements, served by a second web server.  A special,
persistant cache could be stored on the client machine and run through a
plug-in to the browser to provide permanent graphical chaching.
Web pages are assembled by a library of cgi elements.  I'd propose using
C++ and giving a broad path to the database machine.  I've got a design,
that I've spent much time on, for a development system for C++ web based
binaries that can be compiled or assembled as sgml templates, which will
generate C++ classes when run through a precompiler, and reversed to the
sgml form with a command.  They're pretty neat... rapid aplications, for
rapid deployment.  I've been working on them for a couple of years, with
some nice results, which is fortunate, because I've just been introduced
to a commercial tool which purports to allow similar results by inferior
means...
Submits on these pages regen the page and write to the database.  What a
given submit writes is determined by another sgml template/C++ class set
that is loaded after the submit parsing executes.

Graphics/Data server - Optional third leg, allows intensive services the
luxury of their own machine and network connection.  Requests originate,
and are responded to, on the client pages.  Graphics, sound, data, which
the design might allow for, should not burden the gameplay...

--
nathan.yospe at isearch.com      Born In     Don't mind me, I'm just insane
New home page TBA           The Year of       there's someone else here,
Other contact info           the Tiger                      in my brain.
available by request      Riding it Forever After               -wibble-





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev