Subject: Code

From: Tim Sailer <[email-masked]>
Date: Sat, 3 Apr 1993 11:35:50 -0800

Has anyone written a basic combat system, or a RPG system? If so, and
it's not too much code, could you post or email the code? I'm pulling
out my hair trying to figure this out!!!

Thanks!

-- 
Tim Sailer
JPT Computer Solutions - SCO Sales/Consulting/Administration and Mangling
Port Jefferson Station, NY
(516) 331-9001

---

From: Robert Leslie <[email-masked]>
Date: Sat, 3 Apr 1993 20:05:38 -0800

>out my hair trying to figure this out!!!

I know you've already been pointed towards good examples of a MOO combat
system, but I feel obliged to share my biased opinion that MOOs can be put to
better uses. That is, basic combat comes "standard" in many other MUD
environments, and in many different varieties. If you're interested in theory
more than implementation, I would suggest you look at some of the other types
of MUDs: LPmud/MudOS and Diku, both of which are generally known for their
combat-oriented realms. (If you don't know of any, allow me to point you to at
least one.)

I'd also like to clarify a point, since I brought it up, that LPmuds and Dikus
are not combat-oriented by nature. I personally feel that the LP environment
is ideal to program in, better by far than the MOO environment. It is only
because would-be gamers generally use LP for their MUDs that they end up being
just that -- combat games. Is it because they're so easy to program? Anything
that can be done in MOOs can also be done in LPs, and probably vice versa, but
remember I'm biased. LPs are object-oriented, too, can handle arbitrary socket
communications, and more closely resemble a UNIX shell than anything else when
you are a wizard.

My dream is to build an LP-based virtual world some day, and live there. (You
think I'm joking.) Actually, the only thing holding me back is time, time,
and time. Life as a student is rough, but rewarding.

- Rob
...............................................................................
  - No gnu have never after fret far, even Eva hung on -   [email-masked]

---

From: [email-masked] (Jay A. Carlson)
Date: Sat, 3 Apr 1993 20:50:09 -0800

> I'd also like to clarify a point, since I brought it up, that LPmuds
> and Dikus are not combat-oriented by nature. I personally feel that
> the LP environment is ideal to program in, better by far than the
> MOO environment.

It's been a long time since I've looked at LP, and I may have
forgotten stuff about it.  Could you suggest a list of things that
make the LPmud environment ideal, or at least superior to MOO?  (BTW,
I already know a couple, but I'm curious which you think are
important.)

> Anything that can be done in MOOs can also be done in LPs, and
> probably vice versa, but remember I'm biased.

Well, yeah, and I could put a socket interface in vi and use that too.
I think the real question here is software engineering costs---what
kinds of things do MOO and LPmud make simple and clear to do?

> LPs are object-oriented, too, can handle arbitrary socket
> communications,

MOOs can handle stream connections (TCP in the current implementation)
in the MOO character set, which is the printable ASCII set everywhere
right now.  I'm considering moving JaysHouseMOO to ISO-Latin1, but
there are some issues in adding characters that not all of your users
can type directly.

MOO doesn't make any pretence of dealing with raw binary data, which I
see as an advantage.  We can't do UDP, but it's simple to build
external programs that keep I/O and CPU intensive things like...maybe
I should just post my MOO networking manifesto?

> and more closely resemble a UNIX shell than anything else when you
> are a wizard.

I don't see this as an advantage.  :-/

Jay Carlson
[email-masked]

Flat text is just *never* what you want.   ---stephen p spackman

---

From: [email-masked]
Date: Sun, 4 Apr 1993 11:16:00 -0700

The argument about what flavor MUD is best is timeless, but let me say why
MOO was chosen as the server for AstroVR, a collaborative tool for astronomical
researchers:

1.)  It has a simple, yet (nearly) complete embedded programming language,
     with simpler syntax than C and more familiar syntax than Forth,
2.)  It is object-oriented,
3.)  The server code is very robust, with uptimes in the months range,
4.)  It is very well supported at PARC, and provides the basis for a
     real-world application there,
5.)  The core db is very well documented, and it is easy to document additions,
6.)  The db is all in one file, so parts of it can't get lost,
7.)  It is able to connect to other servers with open_network_connection(),
     which is necessary for us so we can access some large database servers,
8.)  An excellent client (mud.el+moo extensions) exists.

As well, there are several limitations of MOO for our purpose.  It doesn't
support floating point arithmetic.  We get around this by installing an 
arithmetic server available via open_network_connection() for now, though this
is slow for small calculations.  It does not have multiple inheritance, which
would be a convenience, but is not a requirement.  

Cheers,

		   Dave Van Buren

---

From: Robert Leslie <[email-masked]>
Date: Sun, 4 Apr 1993 21:14:48 -0700

>I already know a couple, but I'm curious which you think are

