[MUD-Dev] Re: Some thoughts on languages and users - was: Ma

[Jon A. Lambert]

On 28 Apr 98 at 22:15, Chris Gray wrote:
> [Jon Lambert:]
> 
> [much trimmed!]
> 
> :Rather than attempting to discuss your server design (since I'd be 
> :quite ignorant), I'll bore you with a few thoughts on my own design 
> :philosophies regarding languages and how they relate to my server 
> :and my users.  And needless to say, run right off on a tangent.
> 
> Me too!
> 
> There are sort-of (okay, I'm stretching it!) 4 levels in my system. The lower
> level is all written in compiled languages (soon C), and I'm the only one
> who can currently touch that level. The next level is the MUD programming
> language, which is quite a bit cleaner and safer than C (e.g. there are
> no pointers, and the run-time catches things like division by zero, array
> indexes out of bounds, etc.).  Anyone who has been granted "apprentice" or
> "wizard" status can use that language. 

Nod.  I agree that pointers should not be present in a user MPL and 
catching run-time errors safely is very important.  I've seen several 
implementations from C++, Ada, Java and several current MPLs.  I think 
some of the MPLs have done a good job in this area. (kudos to the 
Genesis/Cold crew).  

I know you've posted on this before, and there was a heated discussion on 
it, but I can't remember what your position on variable typing was.  
I'm going for very weakly-typed variables (all variables are of type 
variant), yet having requirements for simple declaration.  Sort of like 
"Rexx, but you better tell me what's a legal name".  All type resolutions 
are the responsiblity of the component object interface.  I'm still 
wrestling with how I handle type promotions and conversions.   

> The next level is a text input with
> prompts system, where the form of code that can be written is quite a lot
> restricted, and each portion is prompted for (the prompt itself changes, and
> there is a one-line full prompt for each section). To be honest, I don't
> know that this type of thing is worthwhile - I haven't had a chance to
> watch the appropriate level of player trying to use it. 

Hmmm, why not implement it as the accessible, but hidden, power-user 
interface for your next level?  

This kind of reminds me of IBM's QMF.  One can cycle through a series of 
screens and specify the different sections of a query and report format 
and then execute or save it when satisfied that all is well.

Aside: QMF sometimes included an apologetic "Sorry" in it's error 
messages.  

> The highest level
> of things that can be done is done completely with the mouse. There is the
> least capability with that method, but anyone can do it. The only problem
> most people get into is entering object names properly (I want them in
> an internal form like 'noun;adjective,adjective').

It is my fervent hope that programming side of my builder interface be 
mostly point and click.  Anything that's an mud-object or component will 
be dragable to a blank piece of paper and linked together with sequence, 
control and decision links.  Control and decision links can filled in 
manually or through expandable property boxes.  (sort of like the VC++ 
or J++ Object Explorer interfaces).  Every Object is reflective of all 
it's public properties and methods.  Of course hot keys will be 
available.  

The actual creative writing task will also be done on a blank piece of 
paper.  It will likely resemble one or more of the popular WebEditors.  A 
library of tags and components can be selected and embedded within the 
document.  The visible format will resemble an expandable/collapsible 
outline.  The idea for this comes from some ancient DOS versions of 
thought-processors that I've had the pleasure (and displeasure) playing 
with.

> Both of the upper levels are written within the MUD language, so can readily
> be extended as needed.
>

Nod.  The output of my upper level will be MPL, although the state of the 
desktop will be stored separately for now.  Perhaps eventually it will be 
a roundtrip tool.  Actual user interface aspects must be written in a 
native language rather than the MPL since there is way too much platform 
dependence here.   

> My experience is very limited compared to some out there, but what I've seen
> is that some people master the MUD language without much trouble. Others
> aren't into programming, but do enjoy the simple building a lot, and will
> spend hours redecorating things. Still others only want to bash things.
> Nothing new here, but merely pointing out that all levels of users will
> exist for any aspect of the system.

I have a gut feeling that users will fall into 4 categories.  I have no 
idea of where and how the numbers fall out.

1) Not interested.  I came to play.
2) Notemakers.  I write, therefore I am.  I'll just pick from the 
   library, thank you. 
3) RubeGoldbergers.  Willing to use most of the tools of my "widget 
   workshop" and fiddle with the properties.  Not quite right?
   What's that stuff that looks kinda like basic?
4) Scriptors.  Drop me into the MPL.  I know how to swim.

> I won't comment much more here (my brand new computer awaits me), but I
> like Jon's idea of building everything out of components, which can then be
> disassembled (or further assembled). Lots of stuff can be handled that way,
> but, as usual, there will be lots of annoying exceptions, too! Things like
> fluids would need special handling, as would situations where the original
> components still maintain some of their identity.

<Gasp!>  Oh crap... fluids and gases.  This is excellent thread material. 
Anyone? Help! 


--
--/*\ 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   /*\--

--
MUD-Dev: Advancing an unrealised future.