[Kedoeji]

I was just considering the development of muds and was woundering.....

What is the single most power langauge to create a mud?

What is the easyest?

Is custom code essentail in good design for a mud?

Finaly, do you think that it in the end really matter now days with high speed connection and processors what language you use as far as creating a mud goes could they all viturally get the job done with the same power and proficiency?

As of right now I want to code a mud in java, but like i said i didn't know so I might wait and buy a c+ book and see if i can get something started there.

[Jaregarde]

Well, the only language I know is Java, but, of course, all the Java books I've read say its the best programming language.   A little biased though, but the main reasons I know in favor of Java are...

a) Platform independency: Every operating system requires a different java compiler and java virtual machine, but both source code and compiled code will compile/run the same way on any machine (well, provided that the machine has a correspondingly up-to-date version of Java).

b) And (as you probably know) Java is object-oriented. The creators of Java took some of the good features of C and C++ and included those, and discarded others. One difference I know is that Java uses interfaces (with the implements keyword) in place of C++'s "confusing multiple inheritance feature" (I'm quoting from the Java Language Specification, as I myself have never used C++). Although Java does not include any "new and untested features" its theoretically a generally well-thought-out-language.

c) And Java uses Unicode, unlike C and C++, which use ASCII. Unicode is 16-bit, whereas ASCII is 8-bit. Unicode is pretty awesome because it has something like 65,536 different characters, including the alphabets for tons of languages, which enables non-English speaking people to write code in their native languages.

The only bad thing I know about Java is I've heard (somewhere on these forums) that Java-based engines take up a lot of RAM. I don't really know anything more about it though, but maybe someone else could say.

Well, I apologize if I said anything that is not true. I think this will turn out to be an interesting thread.

-Jaregarde

Edit: Ah! Rembered another thing, of course, applets! Applets are awesome for MUD clients because of Java's platform independency, so they can be run on any operating system.

[Murpe]

If you looking at a java codebase that already stable and available, take a look at CoffeeMUD. CoffeeMUD is nice if your looking for an 'out-of-the-box ready to go' experience with a web-based game editor.

If you looking for a good project to get you started in using Java, I would recommend the JavaMUD project based through SourceForge.net. JavaMUD project is more inline for those using Java in a more OOB setting, allowing for a load/unload code environment to be utilized (like that of LPMuds).

CoffeeMUD: http://coffeemud.zimmers.net
JavaMUD: http://sf.net/projects/javamud

-- M

[the_logos]

Originally Posted by (Jaregarde @ April 11 2005,22:15) a) Platform independency: Every operating system requires a different java compiler and java virtual machine, but both source code and compiled code will compile/run the same way on any machine (well, provided that the machine has a correspondingly up-to-date version of Java).

Java has upsides and downsides like any language. Platform independency, however, is a myth when it comes to Java. In theory it may be platform independent. In practice that assumes, as you say, that each machine has the same Java setup on it. Sadly, unless you want to limit yourself to Java 1.1 (which thorougly sucks), you're going to be doing a LOT of tinkering to actually make it work on the various hardware platform and browser combinations. Not that it wouldn't be worse in C++ or whatnot of course, but the Java spinmeisters would have you believe Java is truly write once, run anywhere.

--matt

[milliway]

From someone who has been using Java since the first alpha, Java is truly write once run anywhere. Nothing else comes close. You must be mentioning Java 1.1 due to the embedded Java-in-the-browser issue. Browsers only embed Java 1.1 (due to licensing I believe), so if you write something to use Java 1.4 features, it won't run under browsers that support only Java 1.1. That's a version portability issue, not a platform portability issue. Anyway, if you're writing a MUD it won't matter, since Java only runs on the server anyway, and you get to choose your OS/Java version as you wish.

Thedia
http://aelfengard.com

[the_logos]

Originally Posted by (milliway @ April 12 2005,02:31) From someone who has been using Java since the first alpha, Java is truly write once run anywhere. Nothing else comes close. You must be mentioning Java 1.1 due to the embedded Java-in-the-browser issue. Browsers only embed Java 1.1 (due to licensing I believe), so if you write something to use Java 1.4 features, it won't run under browsers that support only Java 1.1. That's a version portability issue, not a platform portability issue. Anyway, if you're writing a MUD it won't matter, since Java only runs on the server anyway, and you get to choose your OS/Java version as you wish. Thedia http://aelfengard.com

Yeah, it's good that way for server stuff, but for GUI stuff (such as for your MUD's client) it is a bit of the suck. We've been facing tons of issues there and I've been told by a lot of Bejeweled-type puzzle game developers that they have the same sorts of issues.

--matt

[Yui Unifex]

Originally Posted by (Nodeka @ foo) What is the single most power langauge to create a mud? What is the easyest?

These are not questions that anybody can answer for you. All we can give is preferences. That said, in general I find higher-level languages to be a better match for mud server development. My personal choice is C# at the moment, and I would most certainly choose it over Java.

Originally Posted by (Nodeka @ foo) Is custom code essentail in good design for a mud?