Here are, at least, things which I feel make the LP environment ideal. This
doesn't make it ideal for everybody, as for example Dave Van Buren has given
very good reasons for using a MOO in his environment. I would be interested in
hearing other people's reasons for choosing MOO. One good reason I can think
of is its relative simplicity: Designing a good LPmud from scratch is no easy
task. (Fortunately, you don't always have to start from scratch.)

1. The LP "mudlib" (equivalent to the MOO core db) is a hierarchical
filesystem comprised of various ASCII files, mostly files describing LP
objects. Objects are identified by their placement in the filesystem rather
than being assigned a permanent ID number. (This doesn't solve the portable
object renaming problem by itself, but combined with good programming
practices and good mudlib design it can drastically simplify the process
involved in porting objects to other muds.)

2. Objects are not loaded until they are needed. Thus it is possible to have a
very large mudlib without needing to store every object in memory at once.
Objects can also be removed from memory when they are no longer needed (but
still remain on disk to be easily recreated).

3. Objects can inherit characteristics of one or more other objects (multiple
inheritance). Objects can naturally override inherited functions, or call an
inherited function explicitly much like C++. Multiple occurrences of an object
can also exist (called "clones") in addition to the "master" object.

4. Objects are programmed in a language called LPC, which is syntactically
similar to C. You are fully capable of exploiting the C preprocessor for
#defines, #includes, #ifdefs, and the like. The similarity between C and LPC
stops before including pointers, although LPC adds other various useful
datatypes such as "string" and "object", and has full support for dynamic
arrays. Various implementations of LP also include associative arrays
(mappings) and floating point real numbers. LPC code is stored in ASCII files
in the mudlib, usually with a .c extension. When an object is referred to that
hasn't been loaded into memory yet, the LPC code is compiled and tokenized
dynamically.

5. Every characteristic in an LPmud is completely defined by the mudlib. That
is, there is no preconceived notion of "wizard" or "programmer" unless you
build that into the mudlib. One object, the so-called Master object in the
mudlib, controls who is allowed to do what by answering questions asked by the
LP driver. (For example, a function valid_write() is called in the Master
object whenever a user caused an object to try to write to a file in the
mudlib.) All security is implemented in the mudlib this way. NB, the LP driver
does enforce some security, such as not allowing any file access to occur
above the root of the mudlib hierarchy.

6. Every piece of interaction between the user and the mud is likewise
completely determined by the mudlib. When a new user connects, the LP driver
calls a function in the Master object and expects it to return a new object to
act as the "body" for that user. So it is up to the mudlib to handle user
authentication if desired, and set whatever privileges the user is entitled
to, in addition to manipulating the virtual world in which the user is to
live.

7. Since the mudlib has a filesystem, objects are free to read/write whatever
auxiliary files it likes, so long as the mudlib has defined privilege for it.
Objects have the ability to save all of their variables' values into datafiles
so they can later be restored. This is normally how user data is kept: each
user's object saves its contents into a datafile unique to that user (things
like status and encrypted password are stored this way).

8. Also because of the hierarchical filesystem, each "programmer" can be given
a home directory to store all of his or her own object definitions. A decent
structure can even allow users to directly FTP files into and out of the
mudlib so that LPC code can be edited locally instead of online. (Some FTP
daemons have been modified to recognize and authenticate mud users by reading
their encrypted passwords from the object datafiles, and setting their home
directories accordingly.)

9. One implementation of LP supports socket communication, talking directly to
another mud (so transfer of basic LPC datatypes is possible) or using either
UDP or TCP to talk to any Internet service. As an example, it is possible to
create an object which inherits a "telnet" object coded elsewhere in the
mudlib, and speak to any remote host using the telnet protocol.

10. When I say LP resembles a UNIX shell, I only mean that most LPmuds tend to
implement your basic UNIX commands into the mudlib so that you can manipulate
mudlib files in a manner you're probably already familiar with: cd, ls, more,
cp, mv, rm, etc. All of these are implemented in the mudlib using LPC. Of
course, you don't have to implement all or any of these, and could devise a
completely different way to give (or not give) users access to the files in
the mudlib. One possible approach is to make the filesystem itself the
virtual realm, so that the equivalent of 'cd' actually walks you through the
filesystem, sightseeing the files as you go by.

As I said, none of this makes LP necessarily better than MOO or any other
variety of MUD for any given purpose, but I do think it makes it one of the
most flexible.

Several general clients exist for talking to LPs, but creating a really good
one (perhaps with an X/graphic interface) really isn't much more difficult
than designing a protocol and implementing it into the mudlib. All messages
can be filtered through the mudlib before being dumped to the user, so it is
simply a matter of packaging the information into the protocol spoken by the
client. The ability is there; it just hasn't been brought to its fullest
potential yet. Actually, I was quite impressed to see a complete windowing
client implemented in LPC (!!) which ran on the server and worked with just
your basic telnet. A step in the right direction, but it would probably be
better to run the client locally (and write it in something besides an
interpreted language).

What other considerations do people find make MOOs a good environment as
opposed to LP or any other environment? Do any of the items I've listed seem
like a better alternative to the existing MOO environment?

Cheers,
- Rob