I'm sure I evoked all kinds of involuntary vomiting with this title, since, by now you've probably guessed the topic I bring to you - choice of a programming language. However, let me quickly preface my textual mob beating by saying that I'm not a novice MUD developer looking to skirt the Search button here. I'm just looking to convert my (now) legacy C MUD project into a brank-spanking-new OO design, and obviously I want to move as far as possible away from C.

Well. I say that, but actually the leading contender right now is C#, unless anyone else steps up. Java is another serious consideration, because I really don't want to be constrained to a Windows environment (don't you dare bring up Mono or I'll…). Python, Ruby, Lua, et al. are also very intriguing, partly because I'm not very familiar with the languages, and also because simple, loosely-typed languages appeal to my RAD tendencies. I have some concerns with languages like these, though. Namely, performance. I know full well that on today's hardware, for most algorithms a typical MUD employs, the differences are likely minimal, but I'd hate to have to port the project again over something as silly as scalability.

So, that being said, does anyone have any experience with a moderately successful C#/Java/Python/Ruby/Lua (or other OO language) MUD? How did it perform for you? Did it scale well? How would you rate it versus other languages you've tried for MUD development?

You probably wouldn't have to. If you're doing something so computationally intensive that it kills your scripting language, you can just write that one part in C/C++/whatever and have the scripting language interface with it. This is very common; for example, Python has the numpy library available for doing things like fast vector/array math. (I.e., do the multiplications in C, not Python.)

To answer your other question, there is a well-known MUD codebase out there called CoffeeMUD written in Java. I have yet to see a MUD codebase written in Ruby/Python/Lua that wasn't basically a toy example, so knowing if it scales is difficult, however, Orrin's MUD is all in Python I believe and it's a fairly sizable world. Basically, if you're careful, it will scale. We use Python at work, and many people use scripting languages in many places for many purposes, so unless you're doing something really heavy, a scripting language should suffice.

BTW, if you don't really care about C# in particular, I would personally go with Java no questions asked, but I'll admit up front that that's mostly just personal preference and a vague sense of unease about the MS platform restriction (as you mentioned).

One thing to note about Orrin's mud is it's built with NakedMUD, so the core (networking, perhaps room movement and messaging) is in C. I'm not aware of any full-production mud in Python (or any other dynamic language for that matter). That said, Orrin's mud plays very smoothly.

In any case, I much prefer Python to Java for its relative simplicity, but no doubt a Java programmer will differ on that point once they expand my argument with Intellisense.


edit – I take back the first comment, Avenshar is pure Python. I've never seen that big of a player count there, but it runs well (using a fairly heavyweight custom Flash client)

Whoops yes, I forgot that the core was in C. That said, for the kind of development you're likely to be doing, most of it will be in the Python side of things. The "interesting" game logic (for whatever definition of "interesting") is probably mostly in Python.

These days I prefer Python over Java as well, however it depends on what I'm doing I guess. If performance actually mattered – and I mean actually mattered – and no, it doesn't actually matter for the vast majority of what MUDs do – then I might pick Java over Python, but then again I would probably pick C++ over Java if I really had to care that much about performance.

