[Mierza]

I'd like to build my own mud, I have a few resources (people inclined) available to help, aslong as I know what I need.

So.. where exactly do I start?

All replies much appreciated.

~Jade (aka Mierza)

[Emit]

well, there lots of work to do. if you want to start from scratch completely, here are a few steps that need to be accomplished, and the order i would probably try to do them in.

1) write the main function. At this point it doesn't really do anything but call the game loop.
2) write the game loop function. just have it an empty loop that you can add stuff to later. have it sleep for a tenth of a second or so every loop.
3) write all your socket code. This would be the most unfun part, probably. maybe borrow some socket code? it needs reading from sockets, writing to sockets, telnet negotiations, a struct for each connected socket, etc.
4) add fields to a the descriptor struct for a player name and password
5) write some functions to save and load a player (startup info probably name and password now, add details later).
6) write a nanny to login old characters and create new ones.
7) write a command interpreter.
8) write a who command and a chat command.

after this, things should progress smoothly.
you'll need an update handler, misc handling functions, a database of mobs/items and ways to save/load/modify it, rooms, information commands, object commands, move commands, and the rest should come as issues arise

most muds are grown like gardens rather than built like buildings, plant the first seeds and then add what you like

[Ogma]

So, Emit, if someone tells you they need a place to live, do you tell them how to build a house?

There are easier ways to start a mud, Jade.

First get your favorite flavour of free Un*X operating system and install it on an extra computer...it doesn't really need to be state of the art.

Next, download your favorite codebase Diku, Merc, Smaug, Rom, or ldmud (which I recommend). You can find all of these in source form on the net. If you get ldmud, you'll also need mudlib, also available on the net.

Next, learn to program in C or LPC and hack away.

Oh yeah, you'll also have to get some sort of persistant net connection.

[Orion Elder]

Just wanted to point out there are a lot more options than just the ones that Ogma mentioned.

Not mentioned, that I can think of off the top of my head, are (in alphabetical order):

AFKMud
Chronicles *
Circle
FUSS (Fixed Up SMAUG Source)
GodWars
ResortMUD and CalareyMUD(they're on there SOMEWHERE)

As mentioned, these are just a few off the top of my head. There are numerous codebase listings all over the net. More information about what exactly you're looking for would be helpful in pointing you to something that might suit your needs.

And, as Emit mentioned, there is always the option of building your own codebase from scratch.

* - Chronicles is my own derivative and is a pretty cleaned up version of SMAUG that has been trimmed down quite a bit, and had some new features added.

[Adelai]

Here's a random question. Which wuld you say is easiest to learn? Knowing some code (C mostly), but having been forewarned about the complexity of MUDs, is there one less... complex than the rest?

[Lodes]

Well knowing you really well Mierza, I thought i'd reply. (on a seperate note, i'll be contacting you on your current mud.)
Muds are indeed some complicated piece of code but after you have worked a lot with a codebase you get to know it quite well and understand what is needed.
Which codebase you choose really depends upon what you want it to already have, which features on that codebase do I want compared to that other codebase.
Now, answering your question maybe a bit more precisely. Any mu* is complex because first it is a server/client application and the current standards are relatively high on how a mud should be. I know you currently are an immortal on that mud I play with you, and I will be contacting you. I hope what I said made sense and maybe also helped some other people.
On another note, it does cost some money to run a mud and a lot of dedication. And now as an advice, with your changes, start with small things, you will learn a lot about different part of the code and then will be able to progress into making some bigger changes. Remember that some codebases are just ugly to look at but I am thankfull to the creators as they sure saved all of us a lot of time, and gave us inspiration to continue on.
-- edit - My first post on this board, really bad formatting which I hope I fixed.

[Mierza]

Ha, my gawd.. all you people know who I am and I've no idea who you are *fret*, leave your name so I can contact you both likewise?

Thanks for the replies guys, I guess I've a long way to go before my coding exp. moves from mIRC to Mu* bases.. ah well.