Good design of what? The game? The codebase? If the design of the current codebase prevents you from doing what you think is best, then sure it's essential.

Originally Posted by (Nodeka @ foo) Finaly, do you think that it in the end really matter now days with high speed connection and processors what language you use as far as creating a mud goes could they all viturally get the job done with the same power and proficiency?

No, it doesn't matter. Muds are in that class of applications that don't need to care about performance 95% of the time. And when there is a performance problem, the answer is usually to cache something. A simple, straight-forward design makes determining that something rather easy.

I recommend against writing in C++ in this day and age. Other languages do so much more for you, and when it comes to application development this can increase your productivity significantly.

[Tezcatlipoca]

Discover the power of LISP

[Gakusei]

Lisp weenie!

I've been trying out lisp for the last few days. It started off fun but it has gotten a bit frustrating getting some things to work lately due to the way its libraries work. I plan on releasing my telnet code as public domain once I've finished, so hopefully nobody will have to suffer as I did.

Having said that, I fully expect it to be very useful after this initial hurdle and recommend giving it a look-over at least. It is very well suited to the domain of text MUDs. The original zork series was written in its own dialect of lisp and that had better sentence parsing than most MUDs today.

[milliway]

Originally Posted by (the_logos @ April 12 2005,02:53) Yeah, it's good that way for server stuff, but for GUI stuff (such as for your MUD's client) it is a bit of the suck. We've been facing tons of issues there and I've been told by a lot of Bejeweled-type puzzle game developers that they have the same sorts of issues.

What's interesting is that my client *will* run, reliably, and predictably, on every platform supported by Sun Java 1.5, and probably just as well on any platform supported by a third-party v1.5 JVM, *and* it will look and perform identically everywhere it runs. It's hard to believe, but Sun has achieved this. Swing (for the GUI) and Java itself are 100% portable. If you're having trouble getting it to work, I'd be glad to help you with architecture decisions, or help with whatever you're getting stuck with, just drop me an email or catch me in-game. If you're using the Java 1.1 AWT trash that's built into some browsers, then it would be very non-portable for sure, perhaps that's what your Bejeweled-type developers are talking about. They are quite likely trying to design something that will work with all of these old browsers without having to download a multi-megabyte Java plugin.

Thedia
http://aelfengard.com
green@couchpotato.net

[Ogma]

Personally, I don't think it matters so much what language the server itself is written in, but how easy it is for your builders and creators to add unique areas to the mud and how easy it is to write intelligent mobs.

I far prefer an LP type MUD (LDMUD, MUDOS and variants). LPC is very flexible and things can be changed on the fly without recompiling the server.

[the_logos]

Originally Posted by (milliway @ April 12 2005,15:42) If you're using the Java 1.1 AWT trash that's built into some browsers, then it would be very non-portable for sure, perhaps that's what your Bejeweled-type developers are talking about. They are quite likely trying to design something that will work with all of these old browsers without having to download a multi-megabyte Java plugin.

Yep, that's the main issue. Java 1.1 is too prevalent to discard and a multi-megabyte download is unacceptable for our purposes. It's great to say that Java is portable between platforms, but the usefulness of that feature is incredibly diminished by the need for people to update their Java installs in order for it to actually work.

[Keriwena]

This may seem out in left field, but I think the easiest language for writing games is mushcode. It was meant to be newbie friendly, as many that use it have no interest in programming, but it's extremely powerful as it's meant to allow building a game on top of a stable server. It excels at list handling, and a full range of math functions can be enabled. If you want to try coordinate movement, get PennMUSH with the HSpace patch.

MUSHes have supported such diverse gaming systems as LARP, Ars Magica, White Wolf's WoD, and D20. They've sported worlds ranging from the comfort of the Shire to the bleak deserts of Arrakis. And a lot of dirty cities.

I suspect you could easily implement your ideas in mushcode and not have to deal with the internal aspects of the server, which could save you a lot of time.

[Kylotan]

Originally Posted by (Kedoeji @ April 11 2005,21:50) What is the single most power langauge to create a mud?

Python.

Originally Posted by What is the easyest?

Python.

Originally Posted by Is custom code essentail in good design for a mud?

Python. Er, I mean yes. If there's no custom code, then on one level you can claim there is no design. So it can't be good. But really, you're thinking about this the wrong way. Decide what you want from a MUD, then look at how you would have to go about providing those features. If all you want is a DIKU with 200 areas, then it would be foolish to demand that you code yourself a new codebase for it.

Originally Posted by Finaly, do you think that it in the end really matter now days with high speed connection and processors what language you use as far as creating a mud goes could they all viturally get the job done with the same power and proficiency?

I think that should be 2 sentences rather than 1... Connection speed has nothing to do with language choice. Instead, the choice should mainly be governed by what you're proficient at, since that's probably going to be the main factor in how long it takes and how well it is coded. Language performance is barely worth thinking about here.

Originally Posted by As of right now I want to code a mud in java, but like i said i didn't know so I might wait and buy a c+ book and see if i can get something started there.

