[MUD-Dev] Some thoughts on languages and users - was: Macro semi

[Jon A. Lambert]

From: Richard Woolcock <KaVir at dial.pipex.comNOSPAM>
> Newsgroups: rec.games.mud.diku,rec.games.mud.admin,alt.mud.programming
> Subject: [DESIGN] Macro semi-language
> Date: Sat, 25 Apr 1998 04:22:00 -0700
> 
> Recently I was asked by a friend and fellow implementor if I could show
> her how to code on the mud.  She had used pascal before, but never used
> C, and didn't really seem to have any grasp of the language.  In order to
> try and help her, on wednesday I threw together a set of macros to create
> a sort of pseudo-language.  I added a few more features on thursday, and
> today got the chance to show her how it worked.  Although she is still
> having problems, she is finding this macro-based system far easier to use,
> and I have started wondering if it might help a few other coder wannabe's.
>

I can see why.  It's a pretty good approximation of Pascal for C 
macros.  You might make her even more comfortable by throwing in the 
odd semi-colon after the last END. :)

Actually I think it's a great idea.  While many of us on this list 
are probably fairly proficient C programmers, it is easy to forget 
that C is not the simplest nor safest language to use.  Perhaps one 
might argue that C is simple because there are so few keywords, yet 
there are so many subtleties involved with it's syntax that prove 
very difficult for a beginner to master.  

For example: foo->bar, foo.bar, &foo.bar, y = (int *) **bar, x /= 
&foobar(**bar*foo, barfoo(&bar->foo)), z = (x==1?4:*foo).  
And I haven't even begun to obfuscate.

> Note that this system is designed for Merc, but could be easily adepted
> to most other hard-coded systems.
> 
> The advantages and disadvantages as I see it are as follows:
> 
> * ADVANTAGES:  More verbose and robust than direct C coding, as well
>   as requiring less actual code to be written.  Compiles down almost
>   as efficiently as pure C, and can be mixed and matched.

If your C compiler does good optimizations, there's no reason to 
think it wouldn't be as fast in many cases.  I've noticed many of
the available GNU languages compilers like Ada are basically just 
smart C pre-compiler compilers.  And seem to perform quite well 
compared with straight C.  In some areas even better than 
hand-written C because they call some well-written native libraries.

Full blown compilers to C, bytecode and native code are certainly
good options. (cf. "How to build a compiler." thread).

> * DISADVANTAGES:  Excessive macros resulting in poor type checking,
>   severe limitations on what you can do, and doesn't really help 
>   teach the user C.  The hope is that as the user requires more and
>   more from the code, they will slowly begin to teach themselves,
>   rather being dropped in at the deep end and not knowing how to do
>   anything.

Yes.  Even without macros C has poor type checking.  But I think you 
hit upon a very important question.  How important is it to teach 
the user C?  

The most definitive answer I can come up with is, It depends on...
 A) The server design.
 B) The user's role on the server.
 C) The user's personal goals (Is the guy/gal studying to be a C 
    programmer for other reasons?).

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.

First some of my wild-eyed theories:
1) Good builders are creative and imaginative writers.
2) Coders are easier to find than good writers. really(?)
3) It is by sheer accident that you find both in one person.  
   (Although we do have a few on this list) 
4) Players who are immersed/entranced, love to create and love to 
   destroy.  Or as Bubba said to me once, "It was a pleasure to burn, 
   to see things blackened and changed"
5) Game builders (a different critter than the writer builder) like   
   to tinker around with machines.  Assembling and disassembling    
   until they get a desired effect.   
6) Not all game builders are good coders.  Although they may have   
   tendencies.

Some problems with today's muds:
1) Writing is not enough for the area writer/builder in the mud 
medium.  The area writer must have tools to produce interactive 
fiction.  Area writers must program.  
2) Playing a game where you have no measurable affect on the 
virtual world is not as satisfying as creating, changing or 
destroying that world.  Players must program to assemble boats, 
build castles, create potions, research spells and do complex 
maneuvers.  In-game building components are just not readily 
available in many muds. 
3) Knowing how to balance the game rules, design combat systems, 
magic systems, design characters, equipment, and run quests is 
not enough.  Game builders/GMs must program.

What level of language, script or interface is appropriate for these 
types of users and their roles?  

Well my vision for the C coder (or driver author) is to code the 
networking and database interfaces, the language/script 
compilers/translators, the user interfaces, the string, memory, 
garbage collection, cache management and programming and tools 
environment for the rest of the above users.  After that he or she 
can pack it in, the drivers is done and becomes merely a maintenance 
programmer.  I don't mean to imply that all drivers should be coded 
in C.  Feel free to substitute C++, Java, Lisp, Fortran, Ada, or 
whatever here.  In short there's nothing "game" related here.  The 
philosophy coincides with MudOS, DGD, MOO, Cold and PennMush.

Next we have an environmental programmer.  We have work for our 
previously laid C programmers.  At this stage environmental code is
built in a mixture of native C and the designed mud programming 
language.  The designed mud language is not powerful enough to handle 
the tasks of creating a skeleton environment, security, etc. or needs 
supplemental library functions.  The biggest difference here between 
MudOS and Cold is that these routines are very loosely coupled, if at 
all, to the driver.  These component objects are constructed to be 
reflective enough to facilitate casual integration into the mud 
language and driver (I call them MudX objects or MudBeans <TM>). 

Next we have the Game Builder.  This person will use the mud 
language a truly simple language supplemented by native components.  
A language more simple than LPC or MOO, an object-oriented KISS.
All the game rules, character creation, critters, equipment, objects,
poisons and other trappings of the virtual world are created with 
this.  Dare I say 'business objects'.  No I won't.  The game builder 
can also tweak exposed properties of components or call component
methods.  

Then we come to our area writer.  A great many of the MudBeans our 
C programmer created and Objects our game designer form the 
backbone of a visual area creation tool.  It comes complete with a 
excruciating simple collection of visual language elements that pull 
together the beans and objects created into an interactive fiction
generator.  

Last but not least we have our player.  This is a bit difficult to 
explain and was partially germinated in another thread (cf. 
"Assemblys" and also "Population Containers")  Basically in 
addition to all components and mud objects having built-in creation 
and destruction methods, they have built in assemble and disassemble 
methods.  So anything which the virtual world exposes to the player 
will be able to be created from something or disassembled into 
something.  Now I don't start at the atom, I start at resource 
objects that make some sense.  You could start at any level of detail 
and define components up or down the chain of an object.  For 
example, I create a forest population container which contains a 
quantity of trees (only instantiated upon demand!), a tree object's
disassemble method creates component wood objects, while its destroy 
method does not.   Anyways, the design of the mud language implements 
inheritance as "containment & aggregation".  Hopefully through these 
mechanisms as more malleable world would be built.  At least that's 
the dream.  

In summary:  I see more users doing "coding" and be involved in 
mud creation and modification.  A good many more than those who know 
C.   Yet be coding in such a high-level and absract way that it's not 
programming in the traditional manner, yet it's safe, flexible and 
powerful.   

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