So.. if anyone wants to help create a newage/modern sci-fi game, with high RPG, with expectations of being totally awesome. (I'm fussy when it comes to games, either the best we can put together, or nothing at all.) Gimme an email to jade@shatteredequinox.com

~TY, Me

[Ogma]

Yes, Orion, I only mentioned the major MUD codebases. I also failed to mention MUCK (Glowmuck or fuzzball), Mush, Mux, MOO etc. so as not to confuse the issue.

Mierza,

If you want to do something significantly different than the standard medieval/fantasy setting, I'd recommend ldmud or MudOs (another one I failed to mention). LP style muds are much more flexible.

[Mierza]

I need to -learn- to code..

1. Is there anything similar to mIRC scripting that will suit my needs; or
2. Where can I learn? (Desired online, free, etc. Or tuition from an exp. friend'd help too.); or
3. Anyone wanna code?

[visko]

People always talk about how incredibly hard coding for a MUD is, but I think that's for job security more than anything

The fact is, this forum combined with a small amount of previous knowledge about C will normally get you to the point where you can start biting off some fairly hefty sections of code and redesigning them quickly and with a lot of success. MUDs are only hard because a lot of people aren't comfortable working within a very complexly-created program that was specifically designed to have everything cross-connected with everything else at the code level. And even a lot of advanced programmers who haven't had a lot of experience with structures will complain a lot, simply because these things, while not obscure or hard to understand, are just not things a lot of coders ever have to get into.

I started programming on MUDs, and learned about structures before I even knew what file I/O was. (I still have serious knowledge holes as far as file I/O goes, and I'm about to post a question related to that, btw. This place is great for answering q's, like I said ) Once you get a pretty good idea of how data flows through functions and is interpreted by each of them, and you get a decent enough picture of how structures work, how to access them, and how to use them to full potential, the rest of the code is gravy.

Also: if something looks like it would be hard to do, someone's probably already written the hard part for you. This is true at least in Rom, which I'm currently taking apart and putting back together; fread_string and fread_number have now made me very reverent towards the guys who started ROM out, heh.

MUDs are complex, sure, no one's arguing that. Hard? Not really. The thoughtfulness of most code bases in their design and understanding of newbie coders, combined with the support that you get from people who are very fervent about this type of gaming, namely this site and a few other less cool ones, are all you need to become a fairly creditable MUD programmer in not a lot of time. So don't worry; grab a linux account somewhere, grab a code base, and run with it.

-Visko

[Koryon]

Few things in here I'd like to comment on..

Originally Posted by 3) write all your socket code. This would be the most unfun part, probably. maybe borrow some socket code? it needs reading from sockets, writing to sockets, telnet negotiations, a struct for each connected socket, etc.

No way, I think this is definitly the best part. Well, in my opinion anyway, writing 3 lines of code and having a new fancy channel in your mud is nowhere near the acomplishment of writing a ton of low level code and seeing TCP comms as the result.

Originally Posted by 4) add fields to a the descriptor struct for a player name and password

I don't mean to pick on you Emit, but do you know what a descriptor really is? (Honestly, this isn't a flame, I want to know what you think one is.)

Originally Posted by ) write a nanny to login old characters and create new ones.

Again, sorry for picking on you

It's funny that you would write nanny, now, I'm not gonna harp because you have your favourite dikurivitive open or in your head as you write this. You see, nanny is just an oddly named function for a finite state machine. FSMs are pretty basic building blocks to, er, everything dynamic that aren't always learned by people who pick up programming on thier own. They're better taught in (digital) electronics, but they're still important, and that's exactly what nanny is. It determines where input should go (command interpreter, handling login status itself, text entry for note systems) based on previous inputs. For more information on FSMs you can look up books/webpages on discrete structures/fundamental logic.

Re: Already posted codebases

Two options not already presented are CVagrant and Glad. CVagrant is mine, and is quite minimalistic, It's basically what Emit described and not much else. Glad is KaVir's creation, and is a bit (well, more than a bit) more advanced than mine. CVagrant you can get from www.gryphonmud.com/~koryon/cvagrant.tar.gz and I'm sure you can get Glad from kavir.org, although I forget the exact link.

Originally Posted by Which wuld you say is easiest to learn?

This is a loaded question.. and doesn't have anything to do with complexity of muds, it's entirely on the programming style (When coding, you can focus on various things, time to run, time to program, maintainability, portability, reuseability), most is centered around "time to program", which means among other things it usually isn't documented well. Basically, CVagrant is a lot less complex then Glad, and Glad less complex then one of the popular codebases. But Glad (the "cleaned up 16k version") is by far the "easiest to learn" because of the amount of work KaVir put into commenting it.

But as for which of the popular codebases is the easiest? Take a potshot and pick one, cause somewhere around 50k lines of code you start to really just need to know the language to work your way around the code. (Or you're gonna learn, REAL fast)

As for learning to code, buy a book and read it, read it, and read it (and try the examples), download a mud codebase you at least know how it works from playing it, and look through it AS you read the book. If you just start with a mud codebase, you're eventually going to end up getting a book anyway, so skip the middle step. A good reference book is always a good investment anyway, I've used my perl book so much I'm going to need to replace it soon .

[Terloch]

Honestly, regardless of codebases out there, or any of OUR preferences, this is what I would recommend you do.

Take whatever code you are the most familiar PLAYING on and at least start with that. You know what things do, what messages are given, etc, and you can find that in the code and by reverse engineering it, you can start to figure out just what makes it all tick. Modify and change it, get comfortable with it, and THEN decide if you want to go with it, or something different...

[Mierza]

Well, this is coming a year too late, but I'd like to thank everyone that applied.

I've learned alot more about MU*'s, and hope to use this experience to put a developed concept that I have into play, to offer something new for everyone to look at.

I'll post some more about my concept in another thread somewhere, and eventually hope to find some talented coder/admin staff that are interested in developing something original.

Also a big thanks to Lodes for all his help outside this thread I know the MU* he's working with now is going to be a stunner for any fans of Star Wars.

Harr Harr..Yes. You will need to surround yourself with competent and dedicated staff members, or else the staff will slack off and the MUD will disappear. That will just result in a waste of resources.

[Mierza]

Raith? Are you my Raithy-raith from the place where Paia reigns?

Yup

[Blade]

I am trying to learn Python programming from scratch. I have no coding exp at all. I want to make a mud with Python programming. I found a site with a great tuitorial, but I have no idea what so ever how to even go about making a mud...Can any of you help me. I still have a ways to go anyway because I have to learn how to program first. Just out of curiosity, how long do you all think it will take me to learn how to program in Python. I am a somewhat fast learner and understand things pretty good? If any of you have sites, or any help suggestions at all, please message me or email me. Thanks!

[Ogma]

Not to be flippant or discouraging, but asking a question like this is like saying 'I'm just learning to drive a car, how long will it be before I can drive in the Indy 500?'

There is far more to learning to program than just learning the language. It is a unique way of thinking and solving problems. The programming language is just the tip of the iceberg. Once you know how to program, learning another language is a piece of cake.

Chosing Python as a first language is a good choice, it lends itself quite well to learning good habits and techniques. However, don't expect to be coding a mud in a couple weeks or months.

I wouldn't recommend coding a mud in Python though. It'd make a good embedded scripting language, but it doesn't lend itself to the fiddly bit bashing that communications protocols require. If I had to code a mud from scratch, I'd go with C++.

On the other hand, if I were building a mud, I wouldn't code it from scratch either. Chose a codebase and built off of that. For most of them you'd need C, but I think the best way to go is use LPMUD or LDMUD and code it in LPC.

[Lodes]

If I was writing a mud from scratch, and I had a deadline, I would write it in java.
I am writing my mud in C++ right now. I finished the underlying engine from which any mud could be based on. It was just a lot of copying from code that I had already written and pasted it into a library to link dynamically or statically to the main program.
I don't like using existing codebases because most of the time, I have to rewrite the entire code and the design often does not seem flexible and powerful enough. Heck, my code can only compile on Visual Studio .NET (2002-2003) or gcc/g++ 3.2 or higher, because I am using some of the latest techniques (they might be a few years old but they're the latest ) to provide that power.
There is a lot of power from coding your mud from scratch. Especially considering how much more you can do in 2-5 times less code than existing codebases.

I don't really know how python is suited for muds.. but I am sure you could code one in it. After all some people are coding muds in php (what the heck are they thinking?) - (acutally I know the answer to that, it's just for the fun of it ).
If you are starting out, it is highly recommended that you use an existing codebase. There are some pretty good ones out there. They might be a bit complex at first though if you're learning to code. I know most muds are derivatives of diku but I strongly think that diku has had its time, it's time people start basing their muds off some other more modern codebases or that a very cleaned up version of diku is released. So far all derivatives I have seen are as messy and have so much useless amount of code that it makes me want to puke. It might have been good back in the days, but wake up people!

