Member Discussions

I had considered building an engine from scratch, but I'm not sure that's the
direction I want to go now. I'd like to find a bare-bones OO codebase similar to
MOO. I'd actually use Lambda if it were disk-based, but...

Is anyone privy to information regarding tthe state of MOOP, other than the
info available on Sourceforge?

Also, if you were writing from scratch, would you use C/C++, Java, Python or
something else?

"I'd like to find a bare-bones OO codebase similar to MOO."

I'm not 100% sure what you mean by OO in this context, but
my understanding of the allure of MOO is that it is
extensible in-game by using the MOO's softcode.

If that's the advantage you're looking for, then an LPmud
might be to your advantage. There's a few types you
can try out on the LPmuds.net downloads page:

http://lpmuds.net/downloads.html

Naturally I'm biased toward Dead Souls, which is geared
to make learning LPC as painless as possible for newbies,
but this makes it not "barebones".

For a barebones LP lib you might try LPuni or Phantasmal
or the 2.4.5 that ocmes with LDmud.

For a rilly rilly rilly barebones lib, you might
try "Lil", but that would be really hardcore.

-Crat
http://lpmuds.net

Also, if you were writing from scratch, would you use C/C++, Java, Python or
something else?

That depends entirely on what you want your MUD to be. Off the bat, I should say that I'm biased towards Java... since it's what I chose for my codebase for a variety of reasons, and thus what I've been working in for a couple years.

Java:
That said, there aren't a ton of "barebones" Java MUDs out there, so you'd either have to go with something which was (more or less) fully fleshed out - Like CoffeeMUD - or write it entirely from scratch. I recommend Java, however, because 1) CoffeeMUD has some pretty cool features if you're going that route, 2) It's very easy to learn, if you're going the "from scratch" route. 3) The documentations is awesome, so it's easier to pick up without classes than the other two (in my opinion), 4) It's safe... meaning that you won't waste your time tracking down memory leaks (as with C), or figuring out exceptions where the stack trace originates from the language's core code (as with Python). Plus, being that safe means it will never crash, which is pretty cool.

C:
Then again, I actually got my start in C, which has the primary advantage of having a ton of codebases out there to run with -- thus preventing you from having to write a codebase "from scratch" just to write one at all. Secondly, it's pretty powerful, and thirdly, it's been around for the longest, which means there's (arguably) more help out there for C related stuff than either of the other two you mention. (Java has some pretty good forums and documentation (which I actually prefer), but there's no arguing with C's age). The obvious issue with C, however, is the fact that it allows memory leaks. But then, it's also faster than the other two languages, and uses up fewer resources (if that's important to you).

Python:
Then, there's Python. Don't get me wrong, I love python. I've integrated it into certain functionality in my game; I use it *all the time* at work, and I think it's very cool, overall. On top of all of that, it is *exceedingly* easy to learn, and without a doubt beats either C or Java in that field. However, it's a scripting language, and in my opinion should probably stay in the scripting realm. (Due to being a scripting language, it's slow, and doesn't support a few of the features a compiled language like C or Java can.) Plus, the documentation for it absolutely sucks. Check out python.org (not python.com, I might add........ that one's not work safe....), and there should be a reference to their documentation. Half the time they don't even tell you what a function returns, or how it's used... and pydoc is many times incomplete. Plus, then there's the tracebacks (or stack traces), which oftentimes get thrown without a complete error message, originating in a piece of code which isn't yours. When you encounter those, then you have to spend the next 15-30 minutes tracking down the proper use of the function throwing the exception, which almost never has anything to do with where the traceback originates. That's not fun. Plus, on top of it all, there are only a couple python muds out there (and I'm not sure how fleshed out they are, or vice versa).

Anyway, I don't think you really need a summary of all of that... (The clear choice, in my opinion, is quite obviously Java, followed by C/++).

However, your best bet, really, is to ignore my recommendation, decide on the core features you want, and then choose a language which is best suited for those features. That part is really up to you.

