Random thoughts

[Jon A. Lambert]

> From: coder at ibm.net
> >> From: Jon A. Lambert <jlsysinc at ix.netcom.com>
> I *really* like ColdX as a base design.  Brandon (and Gred Hudson as the
> original designer of COLDMUD which ColdX is directly based on (Greg dumped
> it on Bandon)) made a lot of very intelligent and well reasoned choices in
> the system design.  Its a slick system.  
>
I have trouble putting the thing away and forgetting it.  I guess I hate letting
something this interesting go to waste.  I'll work on my server for a couple of 
weeks and then boot this puppy up and play it with for a few days. *shrug*
It is definitely a programmer's playground, if you know what I mean.
 
> >...It is my opinion that complex languages like C,
> >C++, Java, LPC and Cold are too difficult to learn by my builders which
> >tend to be strictly non-programmers although very creative and smart
> >people. My building programs will be GUI editors with nice point and
> >click interfaces and the language used by them will be minimal and
> >integrated into the building interface.  This will probably end up
> >resembling a Visual Basic IDE environment (*giggle*).  Controls which
> >represent "black box" C++ programs  can be happily dragged about and
> >attached to objects, rooms and NPCs. They will have properties boxes for
> >minimal tailoring.  I wasn't kidding about the Visual Mud++ with
> >ActiveMud controls concepts!  Lets just hope Microsoft doesn't get wind
> >of it, so shhhh!.  Currently my proposed minimal  language seems to
> >closely resemble a subset of Fortran with very weak typing  though this
> >was not my original intention.  
> 
> Now *THIS* is an idea.  I could actually do a whole bunch of this
> currently.  Things like spoofs and watchers are really just instantiated
> templates with local twiddles.  Changing minor aspects of the rest of the
> class structure could....hurm...would not be so easy.
> 
Strike the Microsoft comments as it's probably not what really want to 
present visually to my users.  A better example would be to imagine a 
CASE tool specifically for mud building.
Eureka! - MudCASE (TM)

I guess I envision these controls/blackbox routines as generic objects
that can do nothing on their own.  Yeah, very much like a template.
These would be created and stored in a template library that the building
editors would access.

For instance, the builder creates an object calls it an apple, then looks through 
the library and drags over the poison template and attaches it to the apple.  
The template then instantiates a poison affect object associated with
the apple.  The builder may then open up a properties window and modify
some attributes like duration, toxicity, etc.  The poison template code is 
generic enough to handle its attachment to the created object whether this
be inheritance/aggregation/association I don't know.  Should the builder
wish to customize/override the code, the method code would be auto-
imbedded within the apple.  This apple could then be re-stored as
a templated black-box itself.

With a rich enough library of low-level precoded affects, objects and std
routines, even the most code-impaired builder could be productive.
Another advantage is standardization of objects for game balance.  Have
the underlying template validate and control the domain values of its 
properties.  Its also a good forced code reuse mechanism providing its
done through inheritance.
The bolder ones are going to open up those objects and view the discreet 
pieces of code, maybe gaining some insight and writing their own scraps 
of code.  Its a much easier learning curve than dumping a core's object 
hierarchy and language reference guide onto a would be builder.
Oh yeah and add a context level help with cut and paste examples!

> Mike Cowlishaw is an interesting one to talk to on language design.  A
> very opionated, articulate, frighteningly intelligent fellow.  We
> disagreed often -- but he had the research data to back his side up.  He
> put a lot of thought into REXX's baroque design -- it is and was very
> accurately intended as a language for non-programmers.

The name sounds vaguely familiar.  I've read quite a few of the Red books,
I imagine it appeared there.  

> >> > How does this handle the Dragon's Dinner scenario, ala:
<snipped potential endless requote>
> For me there actually is no problem as the general area is resolved by my
> lockless/retry model (the old C&C business I detailed, Oh, about 6 - 8
> postings ago -- I'll repost if needed.).  Essentially the two events
> execute in parallel, but one gets to C&C first and commits, the other then
> fails C&C, and retries/reschedules.  This only works becuase all events
> only modify and access local data prior to C&C.

No need, I have it handy.  Will take another look. :-)