[MUD-Dev] Introduction

[Chris Gray]

[Dan R:]
:> MUDServ		  182888 ----rwed 03-May-97 19:41:28
:Just out of curiosity, what sort of system type is this?  (I don't
:recognize the directory listing style)

AmigaOS. My system only runs on Amiga's so far.

:The 300k goal wasn't for the database itself, but for the amount of
:code.	I was disgusted when I discovered that TinyMUCK was over 1.2M
:of code.  300k is high itself.  I'm honestly hoping for around
:175-200k.  The database itself is likely going to be huge. :)

But, you need extra code for special stuff on objects, in rooms, etc.,
otherwise everything is the same. I normally count source by lines, but
I'll go look....

    Basics - 300K - this is the closest to a "code base"
    Scenario - 216K - MUD mail, bulletins, some NPC's, core world, usenet
    Combat - 68K - adds combat stuff to base
    Proving - 244K - 4 level dungeon with lots of special code
    Building - 172K - adds on-line building facilities and some locations

I consider my stuff to be far too simplistic at the moment, so things
like "Basics" needs to grow. So, I'd say 175-200k of source for a good
MUD base is pretty small, unless your code is *extremely* terse! Mine
isn't too terse - there is no overhead for me in using meaningful
identifiers, proper indentation, etc., so I do.

:I've considered a bunch of different ideas, including including a
:full Scheme subset.  However the implementation details of a stack
:language versus a stack-frame language like C are pretty significant.
:Even with tools like yacc, writing a language like C is not easy and
:takes a lot more memory and processing power to 'compile'.  (I'm
:currently leaning towards not compiling the language at all, since
:interpreting a stack based language is very straight forward). 
:
:I'm also not convinced that C is a good language.  I use it and like
:it, but for a beginning programmer a lot of people believe that a lisp
:or forth-like language is actually easier to learn.

Hmm. Possibly. Full C is not a good choice, and I personally think its
basic syntactic structure is quite poor. A Lisp-like language doesn't
have many rules, so it is easy to start off in it, but, to me, that
kind of language has trouble as soon as your code starts to get big. As
for Forth-based systems, well I can't see how it can be easy for non-
programmers. The only people who think in reverse-polish notation are
those that grew up with HP calculators! Forth also gives the programmer
no help at all if some important token or stack-op is missing somewhere.

Simple syntax doesn't necessarily make for an easy-to-use language. The
key is to have consistent syntax, and readable syntax. [I've done some
programming in Lisp and in Forth, and I've written major parts of both
languages.]

:I'm still in the air on this issue.  The few strongly typed
:language/systems I've used left me rather cold to the idea.  (I'm of
:the "I know put four chars there, but give me them as an integer
:dammit." school of programming myself :).

Er, you definitely don't want to allow the kind of direct casting that
C does - that blows your safety and portability! You also need to have
pointers to be able to try it. Consider:

    int *p;
    char ar[4] = {'a', 'b', 'c', 'd'};

    p = (int *) ar;
    printf("value is %x\n", *p);

First, this will only attempt to work on machines with 4-byte integers.
Second, you'll randomly get errors at run-time, since many machines
(particularily RISC's) have alignment restrictions. Third, when it does
work, you'll get totally different answers on big-endian versus little-
endian CPUs. Oh yes, don't try it with any characters with the high bit
set, or with Unicode characters.

If what you meant was the multi-byte character constants that C has (does
C++ still support this?), then I would ask why you want to do that - you're
not planning on limiting the significant letters in your words to 4 are
you? Ick! And you still have to do character moving to get the words into
somewhere you know is properly aligned before you can do integer comparisons
on them.

If you need to convert from a string to an int, its no big deal to call a
conversion routine, which the system should have builtin.

Got any better examples?

:I've been trying to come up with a reasonable way to implement a
:slightly 'stronger' typing for Forth (numbers, strings, lists,
:objects, and error types, mostly castable to other types) without
:completely breaking the language design.  The other thing I'm trying
:to avoid is local variables.  Right now, it's on the stack, in an
:attribute on an object in the database, or it doesn't exist.
:Unfortunately I might have to back off on this, since local vars. are
:incredibly convenient for a lot of tasks.

If your system is programmable on-line, then you don't want it to crash
if someone programs something incorrectly. The bit of code that is running
can crash, but is shouldn't bring the whole server down. This is
especially important if you allow other people to program. Things like
MUF work because they don't have dangerous things like type-cheating,
pointers, unchecked array indexing, etc.

Local variables can aid efficiency a lot. You can cache DB values in them.

Don't be scared off by the seeming difficulty of writing a parser and
interpreter for a language with more syntax. Its not all that difficult.

** Warning: highly opinionated statement coming. **

Just avoid using silly tools like lex and yacc. Stick to a custom lexer
(its easier) and use a recursive descent parser (also easier, and gives
much better error messages). You don't need super high powered tools for
a simple MUD language, either.

** End warning. **     [Dons flame-proof garments]

For an example of a custom lexer and recursive descent parser, see my
ToyMUD archive at   ftp: ftp.myrias.com   /pub/cg/MUD/ToyMUD

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA