The commercial MUD Avalon is written in FORTRAN I believe.

Interesting.
I guess when you have 4 - 8 megs of RAM every 'bit' counts. :smirk:
I just assumed that college kids would be more likely to have access to c++ than the household enthusiast.

These are good answers – clearly PHP is ugly. That's easy to see.

Still, what's surprising to me is that there a muds in Python, Java, Ruby, hell, the list goes on and on, but there is not a single running code base (for an actual MUD that has players) that is coded in PHP. There's got to be something wrong with it–but oh well, I'm sure I'll find out only after the bulk of the time has been wasted.

Also, PhudBase is not a codebase in PHP. It is basically an implementation of a SocketServer in PHP and it is dressed up in the demo to look like it has a MUD behind it, but in fact it's all for show. The "mobiles" that are walking around on the PhudBase Demo are literally moving via manual random number generation on every tick of the server and the hardcoded mobile consists of a name and a description and that's all.

Not only that, the actual linked thread is a promotion for the client exclusively as far as I was able to gather from reading it.

There is absolutely nothing wrong with it.

Not sure what you mean here, but it sounds like you're saying it's just a client and currently all of the resources are clientside. (I.e. no data from the server other than perhaps basic echo server.)

It is running a Telnet server. It's a very basic implementation of a MUD system. What exactly constitutes "MUD" to you? It's a text-based game that allows multiplayer interaction. The data might be hardcoded, and thus isn't exactly extendable, but it's still a MUD nevertheless.

To me, a mud involves more than the impression of entities. Your operative word "multiplayer interaction" is extremely generous, since that would include all chat rooms of any kind. I'm saying you can chat and you can walk around, but that's the extent of the possibilities, and nothing could be extended in any realistic way without serious pain, which in my opinion means it's not a "codebase" – so we're talking about two different things here, whether it's a mud and whether it's a codebase. I assert it might possibly be a mud by the loosest definition, but it is not a codebase for a mud. It is a codebase for a socket server, because that's all you could keep if you were to eventually make a MUD game on top of it.

Well then you have the beginnings of a PHP codebase. I would submit the reason it was never done up until now is because of the other reasons posted in this thread.

First, if you want to get a mud up and running, as was already said, and you want to use PHP, go for it. It is one of the slower languages out there, and I fully agree with the code elegance, but if you can easily maintain a setup, then +1 for you.

I've seen c commented on here a lot, and I think the main reason for people still choosing it is for the speed, (at least it was for me), that they can get out of it. Other languages can be fast (and faster in some instances), but I want the speed I can work out of c or c++ for more elaborate cpu and memory consuming systems.

The speed argument is only legitimate up to a point. A lot of high level languages let you embed C however you choose directly into scripts giving you the speed you need, when you actually need it. Over the next few years (and currently IMO) that extra memory usage is going to become less of a legitimate concern as well. Unless you're trying to run a mud from an a pocket device.

the memory isn't as much of an issue as it was a few years ago, but that doesn't mean we can toss it out the window for something memory consuming when it doesn't have to be.

Actually, it does. You're hanging your hat on an argument that is an extreme position. It's extreme because by that logic we should all be using the Turing complete language that gives us the most low level control. If the memory usage is negligible in most circumstances regardless of the language then it's not an issue. If your mud uses 1 meg of memory and mine uses 2 but the machine has 8000 it's hardly important. Even though yours is a whopping 2 times more memory efficient. I gave you an example where it would be an issue. i.e. running a mud on a device with barely any resources. From the memory standpoint, there's plenty of pocket devices with tons of memory. It's abundant. In those cases, even, you'd be looking more at the speed issue.

Seeing as MUDs have always been a hobbyist endeavor for me, the idea of creating a MUD in PHP (or something else relatively uncommon for the genre) seems perfectly acceptable. There are plenty of valid arguments for why PHP isn't a good choice if you're approaching the project with the goal of making the most elegant, streamlined, and blazing fast bleeding-edge game engine out there. That said, 99.9% of MUDs either aren't created with that mind set in the first place, or they are but for really no good reason since they might see a maximum of 20 people on at one time if they're lucky.

If it's fun for you and it makes you happy (and you're not working on a commercial project), write the thing in Lolcode if that's what it takes to entertain yourself.

I think we all know from a purely technical standpoint, PHP isn't the best solution, but that shouldn't discourage people from tinkering for poops and giggles.

Yes, but his musing was basically, "Why aren't you using PHP for this?"

I don't think anyone was trying to parade rain. :)

@Asylumius: agreed.

I think it's easy to get bogged down with the technical / architectural side of things so much,
that you can probably talk yourself out of using it. The 80/20 rule sort of comes into effect here:
Only about 20% of what makes PHP a bad choice may be vital in the completing of a working system,
as where the other 80% is trivial and or opinion based.

I suppose.

I got a somewhat typical argumentative, condescending coder/IT guy vibe when I first read the topic, but I was probably wrong.

Unless you have a dedicated server, the chances are your monthly hosting fee will be heavily based on your RAM and CPU usage. Perhaps the mud only uses 2MB to start out, but that amount will rapidly increase as the game introduces more content and gains in popularity.

Even developing in C++, I found my hosting costs rising every few months, and had to optimise parts of the mud on several occasions to keep the costs down. Eventually it worked out cheaper to move to a dedicated host.

But personally I would just recommend using whatever you feel most confident in, unless you have very specific needs that your preferred language deals with poorly.

Then your device (a small part of a server) requires that. In any event, you're also making the argument to use the lowest level Turing complete language. Cause, you know, it'd be cheaper if you could get the resource use even lower.

Also, these days– and in the coming days that I alluded to– the first generation mud hosting is probably going to die off or be left for people who need extreme mud specific customer support. Already you can get a linode or newbean account for cheap with abundant resources to run a mud from.

There's quite a bit of middle ground between "memory is not an issue" and "every byte is critical". There are plenty of potential features that can gobble up memory, and I've sacrificed efficiency for improved flexibility and robustness on a number of occasions, but not without some consideration.

However as I said before, I would just recommend using whatever language you feel most confident in.

If you're going for PHP you might as well code a MUD in TinTin++, it'd be an equally fun exercise in futility.