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

[s001gmu at nova.wright.edu]

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
 browsers*

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.

-Greg


--
MUD-Dev: Advancing an unrealised future.