11 Mar, 2011, bozimmerman wrote in the 81st comment:
Votes: 0
Cratylus said:
bozimmerman said:
Please sir, will you elaborate? Even if it's in generalities, I must know how CoffeeMud is deficient!

Very sincere thanks for any response, from Tyche, or anyone else for that matter.

- Bo Zimmerman


Tyche maintians a list of which codebases are most popular. I suspect that's what he's referring to.

That's what I hope anyway, since CM is great.

-Crat
http://lpmuds.net


Ah well. Either way, it did encourage me to go poking around for feature lists as I compile a todo list for the next version. I found a fantastic one on the Dawn of Time web site.

Still hoping for responses though. The more posts I see like "CoffeeMud sucks because it can't do X", the happier I will be. :)

- Bo
11 Mar, 2011, Tyche wrote in the 82nd comment:
Votes: 0
bozimmerman said:
Tyche said:
Runter said:
Oh, I thought it was some kind of vote or something.


Well in a sense it is.
Anyway, it would seem that the top languages for creating one's mud are C, Mushcode, LPC, MUF, and MOO in that order.
Muds written in Java like CoffeeMud haven't even surpassed AberMuds.


Please sir, will you elaborate? Even if it's in generalities, I must know how CoffeeMud is deficient!


While this thread is titled, Muds and Technology, is seemed to be more aptly titled, C Muds Considered Harmful. In any event, I pointed out the huge number of codebases available in many languages including more recently popularized languages like Java, Python, Ruby… to the OP. Then by way of counter discussion I also pointed out that statistics of live muds listed on TMC, support the popularity of other languages for programming muds, like LPC, MOO, Mushcode, etc.

I extracted that there were 11 CoffeeMuds and 14 AberMuds listed on TMC, observing even the most popular Java codebase, CoffeeMud, isn't as "popular" as AberMud yet. Now that's probably not true from a players perspective, as I'm pretty sure most of those AberMuds are what I would call "zombie muds", dead games containing no players but kept alive for years solely by their owners fondness for them.

I think generally most new games are spawned by players, and the tendency is to spawn a game just like the one they were playing except of course "better" because 1) they will be running it, not the asses that ran the game they left, 2) they'll add better features probably denied or ignored on the old game, and 3) they'll have a better or different theme. So switching gears from Diku to Coffee, Diku to LP, Mux to Diku, FamiliarMud to UnfamiliarMud goes against the grain. So the only deficiency of CoffeeMud I know of…. has less to do with the language, design or features and more that it just ain't the Diku, Mush or LP they and their buddies played before. :-)

If you're looking for recent comments on CoffeeMud, check out this thread. [link=post]54256[/post]
14 Mar, 2011, Oten wrote in the 83rd comment:
Votes: 0
just out of curiosity (i have no interest at present to use such a thing should it exist) has anyone written a MUD in drupal?
14 Mar, 2011, Tyche wrote in the 84th comment:
Votes: 0
Oten said:
just out of curiosity (i have no interest at present to use such a thing should it exist) has anyone written a MUD in drupal?


There are arcade style and turn based games, and there is some discussion on it here.
14 Mar, 2011, Vigud wrote in the 85th comment:
Votes: 0
I once thought about utilizing mongrel2 as a mud server, with its natural, built-in support for many languages. But Drupal? Why would you consider Drupal? :/
14 Mar, 2011, Ssolvarain wrote in the 86th comment:
Votes: 0
Still waiting on lolcode mud.
15 Mar, 2011, oenone wrote in the 87th comment:
Votes: 0
how about brainf*ck?
15 Mar, 2011, Vigud wrote in the 88th comment:
Votes: 0
oenone said:
how about brainf*ck?
Easier than Malbolge, so no.
26 Mar, 2011, Kanzel wrote in the 89th comment:
Votes: 0
Topic's already kind'a died off, but I'll throw my opinion into the hat. I don't believe it's that no one wants to try anything new, but people who are newer to operating a mud(such as myself) may feel more comfortable with something based on what they've been mucking around in up to that point. Change can be a little difficult for some people as well, and they might say to themselves "My old way works fine, why should I bother trying something new?", hindering progress. Then again, just because something is new doesn't mean it's any better either.

Personally I'm all for experimenting, but I lack the experience to determine which is best for which situation.
28 Mar, 2011, Nich wrote in the 90th comment:
Votes: 0
I personally have very little experience with mudding, so from my perspective as a developer it's the opposite problem. I'm inclined toward innovation, or at least not repeating past mistakes, and towards coding new systems from the ground up to fit with the MUD's requirements, rather then retrofitting an older code base, but I lack the knowledge of the conventions used in various muds. My worst fear is creating something innovative, and then never getting any players, since I need support from the vets to get it good and properly running (building, etc.), but they don't adopt it because they're used to the codebase they started playing.
28 Mar, 2011, quixadhal wrote in the 91st comment:
Votes: 0
You expect innovation from a community that bends over backwards to cling to the TELNET protocol, even though the population that uses it is slowly dying off due to old age, and the younger people don't generally even have access to it? Good luck with that. :)

