[MUD-Dev] Java and Javascript

[Jon A. Lambert]

On 27 Feb 98 at 0:03, Caliban Tiresias Darklock wrote:
> On 08:41 PM 2/26/98 +0000, I personally witnessed Jon A. Lambert
> jumping up to say:
> 
> >Of course they better do what I want, when I want 
> >to do it, or things I would have liked to do if I had thought of it 
> >or I don't use them.  
> 
> I have never seen an automated program that worked the way I
> expected. I want each and every knob and dial exposed where I can
> twiddle it, and I want it to do NOTHING AT ALL until I have verified
> all the settings and hit the go button.
>

That's why the undo key is a necessary feature to such programs.  You 
have the ability to mangle your document, undo it, go in a twiddle 
and tweak and try again.  I must admit I like Word's interface.  
For instance, I load C++ code into word and have created buttons and 
macros I use to generate different cross-reference listings.  I can
load code into a protected template and begin to massively 
comment it, without fear of accidently overwriting real code.  I've 
used in translating the Mud List Archives into various formats for 
import into mail message databases.  However, its not the ideal
place to be working on code; a glorified EMACs, it is not.  My 
compiler IDE has a similar built-in language called ObjectScripting 
and I have yet to learn how to use it effectively.  <sigh>  To little
time.

My experience with style-sheets parallels yours though.  I don't use 
them.  For a good laugh, DL a copy of the Gettysburg Address and 
run it through Word's grammar checker.  ;)   

> >I don't like my cards getting eaten and 
> >crawling around in the machine to find them.  What I'm trying to say 
> >is that what I really, really want (Uh) is a zig-a-zig ha.
> 
> "HE WHO CONTROLS THE SPICE... CONTROLS THE UNIVERSE!!!!!"
> 
> Sorry, I just watched Dune again yesterday. ;)
>

Hmm, Perhaps there's something deeper to these inter-galactic 
trollops than I had originally thought.  Who are they and what do 
THEY want?  Is the hidden agenda behind this "girl-power" really a 
major move on the spice market?
 
> <sudden jump to being on topic> This fits in relatively well with
> the concept of interfaces for MUDs. Some people want the engine to
> have common sense. Some people don't. For example, in your average
> program, the autotype and such shouldn't happen unless you turn it
> on, and when you do have it turned on you should be able to frob
> lots of settings to make it work like you want it to. What I see in
> most MUDs is an entirely incorrect assumption that the interface
> which makes sense to the programmer is the interface which makes
> sense. The climate of the internet, as many people have noted
> recently, is very different; when MUSHes and MUDs were first getting
> to be popular on the net, you could assume with reasonable accuracy
> that anyone on the internet was a programmer or at least a college
> student with some programming aspirations and ability. You could
> further assume that the user who was logging onto a MUD was not only
> familiar with but probably *expert* at Dungeons and Dragons, which
> was pretty much the only game in town (no pun intended) at the time.
> So even if your game system bore no resemblance whatsoever to D&D,
> you could explain it in D&D style terms and reasonably expect to be
> understood.
>

     I think a good interface will expose a button or keystroke that
will attempt an action using the most likely intended action or
default parameters.
     At a secondary level, the button or key-sequence will expose its
properties to the user to twiddle and tweak.  Even allowing the user
to set those up as defaults for that operation or allow the user to
clone/map the newly defined operation to a new button or key-sequence.

     At an even deeper level a good interface will have a macro or 
script language to program multiple clicks or key-sequences 
(operations) using conditionals and looping constructs.  These may 
also be mapped to buttons or key-sequences.  This client language 
should be aware of its host environment to some extent.  This would 
mean that something like JavaScript's or VBScript's awareness of the 
host browser would be ideal.  Or WordBasic's awareness of the Word 
environment.   The mud client language should be aware of the mud 
client as a host and nothing outside of that sandbox.  

I just got a new copy of MushClient, I was using an older version that
did not have the client language additions.  So I'll give it a look
see.    

> Nowadays, there are hundreds of game systems, many of which are
> nothing like D&D. The internet is available to nearly anyone,
> anywhere, regardless of educational background or computer literacy.
> It should be obvious that the interface of MUDs will need to change
> drastically in order to accommodate these users, or the MUD
> community will slowly die. And therein lies the rub -- not only do
> the new players need to be accommodated with easier interfaces, but
> the old school players need to be accommodated with
> *powerful* interfaces. And striking that balance is difficult. Obviously,
> the direction of MUD interfaces needs to change, but the real
> question is
> *how* it needs to change.

I don't see this as too much of a problem here on this list.  There 
seems to be a strong desire here to throw away or modify many of 
its abstractions.  Of course we all have different areas of game 
interest.  You know, the 'suit of cards' thingy.

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--