[MUD-Dev] Client platforms for rapid development of experimental worlds

[John Bertoglio]

From: "Ola Fosheim Grøstad"

<cut all but the option I understand>

> 3. DOMs and javascript
> ----------------------

> Using the browser DOM is the most portable and perhaps versatile
> option, especially with high quality plugins such as Adobe's SVG
> implementation. I am however not sure of how to implement the
> networking code in a reasonable manner by using ECMAScript
> (javascript). Anyone know how to implement a smooth chat interface
> in ECMAScript? (assuming HTTP 1.1 persitent connections and a
> customized webserver).

First, let me say that this is similar to the option I have been
messing around for four years. I think a thin-client approach using
HTTP and a browser client has tremendous advantages for world
building systems. I have posted some of this stuff before.

Having said that, I would attempt to warn you off the idea of trying
to implement a persistant connection with HTTP. It can be done. We
have implemented a Java applet in that runs on our web pages and is
in persistant communication with our back end data base. This allows
seamless communication but really doesn't scale very well. Plus, you
buy all the cross-platform support issues inherent with Java We used
this technolgy, primarily, to model telnet data entry and query
applications in HTML. These old CHUI apps needed the kind of
character by character validation that is not normally possible on
web applications.

Essentially, we have come to the conclusion that it would be better
to implement a HTML solution that models standard web as closely as
possible. A web-based game world cannot have the kind of granular
interaction that is possible with a telent-based system (or any of
other thick client methods).

A web-based system would have to have a slower pace.  But the energy
not spent on the huge data flow inherent in a persistant connection
could be used to provide content and depth. What I envisoin is not a
slow version of EQ, but a really fast version of an Email/Postal
style game.  If you move through 100 zones in an hour, you must have
been very well provisioned...otherwise you would be dead from thirst
or starvation.

There are some advantages:

  - You would probably loose a lot of the "Short Attention Span
  Theatare" griefers because the would get bored.

  - You can build a huge world. I have built test worlds of up to
  40million zones and found position updates to be essentially
  instentaneous.

  - No lag problems. A high speed connection will not buy you a huge
  advantage.

  - No client spoofing problems. Everything is really done on the
  server. Lieing to the client is just lieing to yourself.  The
  server adjudicates everything.

Is this method for everyone? No. But it would build a powerful
framework to create more of an authoring system than is present in
more visual and intense enviroments. Also, as I have mentioned in
past posts, I don't have XX man-years to craft graphics...even if I
had the talent to do so.

We have messed with SVG and really like it. It reminds me of
RIPScript (any old bbs folks out there?) in that it allows you to
send text and get graphics. Kind of a discount version of Postscript
with less overhead. Again, I am not sure the pipe would support a
high frame rate for animation but it would be a great way to build
graphics.

JavaScript and Chat: Using DHTML techniques you can use client pull
(the old meta-refresh trick) or various server push
technolgies. There are dozens of examples out there using PHP, Perl
and ASP. After all is said and done, I prefer client pull. Using
DHTML and JS, you can limit what is returned to the client to those
lines of text that have not yet been seen. The old method of
resending all of the lines, every time, eats bandwidth to no
benefit.

The method we are using uses a hidden (1 pixel) frame to make the
requests to the database through the web server. The server returns
Javascript which updates the screen without a full refresh. Using
techniques like innerHTML, you can totally rewrite a page without a
full server resend. We are experimenting with static and dynamic
resend rates but find that around 15 sec gives the best balance
between creating a "twitch" game and a "get on with it" problem.

John A. Bertoglio
co-laboratory
503.781.3563
www.co-laboratory.com
jb at co-laboratory.com



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