Java is more than adequate for MUD server development. If that's what you're familiar with, go for it.

Originally Posted by (Keriwena @ April 12 2005,19:11) This may seem out in left field, but I think the easiest language for writing games is mushcode. It was meant to be newbie friendly....

Mushcode:

Originally Posted by &CMD.COMPCH TKCommands=$compch * *:@pemit %#=[setq(0,setdiff(cwho(%0),cwho(%1)))][setq(2,setdiff(cwho(%1),cwho(%0)))][setq(1,setinter(cwho(%0),cwho(%1)))]%r[center(ucstr(grab(v(lst.channels),%0*,&#124),25)][center(BOTH,25)][center(ucstr(grab(v(lst.channels),%1*,&#124),25)]%r[iter(lnum(1,max(words(%q0),words(%q1),words(%q2))) ,%r[center(name(elements(%q0,##)),25)][center(name(elements(%q1,##)),25)][center(name(elements(%q2,##)),25)])]%r &CMD.SORTEX TKCommands=$sortex *:@pemit %#=[switch(%0,*/*,[setq(0,before(%0,/))][setq(1,after(%0,/))],[setq(0,%0)][setq(1,*)])][setq(0,locate(%#,%q0,*))]%r[u(name-num-flags,%q0)][iter(sort(lattr(%q0/%q1)),%r[ansi(h,[ucstr(##)]] [get(%q0/##)])] &CMD.LCON_X TKCommands=$lcon *:@pemit %#=[switch(setr(0,locate(%#,%0,*)),*#-*,Invalid input.,%r[tagwrap(PRE,Contents of [u(u.name-num-flags,%q0)]:%r[iter(lcon(%q0),%r [ljust(left(name(##),38),40,.)][rjust(%b[flags(##)],28,.)][rjust(##,7)])]%r)])] &CMD.LCON TKCommands=$lcon:@pemit %#=%r[tagwrap(PRE,Contents of [u(u.name-num-flags,%l)]:%r[iter(lcon(%l),%r [ljust(left(name(##),38),40,.)][rjust(%b[flags(##)],28,.)][rjust(##,7)])]%r)] &CMD.ALIST_X TKCommands=$alist *:@pemit %#=[switch(%0,*/*,[setq(0,locate(%#,before(%0,/),*))][setq(1,after(%0,/))],[setq(0,locate(%#,%0,*))][setq(1,*?)])][iter(%q0,%r[u(u.name-num-flags,setr(3,locate(%#,##,*)))]%r[table(sort(lattr(%q3/%q1)),18,79)]%r)]

MooCode:

Originally Posted by @verb $math_utils:hexfromint tnt @program $math_utils:hexfromint ":hexfromint(INT) -- return a HEX number.."; numbers = {"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "A", "B", "C", "D", "E", "F"}; number = toint(args[1]); result = ""; while (number) result = tostr(numbers[number % 16 + 1], result); if (number < 16) number = 0; else number = number / 16; endif endwhile return result;

Mushcode is friendly to newbies only after about 10 hits of LSD. It's unreadable, write once garbage that makes this look attractive.

[Keriwena]

Tyche,

Do you really think some newbie is going to try to write a command that sorts and displays the members of two channels into 'this', 'that', and 'both'? I don't.

In MUSHcode, your MOOcode would be:

think tohex(#)

Of the five commands you posted MUSHcode for, why not show us how readable the channel compare command would be in MOOcode?


Keri

PS: You're in good company, to be sure - Lydia prefers it 'pretty printed', and encourages "liberal whitespace"; Ralph Melton once said, "MUSHcode is already within inches of being sheer raving gibberish; anything you can do to put another inch between your code and the abyss of blind gibbering chaos that it yearns to become is highly worthwhile.". I just always figured they used too much C to be objective.

That there doesn't happen to be a builtin is not the point. It isn't on most mushes either. Mushcode has no syntactic coherency. There are dozens of semantic rules and exceptions to learn and gotchas. It's not newbie friendly language.

Rather
"...abyss of blind gibbering chaos..."

yes exactly :-P

[Keriwena]

> That there doesn't happen to be a builtin is not the point.

No, it's not. The point is the two examples you posted are not comparable.

> There are dozens of semantic rules and exceptions to learn and gotchas.

And these are what make it newbie friendly. It conforms to what the clueless expect. An example would be the @lock code, which performs different functions on different object types. Not consistent behavior, and abhorrent to those formally trained, but simple for the newbie who just wants to lock his door and not have others carry him off while he's idle.

Basically, what you're saying is, "It's Greek to me!". Yet, the Greeks don't find Greek "unreadable". As I mentioned before, those with too much invested in formal languages, even those that write the C that makes mushcode work, tend to have difficulty with it, but those of us who are natives find it concise and powerful.

Simply put, you are applying standards that don't apply, and the result is a very personal and Chauvinist judgement.


Having said all that, however, the OP, being versed in Java, might well find MOOcode more attractive.