Random thoughts

[Jon A. Lambert]

Oops something got lost I think, wait here it is...

> 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.
 
> > 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.  
<snip> 
> 
A better example instead of VB (as its not what I want to present as a good IDE)
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!