@David Haley:
I've read about Python's extensibility to C/C++, and I know Lua has the same capability, but to be perfectly honest, I generally dislike the idea. It just feels very hackish to me, like I didn't pick The Right Tool For The Job ™ in the first place. Or like I'm out-sourcing (a word that'll get you a swift punch in the nose in my profession).

As for C# versus Java, the only reason C# has my eye so far is because of its support for multiple inheritance. It's obviously not a requirement, but man does it make my class hierarchies more elegant.

Basically, you're confirming what I've been running into already. Which is to say, there's lots of proofs of concept out there (or "toy codebases" as you called them), but it's proving very difficult to find anyone running one of these in a production game environment (even small scale).

I've been writing a MUD in Ruby for a little over a year now. It's a 98% pure Ruby solution. As David suggests that other 2% is C.


It's not going to be noticable to your users. IMO it scales completely acceptably. In fact, most of the high level languages these days come with extensive profiling support so you can optimize code purely. It's going to take more resources than vs say C, but it's highly dependent upon your actual implementations and algorithms as to whether or not it's going to work for you. For me, it's been completely within the acceptable range of operation. Indeed, I think a typical mud hosting package would possibly support a mud in Ruby. If you're dealing with your own VM or dedicated machine then it's definitely no issue.


You're going to get about the same results from Python.


I wrote primarily in C for about 5 years and then primarily C++ for an additional 5. I wouldn't ever use either of these languages to write a new MUD. If all you are concerned with is resource conservation you would want one of these languages. I'd keep in mind that a long time ago when resources were more scarce people were writing muds in these languages. Now there are 100 times more resources and the demands for many muds remain the same. If you want to talk about the right tool for the job I don't think a pure C solution is the right tool in this instance.

I disagree with this quite a bit. You should change your slogan to The Right Tools for the Job.

In any event, you can optimize code for pure solutions by profiling it and tweaking it. It's easier to just solve bottlenecks with a few lines of C and clearly document it.

@Runter:
Is that why 2% of your game is in C? Did you profile your code and find significant bottlenecks which you had to replace with C implementations? Or was it for non-performance-related reasons?

The reason I ask is that I've found these kinds of suggestions all over the web, but I've yet to see confirmation of the sort "yes, I tried X and found it to be too slow, even with an efficient algorithm, so I out-sourced that chunk to C/C++." Most of the reasons I've come across seem to be along the lines of "because it was already written."

I found a few things in particular to be significantly too slow. A particular example was discussed on this very forum at one point was color code parsing. Here's some of that discussion: Here and even some real numbers. It was later determined that it was going to be a bottleneck for muds that use overmaps/wilderness maps/automaps or large colorful descriptions, etc etc. It probably would have still been fine—but even with the pure optimized solution you can see that the C solution beats it out handily.

The very core of my mud is also in C. At the lowest level the socket library, timers, etc are all C solutions. (Accessible through pure Ruby code.)

If I were designing a brand new codebase from scratch, I'd select a language which has strong support for string manipulation. The vast majority of your time will be spent creating, modifying, and copying strings around, so choosing a language which make you jump through hoops (like C/C++) makes no sense.

Native support for regular expressions is a plus, but it's also not a silver bullet. It can be tempting to use it when simpler operations would be more efficient.

Just my two cents: multiple inheritance is hardly a good reason to choose a language, most people consider it a Bad Thing.

I say this because you (the collective you) should really be favouring composition over inheritance.

Saying that, Java supports multiple interface implentation, which allows an, if convoluted, work around.

I didn't notice anyone actually attempt to write a better version.

Well, there were none posted but there were a lot of discussion at the time about the issue on IMC. What was posted was actually some of the fruit of that discussion. It's what led Kiasyn to posting the C benchmark. (Which was cheating. :))

I probably should have already said this but… C# = meh. I mean, if you already know the language or think you might like it or whatever… But meh.

Putting my clear unfair judgment aside, you said you liked that it supported multiple inheritance. From what I remember it does not.

edit: indeed delving into wikipedia seems to support my memory.

"Multiple inheritance is not supported, although a class can implement any number of interfaces. This was a design decision by the language's lead architect to avoid complication and simplify architectural requirements throughout CLI."

As others have said, this is a little odd. It would be like saying that you had to pick one vehicle for absolutely all of your transportation needs, and that it's unacceptable to occasionally use a plane instead of your car.

The fact of the matter is that your "job" is not some single atomic thing. It has many facets, each with its own complexities. If you were writing a graphical game in a dynamic language, it would be almost foolish to write the low-level graphics handling (pixel blitting, graphics card drivers, etc.) in your scripting language, for performance reasons. That doesn't mean that the entire project should be written in the language to implement the low-level graphics! Indeed, the project has many aspects and for some of them performance matters and for others it matters less.

And, well, you're out-sourcing to yourself, so it's not so bad. :wink:


My understanding was the same as Runter's, namely that C# supports multiple interfaces but not actual inheritance. Java supports multiple interfaces as well. Multiple implementation inheritance is indeed considered by many to be more trouble than it's worth, the most simple problem example being diamond inheritance. For whatever it's worth, a great deal of recent OOP languages simply don't support it; that should tell you something. :wink:

That's not quite true, Archons of Avenshar is a full production game environment in pure Python.

Also I'll add my 2 c. about the 100% vs. C core debate – Python itself runs some of its code in C when the optimization is worth it. So it's definitely not some grafted on thing.

I know Even Online uses a ton of Python and gets the following plug on the Python home page;

@Runter:
You're right. I work a lot with C++ (which does have it), and I just assumed C# would have it as well.

@flumpy:
It's only considered a Bad Thing in cases involving ambiguity (i.e. the diamond problem). Composition makes for ugly, overly-chained code IMHO. Interfaces allow inheritable behavior from multiple sources, but then you have to implement it in each subclass. If the implementation isn't supposed to change based on subclass (as is often the case), you're left either copy/pasting code :( or redesigning your beautiful hierarchy :(:(:(

@David Haley:
A more accurate version of your analogy would be you suggesting that I buy a Jeep (Python, or whatever) for off-roading (making the MUD), but swap out the engine (core) for a Hummer's (C/C++), because it's more powerful. Why not just use the Hummer to begin with? You'd have to put up with the Hummer being a little harder to service (harder to code/maintain), but if it can do everything the Jeep can do and then some, why bother creating some kind of Frankenstein vehicle?

Anyway, basically what I'm trying to find out from you guys, is if a Jeep is sufficiently powerful enough that I won't -need- to buy a Hummer or use a Hummer engine for acceptable performance. :) It seems to be the consensus that I wouldn't, but without any actual cited sources.

