Just a bit of musing

coder at ibm.net coder at ibm.net
Fri Mar 7 07:38:19 CET 1997


On 04/03/97 at 06:14 PM, Nathan Yospe <yospe at hawaii.edu> said: >On Sun, 2
Mar 1997 coder at ibm.net wrote:

>:Outside of that about the only real point I'd argue vehemently agaist are
>:platform specific clients, whatever the excuse.  

>Hmmm. You suggest instead that everything be Java? 

I don't care.  JAVA, Tcl/TK, whatever.  There are quite a few
possibilities.  What I am right royally sick of however is the "chase the
Wintel market and ignore the rest" attitude.

>I hate to be abrubt,
>but for a gmud, the most you can expect to support is X-Windows, Win32,
>and MacOS. 

If you're taking the JAVA approach and are sufficiently careful with your
compatability, the client set is then:  *nix/X, Wintel, OS/2 (one of the
faster VM's), MacOS, Be (pretty soon if my rumours are accurate), MVS and
TSO via 3270 or 5280, and I'd also expect OpenVMS not too far in the
future.  That's not a bad set.

>With the exception of AmigaMUD (Hi, C.G.) the majority have,
>admittedly, been Win32 exclusive. 

BSX?  (Agreed BTW)

>:Hurm.  Raz I think talked extensively on Wout's list about externallising
>:the IO this way.  For a free programming MUD the problem quickly becomes
>:synchronising the client and server DB's -- especially when no strings or
>:string references are hard coded into the server anymore.  (Not to say it
>:can't be done, but it gets entertaining).
>
>Of course, the free programming issue does complicate things. I had been
>thinking about impulse passing, with a massive array of strings at the
>highest level of the IO being pulled for impulses, thus allowing possible
>d/l and impulse passing to the client... even further extension leads to
>clients that display this graphic instead of this text, etc... 

Again, while all this is definitely possible, the problem becomes almost
nightmareish when the server itself doesn't "know: any of the strings
involved  (eg they're just random attributes in random objects/DB records
which happend to get sent to users as vs computed upon).  Note that I am
writing of with a MOO-style server/data seperation here.

For that type of seperated server (which mine is), its not a problem that
I see an elegant way to solve.  I suspect I'd rather wait for the
bandwidth concerns to be reduced, or to cache other interface elements.

>:Cf Rogue/Larn/Hack.

>Huh?

Old ASCII map dungeon games.  About the only other in the field I can
think of is Moria.  However I think I trimmed the wrong quote to go above
that line...  (Been way under the weather lately)

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...





More information about the mud-dev-archive mailing list