[MUD-Dev] Introduction

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sun May 11 13:35:22 CEST 1997


[Dan R:]
:So, figuring I'm a decent enough coder, I'll write my own.  My
:goals are probably a little ambitious, but I'm hoping to see the
:following:
:
:A small footprint in memory (under 300k for the binary, plus object
:and attribute caches for a total on the order of 1.5M resident in a
:medium sized database).

MUDServ 		  182888 ----rwed 03-May-97 19:41:28

That's my server, including interpreter, database code, etc. I normally
run with a 500K database cache. There are other caches, etc. that will
likely push it up to over a Meg. Oh yeah, there is also a shared library
that contains the programming language parser and lots of utilities:

mud.library		   55468 ----rwed 20-Apr-97 17:14:47

:A "mechanism not policy" setup, such that all the rules about the
:'game' are kept internal to the database as opposed to hardcoded into
:the server/driver.  By extension, an internal language that's
:powerful and efficient enough to code the game rules and secure
:enough for day to day use.

Definitely

:A *small* codebase (ideally also under 300k) that's well documented
:and cleanly coded such that it's easy to extend if necessary.

That might be a problem. Mine is currently:

MUD.index		   49524 ----rwed Friday    23:15:35
MUD.data		  591194 ----rwed Friday    23:15:35

When you make your server generic, and put all the actual scenario rules,
etc. in to the database, that can push up the size of the database a lot.
You can aim for a small one, and it might even start that way, but I bet
it will grow, and grow, and grow...

:At this point I've finished most of my db layer, and a good portion of
:my networking code.  Now I just need to design and implement the
:internal language.  (I'm leaning towards a Forth/MUF-like stack-based
:language at this point)

You want to think about this a lot. Are you the only one who you would
want to use the language? If so, they choose whatever fits your needs. If
not, then think about what other people know and are used to. That's why
the C-like languages in LP and MOO are successful. Personally I'm
sufficiently arrogant that I just made a language like the previous
languages I've designed, and force people to use it, even though no-one
is familiar with it.

Might I suggest that you make your language strongly-typed? Many people
don't like that (not me!), but it can make it run a lot faster if you
don't have to do very many run-time checks or conversions. Similarly,
force people to pre-declare variables, so that you can access them via
something other than their name at run-time (e.g. an offset from a
current scope pointer, allocated on entry to the scope).

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



More information about the mud-dev-archive mailing list