Seriously though, the MUD developer community reminds me of the scene from the Holy Grail. If stubbornness was a stat, we'd all get 18/100's.

"When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England."
28 Mar, 2011, Runter wrote in the 92nd comment:
Votes: 0
Quix has been drinking the mudbytes koolaide.
29 Mar, 2011, KaVir wrote in the 93rd comment:
Votes: 0
quixadhal said:
You expect innovation from a community that bends over backwards to cling to the TELNET protocol, even though the population that uses it is slowly dying off due to old age, and the younger people don't generally even have access to it? Good luck with that. :)

The problem isn't with telnet, but with ignorance about its capabilities and hos....

You might as well blame lack of innovation on teenage pregnancy, hate crimes, Dungeons & Dragons, alien abductions, or rock and roll.
29 Mar, 2011, Runter wrote in the 94th comment:
Votes: 0
I do blame lack of innovation on D&D. I never want to see a game with magic missile ever again. ;)
29 Mar, 2011, David Haley wrote in the 95th comment:
Votes: 0
Telnet, teen pregnancies, and D&D are the future.
29 Mar, 2011, quixadhal wrote in the 96th comment:
Votes: 0
Sure you CAN do all kinds of interesting stuff with TELNET. You can also cut through a steel bar with a nail file, or dig a mile long tunnel with a spoon. That doesn't make them the right tools for the job.
29 Mar, 2011, plamzi wrote in the 97th comment:
Votes: 0
I agree with KaVir. To state the obvious, telnet is a protocol. Blaming it is like blaming the messenger.

You could drive a beautifully complex 3D world outshining Oblivion, all over telnet. But that requires a lot of us to shift our attention to clients instead of just servers. And yes, it also requires a whole lot of time and talent, possibly more than any single person can ever manage.

Divided we fall.
29 Mar, 2011, David Haley wrote in the 98th comment:
Votes: 0
plamzi said:
You could drive a beautifully complex 3D world outshining Oblivion, all over telnet. But that requires a lot of us to shift our attention to clients instead of just servers. And yes, it also requires a whole lot of time and talent, possibly more than any single person can ever manage.

It seems to me that you've sort of defeated your own argument here.

If I want to deliver a larger TV, I'm not exactly going to send it with a runner messenger, hmm? Of course different messengers are more or less appropriate. :wink: So, to use your metaphor, it can in fact make all kinds of sense to blame the messenger, if you are trying to send the wrong kind of message.
29 Mar, 2011, plamzi wrote in the 99th comment:
Votes: 0
David Haley said:
plamzi said:
You could drive a beautifully complex 3D world outshining Oblivion, all over telnet. But that requires a lot of us to shift our attention to clients instead of just servers. And yes, it also requires a whole lot of time and talent, possibly more than any single person can ever manage.

It seems to me that you've sort of defeated your own argument here.

If I want to deliver a larger TV, I'm not exactly going to send it with a runner messenger, hmm? Of course different messengers are more or less appropriate. :wink: So, to use your metaphor, it can in fact make all kinds of sense to blame the messenger, if you are trying to send the wrong kind of message.


I'm not sure what you mean, David, by extending my metaphor. Is it the case that telnet packages travel more slowly over the network? If so, then definitely we'll need to switch to a faster runner, someone who can make all those turns inside the optical cables without falling out of the racetrack entirely.

In my view (and I may just be woefully ignorant about all this), telnet is an outdated protocol just because, well, it's out of fashion. You can still encrypt and encode and send any data in any kind of format over it, including all the data to drive a 3D interface. Corrections welcome.
29 Mar, 2011, quixadhal wrote in the 100th comment:
Votes: 0
As I tried to show with my examples, it's not that you CAN'T do things with TELNET. Obviously you can. It's that doing so is overly complicated and opaque. The whole idea of using IAC sequences for negotiations and OOB data transfer was a great thing when we had serial communication at 9600 baud and squeezing every bit of information (pun intended) onto the wire in as compact a form as possible was essential.

However, that was 1980. These days, designing a friendly protocol that uses plain text structure and is therefore easy to debug, easy to update, and easy to write adapters for is, IMHO, a much better idea than fiddling with (unsigned char)255.

The biggest argument to staying with TELNET has always been that it's universal. Everyone has easy access to a TELNET client, right there on their machine. That was true in 1990. It is not true anymore. Modern versions of windows and even some linux distros, no longer ship with telnet clients by default, you have to add them in by hand. That means our potential audience will continue to shrink even further, as new people may not even have a way to connect to our antique servers.

But, I've made this argument several times. Those who believe in the way things are will never accept a new idea unless you can hand them a finished product that has both a well designed new protocol for client/server communication *AND* is an excellent game, since a bad game won't succeed, and nothing short of having 100 people online will convince them you aren't full of sh*t. :)
80.0/275