[MUD-Dev] Java and Javascript

[Matt Chatterley]

On Mon, 16 Feb 1998, Caliban Tiresias Darklock wrote:
> At 11:11 AM 2/14/98 +0000, Mat Chatterley wrote:
> >
> >Absolutely agreed that the browser interface is not useful. If anything,
> >it means a waste of resources!

Albeit in a slightly ranty form, this contains some very interesting
points (and I'm not certain to what degree this is serious, but in either 
case, an interesting attitude - not necessarily Caliban's). Dissection in
parts follows.
 
> No it doesn't! Quit assuming that your MUD is the only damn thing I want to
> do while I'm online! I want all the same integrated features I'm used to,

But given that assumption (a reasonable one when writing a mud client, I
think), using the browser environment when not necessary *would* entail a
waste of resources. This is perhaps not a valid enough argument on its own
(OTOH, Netscape puts my machine through the wringer, and I have 64 mbs of
ram plus a fast disk). Even so, its a design thing - I hate to see big and
unwieldy things being used for tasks that can be accomplished with
smaller, neater programs (and also, it makes things more accessible to
'lower power' machines). Of course, it means I don't have to deal with
bugs in other peoples software, too.

> dammit, and your client can most definitely make use of forward and back
> while I'm playing if you use an interface that uses that -- like a separate
> help window on the side in a frame, for example. Browser-based clients can
> provide a lot of functionality and a lot of convenience, and I see a lot of

Actually, I can't think of any extra functionality that could be offered
by a Browser based client. Could you give some examples? (Genuine
interest). How would you find it more convenient?

> that being ignored on the archaic argument that it's a "Waste of
> resources". I look at my desktop right now and I see a machine with more
> memory, a larger screen, faster video, and a bigger disk than we would even
> have DREAMED of five years ago. I have more memory on my SOUND CARD than I

[Snip]

It's not the only argument; just one consideration. And you may not wish
to use the entire machine up for your mudding! You might want to run it in
the background, or low-priority rather than in a browser (I think you must
accept that browsers are fairly huge things, now).

> Christ, people, we go out and buy games now that require 32 megs of memory
> and 400 megs of hard drive, and solve them in two weeks. I think we can
> spare a similar level of resource commitment for an ongoing MUD, provided
> the distribution method is reasonable. Rule of thumb: The "average" machine
> at any given point in time is the machine that cost $1500 last year. Today,
> that machine is a Pentium-2 at 233 MHz with 4 GB disk and 64 MB. We can
> assume that the user has at least a 12x CD-ROM and 32- or 64- bit sound
> card, and that his video card has at least 2 MB on it but probably 4 MB. We

There are many machines below average. Personally, I own a p133 (intel),
with 5gb total storage space (not all available currently), and two
cd-roms (4x and 2x). The video card has 1mb ram, and the sound card
doesn't work. It also has 64 mb ram (oh, and the CPU only clocks 100
because the PSU is overloaded by the SCSI bus). The 4x cdrom is kinda
busted, too. None of this is likely to change any time soon - I make the
assumption that I am not the only person behind what some people consider
to be 'standard'.

> can therefore assume that in a year, this will be the average. Program
> accordingly. Manage resources accordingly. And quit bellyaching about the
> resources being used on the client. Yes, every time I look at my Windows
> desktop my 1970's-era programming discipline rears its ugly head and tells
> me just how many clock cycles my system is wasting on these pretty pictures
> when it COULD be doing my work. But that's modern computing for you, and
> that's life. 

The more resources the browser uses, the fewer are available for my client
if I wish to make it do clever and/or attractive things, though.
 
[Snip]

> >Or, since the browser implementations of Java seem to be flawed, require
> >the user to download a JRE (runtime environment without the development
> >tools and such) for their system. OTOH I've had no troubles with
> >in-browser Java as yet, but am not using 'cutting edge' features, either.
> 
> Yeah, exactly. I really want to download the JRE and install it. I'm just
> hankering for a chance to close all programs, edit my registry, modify the
> system files Windows isn't supposed to need anymore except for DOS
> compatibility, and reboot my computer twice. Sorry, I'm playing a different
> game.

This is no different to instally any other substantial piece of software.
Btw, AFAIK no reboots or anything of that sort are actually required to
get JRE running on windows (certainly was not needed when I test installed
an old copy of JDK 1.02 I had on the windows machine here).
 
> >You may well encounter troubles (Ack! I'm tired/sloshed, I nearly typed
> >'you may well encounter trousers').
> 
> Well, we all know where men's minds live. ;) 

Blah. :P
 
> Incidentally, if I ever encounter trousers in the course of programming a
> MUD client, I'm dropping the project immediately. That's a Bad Omen, and I
> think it's one of the signs of the apocalypse listed in the book of
> Revelations.

*Laf!*

[Greg munt originally said:]
> >> >Should I be looking at both Java *and* Javascript, to complement each 
> >> >other, or should I concentrate on using just one of them? 
> 
> Debugging will be a lot harder if you use a combination. However, if you
> can leverage an existing codebase by interfacing the two, by all means do
> so. If you understand and feel comfortable with both technologies, use both
> of them. If you feel more comfortable with Java, use it. More comfortable
> with JScript? Use it. They're just interfaces. Your major problem with
> going straight JScript is the inherent statelessness of HTTP, so you should
> probably use at least some Java to maintain a persistent network connection
> (assuming you need one). I'm sure you can do a pretty decent MUD without
> it, but saving state is one of those 'big things'. 

It could also be pretty hard to integrate Java and Javascript in any way
like this (as far as I can see). The trouble with JS really is that its a
scripting language which was (as far as I can tell) intended for embedded
objects in webpages, rather than 'dynamic objects' like Java itself.
 
> What ever happened to single player games? I don't like team sports and I
> don't like competition and mainly I want something that I can play and have
> fun with even if there's no one else there. Most of the time there isn't
> going to be anyone else involved. (Sort of like my sex life.) This network
> game boom has really caused a lot of the single player stuff to suffer.

Can't a lot of muds be played single-player (this is an interesting
notion).

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html