Subject: Colin rambles on ... and on ...

From: "THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <[email-masked]>
Date: Fri, 1 May 1992 04:02:00 -0700

What is Lambda supposed to be about? 

If its a 
fun and friendly enviroment, then I think it succeeds. Organisation
could not be held as a strong point, but I think there is a certain amount
of consistancy.

Also a large number of programmers feel a desire to use thier imagination, and
use thier skills to create interesting enviroments.  I cannot see anything 
wrong with this. HOWEVER I do agree with comments made about half completed
work, abandoned by players who no longer participate, is there no way to remove
objects that belong to players who have not logged in over a period of months?
If some active player has a child of any object then they could be advised by
mail to copy the verbs so the offending (call it 'rotting' object) can be 
removed - or recycled.  This 'tat' would surely reduce the database. (As I 

As for the idea of a player calss split, I took the mail messages home to 
re-read them. And I was confused!

As a player you can use already created objects, call verbs defined on the
location, yourself, or on objects you are carrying (as well as verbs defined
heirachially). 

As a Programmer, you can create new objects, $room, $thing, or children of 
other generic objects. You can add verbs, program verbs, add properties, 
define properties ...

As a builder, erm ..., you can create children of certain objects. To make
an object interesting you would have to be able to redefine properties.

I can't see the builder as being very interesting, to really create good
rooms, objects, puzzles, scenarios etc. you would have to be able to add
properties, and the verbs to use these added props. A subset of verbs perhaps?
I don't think that would work. If you've ever used the minimal.db, you will
know that to start off with no verbs are programmed, and only eval is defined.
so you '.pr' _eval_ then use eval to create new verbs properties which will
make creating and extending the database easier. _eval_ is a great tool, you
can test results of operations, help find bugs. but if you give a builder
_eval_ you are saying, 'you are a programmer, but you have to do everything
in a roundabout way'.  If you don't its a case of making it unnecessarily 
difficult to program, and so less popular. People will lose enthusiasm, and
_then_ the MOO might die.

I feel there is a certain lack of understanding, the programmer class could
just as well be called the builder class. In fact the term would be more 
accurate. To reconcile it with fantasy muds, our $player is a pleb, an 
adventurer, $prog is a builder, $wiz a demi-god, and the arch-wiz (the great
huff-enuff Haakon) the god!

If you don't like the way this MOO is set up then, set up one where experienced
$players say to wizards ' ... I'd like to program this object with this verb to
accomplish this ... ' and the wizard could say ' No we already have something
like that here let me show you ...' or ' OK here's your programmer bit, show me
the object when your finished and I'll give you some quota to build some more'

So $players would serve an 'apprenticeship', and only be granted full 
$prog status after completing thier _meisterwerk_.

I cannot see the point in an intermediate state between $player and $prog, but
I could see the point in limiting the promotion of $player. On Lambda I cannot
imagine this being implemented, since to take $prog away from players would be
considered as behaving clique-y and elitist. 

Lets move this discussion more into how we can remove the 'tat' from the MOO,
lose players who no longer use the MOO, and clean up generally. I would be
happy to help, and I'm sure others would too. ( The database is 45000+ obj.)

Colin