Enough about my ranting.. I hope you guys got something out of it.

[Kylotan]

Originally Posted by (Ogma @ Oct. 17 2003,00:03) I wouldn't recommend coding a mud in Python though.  It'd make a good embedded scripting language, but it doesn't lend itself to the fiddly bit bashing that communications protocols require.

What are you talking about? Python is ideally suited for muds given that it comes with extensive networking and string-handling capabilities as part of the standard library. I'm intrigued to see what 'fiddly bit bashing' you think is required...

[Derk]

I have been working with python a lot lately, and quite honestly I hate its documentation. Its detailed.. but at the same time, grr.

I had an iterator that was returned to me from outside of python.. i couldn't find anyway to see how many items were in it... much less to reset it.. it might even be possible...

But you have to deal with junk like this

Shrug

[Kylotan]

The whole point is that iterators don't contain any items; they just give you an item at a time until it runs out... which it might never. It's better to think of an iterator as an interface to a series... the series could be finite or infinite, you just don't know. In your case, it sounds like you don't really want an iterator at all. Cos they're not much like C++ iterators.

[Derk]

Well, when using jython.. and receiving a java Enumeration such as the elements of a Hashtable... Jython automatically converts Enumerations to iterators.

What I did was put every item in the iterator into an array. Which gave me the count and what I really wanted anyway.

Since my engine is multithreaded.. if my python scripts asked for the number of players in the room, and then a list of the players... its possible those things could be different. :/

[Kylotan]

I've never used Jython and can't really see why it would return all that, but I assume there's a good reason.

If you only wanted the count, wouldn't one of these work?:
myHash.size()
len(myHash)

If not, a simple method of counting the number of elements that an iterator will yield to you is this:

len([x for x in myHash.elements() ])

Basically you make it into a list and grab its length.

[Derk]

Originally Posted by (Kylotan @ Oct. 29 2003,19:01) IIf you only wanted the count, wouldn't one of these work?: myHash.size() len(myHash) len([x for x in myHash.elements() ])

I need to know how many things are in the hashtable, like the players logged in the mud, so it displays pretty... like.. bob, susan, and jill.

Doing myHash.size() wouldn't work.. because because in the split second between asking for the size of the hashtable, and actually trying to print out what is in it the size could change.

If I count through the iterator, its no longer useful and I have to ask for another... which once again.. another thread could modify the hashtable while doing this

Throwing everything into an array works perfect for this.

Threaded programming brings up lots of issues. Sure, there are ways I can lock the hashtable down between asking for the size and elements... but the least locking the better. I try to assume that anything can be changed at any moment.. I only call synchronized functions when there is no way around it.

I hate how in traditional muds... you are seriously limited by the fact that if a command you execute takes too long it lags up the whole mud. Screw that.

[Kylotan]

And what do you do if another thread changes the hashtable while you are iterating through it?

[Derk]

Originally Posted by (Kylotan @ Oct. 30 2003,07:39) And what do you do if another thread changes the hashtable while you are iterating through it?

Hehe.. good thing you asked... I was under the impression the impression it wouldn't work this way...

[code] <cl 100.0% el 100.0%> set derk foo bar
foo->bar
<cl 100.0% el 100.0%> exec attributes = player.getAttributes()
<cl 100.0% el 100.0%> exec player.println(attributes.next())
admin
<cl 100.0% el 100.0%> set derk foo foobity
foo->foobity
<cl 100.0% el 100.0%> exec player.println(attributes.next())
Traceback (innermost last);
File "<string>", line 1, in ?
File
"scripts/exec.py", line 1, in ?
File "<string>", line 1, in
?
java.util.ConcurrentModificationException
at
java.util.Hashtable$Enumerator.next(Hashtable.java ;976)[/quote]


Which is interesting, because according to the java api... I am not using a java iterator, but a java enumeration.

Originally Posted by The Iterators returned by the iterator and listIterator methods of the Collections returned by all of Hashtable's "collection view methods" are fail-fast: if the Hashtable is structurally modified at any time after the Iterator is created, in any way except through the Iterator's own remove or add methods, the Iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the Iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future. The Enumerations returned by Hashtable's keys and values methods are not fail-fast.