@Idealiad:
Thanks for the suggestion, but I checked it out earlier. I was the only player online :(

@Barm:
I don't think a commercial game like that is really an apples-to-apples comparison, because they can afford to throw hardware at problems. I'm less concerned with "can Python/whatever be used to make a speedy game" (which, it obviously can, as evidenced by EVE) than I am "can Python/whatever be used to make a speedy MUD running on a small-but-dedicated server with more than a small handful of players."

Sorry, no, that's really not an appropriate analogy. Your analogy assumes that one tool solves all problems. You assumed that the Hummer is inherently superior in all aspects. Well, yes, if you have a solution that is inherently superior in all aspects, then use it! What people here are telling you is that that is simply not the case here. C++ is better than Python/Lua/Ruby for writing certain kinds of things, like anything involving lots and lots of data processing. Dynamic languages tend to be easier to work with when performance isn't your #1 concern.

It's all about trade-offs. If something is inherently superior, then use it. If it's not, you have to make trade-offs.

Incidentally, you argue that a "Frankenstein monster" will necessarily be harder to code/maintain. But this isn't necessarily true either. Some code is simply harder to write in some languages than in others, and so the overall system will in fact be simpler if this doesn't happen.

Regardless, as others have pointed out, your view is in the minority when it comes to these languages' developers anyhow because all of these languages implement considerable chunks of their functionality in their C cores anyhow. :shrug: :smile:


Throwing hardware at problems only addresses so many issues. You can't endlessly throw hardware at something. The point was that it can be made to scale.

An additional note, just to be analogy happy and to drag out an old one: what you're trying to do is to find the perfect hammer for the world's nail. But your problem isn't just a nail. It's boards and screws and nails and levers and so forth. So there is no "hammer" that will be the "right tool" for the job. Instead of trying to contrive some tool, just pick the appropriate tools for the appropriate sub-problems.