Re: Re [long]: CODE RFC Room Programming Design

From: Thomas Pedersen (classic@cloud9.net)
Date: 10/10/96


Why bother re-writing that much code.  If you want interpreteded code, get
*gasp* LPMud.

> 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   |
> +-----------------------------------------------------------+
> 


* Classic@Cloud9.net * tpedersen@kraft.com *
* http://www.cloud9.net/~classic *
* visit Darklord MUD at pody.westnet.com 5000 *

+-----------------------------------------------------------+
| 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