[MUD-Dev] Re: Java for Mud Client (Crossfire MUD topic)

s001gmu at nova.wright.edu s001gmu at nova.wright.edu
Mon Apr 27 10:18:03 New Zealand Standard Time 1998

On Mon, 27 Apr 1998, Joel Dillon wrote:

> On Mon, 27 Apr 1998, Justin McKinnerney wrote:
> > >
> > >   Well, at work we handle persistence in applets by passing them their
> > > identity (the name of their user or whatever) via an applet parameter and
> > > sucking data from a server over a socket or jdbc connection. That's good
> > > enough for our virtual conferencing system and presumably it'd be good
> > > enough for a mud client as well.
> > >
> > > 	Jo
> > 
> > The issue was download time for graphics in the java client if it were
> > applet based - so the persistance required here is local storage of applet
> > data so a user doesn't have to download it every time.
>   Ah *bopme* Perhaps one way (not a very nice way) would be to encode the
> data as constants in the class files. That way the browser would cache
> them for you; but you wouldn't want to do that for large amounts of data.
> run into problems with older browsers.

Encoding the data like that would also make changing the way something
looked quite difficult, unless you limited it to a set of primitives that
were encoded.  Granted, you may not want that amount of flexibility within
your system.  UO, if I understand correctly, has a graphics set that they
are not planning on changing much, if at all.  'zat right, Raph?  I recall
reading that somewhere... I think it was the Origin web page... ;)

btw, wouldn't those class files be re-downloaded every time anyway?
*doesn't know a heck of a lot about the intricacies of java and web

It all depends on what you want to do.  Some people are perfectly willing
to use hardcoded games, that have to be recompiled to add a new feature,
some are willing to write byte code.  

As for an answer to the original question, well, I haven't really
investigated the options for a client program yet.  Java applets under
netscape are a possibility, but what my design team and I have discussed
so far leads me to believe we would run into the very same problem.  :)
I was leaning towards a standalone java application, but the previous
discussion about Crossfire has caused me to re-think that.  I haven't
abandonded it yet, but it has caused me to think about it some more.


MUD-Dev: Advancing an unrealised future.

More information about the MUD-Dev mailing list