Anyway, back to bed to spend quality time with my food poisoning.

Best of Luck,
-Jess

When I say "OO" I mean I want a codebase where data and behavior are bound to objects. I don't want to add/modify features by adding/modifying code modules. Ideally, the codebase I adopt or develop will be written in Java or C++ with an embedded OO scripting language for coding of game mechanics and compilation on the fly -- something like ColdC, which I may actually end up using. If I do what I really want, though, I'll write a Java-based version of MOO with disk storage and more modern scripting features.

Thanks for the suggestions!

Java 6 introduced the ability to plug in and use a variety of scripting languages... scripting.dev.java.net describes it a bit.

I actually use it extensively in my codebase. Primarily, I plug in modules written in Jython (a python implementation written in Java, which runs exceedingly fast and is fully integrated).

That way, you can create an engine in Java (which is safe), and then extend it with Python (which is easy, and doesn't require touching the engine).

That sounds like what you're looking for.

Best of Luck,
-Jess

Hi there!

Just a couple points I wanted to make...

(I'll preface this by saying my custom codebase is in Python, and I'm a Python fanboy =)

I disagree about scripting languages not being suited for writing a MUD in its entirety. There are numerous options for speeding them up to more than acceptable speeds, so don't let fear of slow speeds keep you from using one. Remember that in most scripting languages, you can code a performance critical part in C/C++ if you really need to fairly easily (see Boost for Python, etc).

My favorite thing to point out is EVE Online, a MMO which holds the record for most players on at once on one server, that has both client (that won several Best Graphics awards) and server written in Stackless Python.

As someone who has written a moderately complex codebase in Python, I have yet to encounter any speed problems.

So, to answer your first question, I would (and did) choose Python. The stupidly rapid and ease of development in it is unmatched in any other language I have ever used. It has a massive builtin library, and one of the best networking libraries I have seen (Twisted, chat server in around 15 lines of code).

However, man_jess is right that there aren't really any developed Python/Ruby/Perl MUDs out there. So I can't really recommend any of those, mine included, for an actual-for-serious-project.

However, let me suggest NakedMUD. The core of it is C++, and you can extend it with Python. 95% of the stuff you want to code in, you can do in Python. Also, it is very stable, tested, and is nearly feature complete.

http://homepages.uc.edu/~hollisgf/nakedmud.html

Good luck with your project, and if you want some help with Python or scripting language related things, feel free to email me!

-Kuros

Jess: That sounds exactly like what I'm looking for, and the native inclusion of
Jython relieves me of the task of embedding. Excellent!

Kuros: I'm a big Python fan myself. I love the native network API as well as
Twisted, and the absolutely sick rapidity with which Python allows you to
develop. I love MOOP, a MOO written in Python that uses Python for scripting.

Thanks for the help!

(Comment added by Malifax1 on Thu Nov 29 8:43:45 2007)

Jess: That sounds exactly like what I'm looking for, and the native inclusion
of
Jython relieves me of the task of embedding. Excellent!

Kuros: I'm a big Python fan myself. I love the native network API as well as
Twisted, and the absolutely sick rapidity with which Python allows you to
develop. I love MOOP, a MOO written in Python that uses Python for
scripting.

I've looked at NakedMUD and had it up on my machine, but it's not exactly
what I'm looking for. I think I will either use ColdC or write something
similar in Java with Jython for scripting.

I do have a question about ColdC, though. From what I've seen, it looks like
a great platform with all the hard work done and a complete set of scripting
features tailored specifically for building MUDs. It's exceptionally stable.
Why haven't more people used it?

Thanks for the help!

Ooooh, MOOP! I looked at that a long time ago. I somehow missed the P in your first message...

Anyway! You are about the 3rd person I have ever heard mention ColdC, I think. Assuming they have solid product, I'd guess the reason they don't have more followers is lack of advertising. I haven't ever talked to anyone who uses it, and like I said, hardly anyone has mentioned it to me ever.

A question for you, if I may. Assuming you go with writing your own custom codebase, what is your reasoning for choosing Java with Jython, over something like pure Python? I'm not trying to convert you, but it seems to be an extra step, especially considering your background with Python.

Isn't it a lot more work to use Java and Jython to let you write a MUD in what is essentially Python with access to Java libraries? Especially when those libraries don't offer anything I can think of that is better than what Python does for a MUD?

-Kuros

"I somehow missed the P in your first message..."

I did the same thing. Weird.


"You are about the 3rd person I have ever heard mention ColdC, I think. Assuming they have solid product, I'd guess the reason they don't have more followers is lack of advertising. I haven't ever talked to anyone who uses it, and like I said, hardly anyone has mentioned it to me ever."

This one dude I knew really really really liked ColdC
in principle, and tried to make a go of it, but he
said he was foiled by its sparse and cryptic documentation.

I dunno if it really is so bad, since I never tried it
first-hand, but complex-product-with-weak-docs might
explain a slow rate of adoption.

-Crat
http://lpmuds.net

This one dude I knew really really really liked ColdC
in principle, and tried to make a go of it, but he
said he was foiled by its sparse and cryptic documentation.

The documentation is pretty sparse, but it is actually sufficient. The biggest thing missing from it really is any form of introductory tutorial for people who are completely new to coding. The docs do cover all the basics (data types, objects, methods) but tend to present it in a format that assumes the reader has programming experience in other languages.

When I started working with ColdC, I had a decent grasp of C and a very solid grasp of LPC. Those skills alone were enough to make the transition to ColdC largely painless.

There are also a couple of barebones cores available (SmallCore and MinimalCore) which can serve as useful how-tos for someone wanting to start a ColdC mud from scratch (there is actually less involved in bootstrapping a ColdC core that will accept connections than there is in bootstrapping an LPC mudlib that will).

But, yeah, more readily available documentation probably would add some appeal (as would a configuration script that doesn't need to be dicked with under most flavors of Linux).

something like ColdC, which I may actually end up using.

Good choice.

The docs do cover all the basics (data types, objects, methods) but tend to present it in a format that assumes the reader has programming experience in other languages.

Exactly.

Before I start diving into the packages I'm missing, can anyone tell me if ColdC
will even compile in BSD?

BsD? Of course, it's an operating system, not a compiler, so I see no reason why it'd have an issue with a programming language...

Heh. Not all languages work on all OSes. A language or program with a specialized purpose is more likely to not work on all OSes, since a library it utilizes may not be available on all platforms.

-Kuros

(Comment added by Kuros on Fri Nov 30 15:13:57 2007)

Additionally, ColdC is more a program with it's own domain specific language, rather than a different language (the OS still has to be able to compile C to run it. As well, all the packages ColdC utilizes must be available/compatible with BSD.)

Before I start diving into the packages I'm missing, can anyone tell me if ColdC will even compile in BSD?

It was developed on BSD.

(Comment added by Tyche on Fri Nov 30 15:37:08 2007)

The only requirements are either ndbm, dbm, gdbm or bdb. As mentioned the configuration script might have problems detecting and choosing which database to use if you have multiple ones or a user install location.

Thanks much for the info.

If anyone can lend a little help, I'd greatly appreciate it. I'm fairly new to UNIX.

I'm trying to compile the ColdC engine, Genesis, on FreeBSD running on my
MacPro. I have several database packages installed, including gdbm, ndbm
and db. I get the following when I try to make:

- System configuration
Getting hostname... devious-minds-Server.local
Checking system type... i386-apple-darwin9.0.0
Checking for gcc... gcc
Checking whether we are using GNU C... yes
Checking whether gcc accepts -g with -O... yes
Checking for makedepend... makedepend
Checking for perl... perl
Checking for lint... no
Checking for bison... bison -y
Checking byteorder... 1234
Checking for type sizes...
pointer.. 32 bits
char.. 8 bits
short int.. 16 bits
int.. 32 bits
long int.. 32 bits
long long.. 64 bits
float.. 32 bits
double.. 64 bits
long double.. 128 bits
Checking how to run the C preprocessor... gcc -E
Checking for ANSI C header files... yes
Checking for sys/wait.h that is POSIX.1 compatible... yes
Checking whether stat file-mode macros are broken... no
Checking whether time.h and sys/time.h may both be included... yes
Checking for <fcntl.h>... yes
Checking for <sys/file.h>... yes
Checking for <sys/time.h>... yes
Checking for <unistd.h>... yes
Checking for <vfork.h>... no
Checking for sys_siglist declaration in signal.h or unistd.h... yes
Checking for working const... yes
Checking for off_t... yes
Checking for pid_t... yes
Checking for size_t... yes
Checking return type of signal handlers... void
Checking whether struct tm is in <sys/time.h> or <time.h>... time.h
Checking for d_namlen in struct dirent... yes
Checking for tm_gmtoff in struct tm... yes
Checking for tm_zone in struct tm... yes
Checking for -lnsl... no
Checking for -lcrypt... no
Checking for -lm... yes
Checking for -lsocket... no
Checking for -lintl... no
Checking for vprintf()... yes
Checking for working vfork()... yes
Checking for strftime()... yes
Checking for gettimeofday()... yes
Checking for mkdir()... yes
Checking for select()... yes
Checking for socket()... yes
Checking for strcspn()... yes
Checking for strerror()... yes
Checking for getrusage()... yes
Checking for strstr()... yes
Checking for memmove()... yes
Checking for crypt()... yes
Checking for inet_aton()... yes
Checking for finite()... yes
Checking for rint()... yes

Checking for how to get db support
Checking for <gdbm-ndbm.h>... no
Checking for <db1/ndbm.h>... no
Checking for <ndbm.h>... yes
Checking for <db.h>... yes
Using... <db.h>
Checking to see if DB_DBM_HSEARCH needs to be defined... no
Checking for -lgdbm... no
Checking for -lgdbm_compat... no
Checking for -lndbm... no
Checking for -ldb... no
Unable to figure out what library to ling to get db support
make: *** [config] Error 1

Help?

Checking for how to get db support
Checking for <gdbm-ndbm.h>... no
Checking for <db1/ndbm.h>... no
Checking for <ndbm.h>... yes
Checking for <db.h>... yes
Using... <db.h>
Checking to see if DB_DBM_HSEARCH needs to be defined... no
Checking for -lgdbm... no
Checking for -lgdbm_compat... no
Checking for -lndbm... no
Checking for -ldb... no
Unable to figure out what library to ling to get db support
make: *** [config] Error 1

The configure script doesn't find the proper libs on some systems. Find the following lines:

if test -z "$db_lib_to_use"; then
   echo "      Unable to figure out what library to ling to get db support"
   exit 1
else
   LIBS="-l$db_lib_to_use $LIBS"
   echo "      Using... -l$db_lib_to_use" 1>&6
fi

Comment them out and insert the following:

echo "      Forcing the use of -ldb" 1>&6
LIBS="-ldb $LIBS"

This should allow the configure script to complete and allow make to run without any problems.

including gdbm, ndbm and db.

I'm assuming by db you mean bdb? or... the "ldb" that make seems to be looking for?

There should be a README with the distribution. In all likelihood, there will also be a setup script or a configuration file somewhere via which you will be able to specify either the path to the DB you wish to use (if you have it installed, but it cannot be found), or the specific DB you'd like to use, (if you have multiples installed and it doesn't know which you want....... though it appears that isn't the case). Worse case scenario, finding the readme or looking at the help page for the setup script will tell you which databases are supported, and perhaps give you links to pages which support those dbs.

I've never installed ColdC, but that's generally a good place to start with any package installation.

Best of Luck,
-Jess

(Comment added by mann_jess on Wed Dec 5 19:36:19 2007)

...Or make the changes the guy who is familiar with ColdC suggested... of course, he just *had to* sneak that post in before I was done writing mine.

Sneaky guy... Hmph.

Best of Luck,
-Jess

Thanks moocho. All set.

Ok, I feel really stupid. The configure completed successfully, but when I tried
to make I got a bunch of code errors, undeclared identifiers "datum" and
"key." It's like I'm missing a library or something. Could this be a result of
improperly set compiler flags?

It looks like this:

gcc -g -O -Iinclude -Imodules -c -o lookup.o lookup.c
lookup.c:29: error: syntax error before ‘objnum_key’
lookup.c:29: warning: data definition has no type or storage class
lookup.c:30: error: syntax error before ‘name_key’
lookup.c:30: warning: data definition has no type or storage class
lookup.c:31: error: syntax error before ‘offset_size_value’
lookup.c:31: warning: data definition has no type or storage class
lookup.c:32: error: syntax error before ‘value’
lookup.c:33: error: syntax error before ‘objnum_value’
lookup.c:33: warning: data definition has no type or storage class
lookup.c:38: error: syntax error before ‘*’ token
lookup.c:38: warning: data definition has no type or storage class
lookup.c: In function ‘lookup_open’:
lookup.c:51: warning: assignment makes pointer from integer without a cast
lookup.c:53: warning: assignment makes pointer from integer without a cast
lookup.c: In function ‘lookup_sync’:
lookup.c:74: warning: assignment makes pointer from integer without a cast
lookup.c: In function ‘lookup_retrieve_objnum’:
lookup.c:81: error: ‘datum’ undeclared (first use in this function)
lookup.c:81: error: (Each undeclared identifier is reported only once
lookup.c:81: error: for each function it appears in.)
lookup.c:81: error: syntax error before ‘key’
lookup.c:85: error: ‘key’ undeclared (first use in this function)
lookup.c:86: error: ‘value’ undeclared (first use in this function)
lookup.c: In function ‘lookup_store_objnum’:
lookup.c:96: error: ‘datum’ undeclared (first use in this function)
lookup.c:96: error: syntax error before ‘key’
lookup.c:99: error: ‘key’ undeclared (first use in this function)
lookup.c:100: error: ‘value’ undeclared (first use in this function)
lookup.c:101: error: ‘DBM_REPLACE’ undeclared (first use in this function)
lookup.c: In function ‘lookup_remove_objnum’:
lookup.c:111: error: ‘datum’ undeclared (first use in this function)
lookup.c:111: error: syntax error before ‘key’
lookup.c:115: error: ‘key’ undeclared (first use in this function)
lookup.c: In function ‘lookup_first_objnum’:
lookup.c:125: error: ‘datum’ undeclared (first use in this function)
lookup.c:125: error: syntax error before ‘key’
lookup.c:127: error: ‘key’ undeclared (first use in this function)

Etc.

That looks like there's an issue with either a header being missing, or not being compiled to that particular file... lookup.c? Don't know how to fix it, but that's the issue (I think).

-V

(Comment added by Vopisk on Thu Dec 6 13:53:13 2007)

Bleh, not being compiled BEFORE that particular file...

Order of inheritance and all that good crap...

Ok, I feel really stupid. The configure completed successfully, but when I tried
to make I got a bunch of code errors, undeclared identifiers "datum" and
"key." It's like I'm missing a library or something. Could this be a result of
improperly set compiler flags?

It looks like the header file (db.h) wasn't properly included (which would mean that the configure script lied to you when it said it was using db.h).

Go in to the the include subdirectory of src and take a look at config.h. There should be a line that reads:

#define DBM_H_FILE <db.h>

If you can't find that line, then the configure script fubared somewhere and didn't add it. If DBM_H_FILE is defined as something else (gdbm/ndbm.h for example), then you would need to change the lib you are using (-lgdbm if you are using the gdbm header file) or have the configure script force the use of db.h.

Yeh, the db.h file is included properly in the include header file, exactly as you
described..