[Mierza]

Myself and a group of trusted, talented individuals, started designing and creating the 'revolutionary' MUD that I was dreaming of.

Unfortunately, after the game engine was created, and the start of spec sheets and documentation, my lead coder had to leave the project.

Because I don't want to scrap the project (and let down other employees) and because my heart is so set on actually -completing- it, I'm going to have to ask for the help of you experienced coders out there.

So the question I have to ask is, what things will be required in the process of creating, from scratch, this MUD code.

Now, I know earlier on in this topic, people were kind enough to explain ways about creating a MUD from scratch, however there are other things I'm seeking answers to.

For one, we need everything original. Like our game engine, a main client that is realiable and can support alot of features, a java client that is not so heavy and can be accessed from pretty much anyone.

I need the main client to support graphics, kind of like a 'view screen'. Say, where in a normal MUD you'd type 'look at person' and it'd bring up text, I intend ours to also display their character portrait. Same with landscapes and such.

So what steps would be involved in creating a code base like this?

Also, what language/s would be best for such a project? Our former coder and his assistant were using RUBY, and using LUA as well for the ease of world builders.

As you can guess, I'm not very knowledgable when it comes to codeing of any sort.. but that's why I'm asking for some experienced input. Thanks.

[Kylotan]

Ok... you have to realise that you're really in the deep end here. Telling you what steps would be involved would be like telling you what steps are involved in making a car. Not only are you requiring a totally new server - maybe a year's dedicated work in itself - but you want a totally new client with features unseen in other clients,which again is quite a lot of work. I'm not sure you quite realise the scope of your demands, which to be fair is quite common among people who don't program. They often say "all I want is X... with Y added" and they don't realise that writing X from scratch took years in the first place and that Y isn't already in X because it's #### hard to code... but anyway.

As for the "What language is best?" question, I thought you said you already had a lot of code written... are you willing to give all that up and start again? Because that seems a bit wasteful. Anyway, if so I would always recommend Python as a coding language to a newbie, but Ruby is very similar. I am dubious about your old coder's decision to incorporate Lua however; that seems pointless given that I'm sure you could get the builders to write scripts in Ruby. Anyway, back to the point; I could write a basic MUD engine in Python in 2 months but I know what I'm doing. If you don't really know what you're doing it's likely to take you years no matter what language you use. Therefore generally the best language to use is 'whatever your coding team wants to use', and finding such a team becomes the priority.

[Mierza]

We did have code done, including the game engine. We also had a server, etc. But when our coder left, he kinda didn't leave either the code or the documentation for it.

It is a big task, and I never expected it not to be. Pretty much everyone on my team has been working to the original design of our clients and codebase based on the decisions I made with my former coder. His suggestions and advice are where I got my 'demands' from, and was made to believe that they could be accomplished with time and a bit of hard work. I mean, there's no way I'd have thought of wanting our own game engine, I barely know what one does. I think the reasoning for it was something like "We own it's copywrite, we can use it for further games, and creating it will give us more experience." The reasoning for the two clients was like, "We own the copywrite and can use it for further games. Fixing bugs and helping players with technical support will be alot easier. We can support our features more." (Features being audio, video sequences for quests, etc.) -Before critisizing the 'high goals' please remember that when this project was started, these were realistic, and we did have someone who knew the code side of things over and under.

Because I can't ask him anymore about what is involved in all that stuff, I decided to ask here. That way I can employ proficient new coders to do the job. -I don't want to start the coding from scratch. But I also don't want to waste the work of my game designers and some of the artist's work, because of this disruptment either.

If some things are a bit far ahead then I'd appreciate advice on what things. That way I can re-evaluate. As I said earlier, I'm no real coder.. and that's exactly why I'm asking.

I also have no idea about the choice of the RUBY/LUA thing. Most of the reasons for doing things were supposed to be included in the documentation that was also supposed to be provided. But we didn't get that far, ah well. As a team leader, I don't want to just let it fall apart because a member had to leave. Even if we don't have the code anymore, we still have hours and hours worth of designs and art that I don't want to waste.

If you have a better idea of a more realistic coding approach, I'd be glad to discuss our designs more indepth. Hopefully I find a coder willing to help first though and run it by them instead, cuz it's quite involving.