Re [long]: CODE RFC Room Programming Design

From: Ric Klaren (j.klaren@student.utwente.nl)
Date: 10/10/96


Hia,

On Tue, 8 Oct 1996, Gary Barnett wrote:
...
> Design Requirements: Interpreted language for rooms (and later mobs and objs)
> that would be flexible, simple to learn (and debug), and as fast as possible.

It's possible, I have done it upto now only for mobs, rooms I have to add
later on... (meant a bit of a rewrite since it was too mob based, should have
thought first :( ) I used the compiler/scanner generators from the cocktail
toolbox because those were written for speed.... Untill now the produced
interpreter is way fast enough on our mud server. e.g. one load thousand mobs
with fight prog into room and let one go berserk.... result screen output is
bottleneck no lag because of the fight triggers. (one cheering happy
implementor feeling :) Using a parser generator makes imping the thing a lot
easier. Unless you don't know how to use them.... then it's a big problem :(
wrote the first running version of my mobprogs in about a 14 days (to
illustrate the fact that using a generator is quite handy (i didn't even
write fulltime)).
The toolbox takes also care of generating syntax error stuf complete 
with line and column numbers and what it is expecting of you on the 
point of the error.
For the speed requirements I used a recursive descent parser (a system 
where each language construct is put in one function which calls 
recursively other functions. (ok it's not 100% accurate description but 
alla) In the specs of the toolbox it is stated that it can parse about 
900.000 lines per minute (on a 68020).

> This system must allow online entry via OLC.. 

Then you'd have to write a better editor..... maybe even one using 
charactermode telnet. Or find a way to glue an external editor to the 
telnet connection of the user (Unix only I guess)

> and dynamic program replacement,

That's no problem if you got the structures a bit sorted out... 
including freeing up space of old programs, variables etc. 

> so a reboot will not be required. Also a means of reporting syntax errors at
> the time of entry will be included.

That might require using two parsers.... one for syntax checking and one 
for the real executing. (ok it's possible to do it in one but that would 
mean adding some means of 'dry run' mode and I don't think all those 
checks would be to well for the speed of the sucker)

> Room Program Types: <snip>

IMHO sufficient ;)

> Program Structure Keywords
>  FOR I = ? to ? - Used primarily to step through a list of people
>  EXIT             to do some nasty effect to them.. or just move
>  NEXT             them around..or step through a list of items to
>                   damage them *grin*

I didn't add loops because of the fact I used a toolbox. The if was already
quite a dirty hack but loops wouldn't be impossible making a for would be
safe I guess... using a while (or something like it) might not be a good
idea. What if a prog writer screws up and a mob/room/prog ends up in a
endless loop in which it loads thousands of mobs in a room (or something
extremely funny like it :) (though done in a for it might be quite an
indigestion for your mudserver too)

>  INTERVAL  - Used to set how often the program runs. (one second granularity)

good idea

>  RETURN    - Done.. End the program. Not required at the end of the program.
>  RESTART   - Clear all local vars and start at the top.

Tricky using a recursive descent parser..... (can be done but loads of checks
all over the place, altough.... I'll go see the code i guess :) )

>  RUN       - End this program, and Run another room's room program. 

There's a limit on this I hope or something to prevent progs running 
eachother indefinitely.

>  CALL      - Run another room's room program, then restart this
>              program when it finishes (this will clear local vars)

Clearing local vars?? i guess that wouldn't be practical... Also a user 
of the language might think of it as very strange.... Again the prog a 
calls prog b calls prog a problem....

> Commands

For the commands I used the command interpreter (this is also the reason 
why I have to do a bit of a rewrite :( (command_interpreter needs a 
char_data <sigh>) For mobs it works beautiful for rooms it would really 
suck.... 

>             (C style +=, -= is only supported in the SET command)

With parser generator real easy to add ;)

>  INFO      - Send a string to the INFO channel.

Maybe add a prog channel (for all kinds of errors (only to imps)) 

>  Data Structures:
>  MOBS[] A list of the mobs in the room.
<snip>
> 
>  CHAR[] A list of all players in the room.
<snip>

(ok it's a very small change not worth mentioning almost but call them 
MOB[] and CHAR[] or MOBS[] and CHARS[] (I personally hate such small 
inconsistencies in languages - ok sue me for it ;) )

I missed these:

.MONEY    -- (RW) mob/PC's money
.BALANCE  -- (RW) mob/PC's bank balance

>  WOBJS[] A list of all the objs the event causer is wearing. 
>  EOBJS[] A list of all the objs the event causer is wearing. 

Why not MOBS[] or CHAR[].WOBJS[] ? so you'd get
CHAR[].WOBJS[]    -- worn objects
                  -- with indices names of wear positions

eg: CHAR[CAUSER].WOBJS[WIELD]

CHAR[].IOBJS[]    -- inventory objects

> Temporary Variables... used for program scratchpad and text output. 

I used 'complete' variables so you'd declare some variables at the start of
the prog and you'd use them by their respective names (construction with
hashtable). I imped an int and a string type. even made it so that all
variables for a mob are shared over their triggers progs, and the values are
remembered during consecutive trigger calls... 

> Restrictions on code.
> 
> 1) For Loops. 
>    a) Cannot be nested

IMHO impracticle...

>    b) Cannot be inside of an if/then construct.

Why? 

> 2) If/then/else/endif statements.
>    a) Cannot be nested.

Again impracticle.... (IMHO that is...)

Hope I said somehting usefull in this load :)

(my replies to replies to this might take some time for faster replies 
send a cc to klarenj@cs.utwente.nl)

Grtnx GrimReaper
aka
-----+++++*****************************************************+++++++++-------
- Ric Klaren - j.klaren@student.utwente.nl - ia_ric@cs.utwente.nl -------------
-----+++++*****************************************************+++++++++-------
``Why don't we just invite them to dinner and massacre them all when
they're drunk?''
``You heard the man. There's seven hundred thousand of them.''
``Ah? So it'd have to be something simple with pasta, then.''
-------------------------------------------------------------------------------
From: Interesting Times by Terry Pratchet
-----+++++*****************************************************+++++++++-------

+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   http://cspo.queensu.ca/~fletcher/Circle/list_faq.html   |
+-----------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/18/00 PST