Member Discussions

Okay... Ive posted a couple of different times in this forum over the last couple of days, and have gotten some very good responses.

However, looking at what I want to change, I realize I want to change more then I want to leave the same, no matter what codebase. Heck, even ROM, which I thought I could fairly easily modify to get something that, while unoptimized, behaved how I wanted it to, has been giving me some rather inexplicable problems (if you happened to have read my post about that, Im sorry I havent responded to it).

So, obvious approach is to just make my own MUD. Have one minor problem, though. While I am good enough at coding (Ill be doing this in C++) to honestly both know what Im up against and think I can overcome it, I will have to learn some things... so thats why Im posting this.

Heres what I need to determine how to do - actually getting people to connect to the game, and getting the game to run (my real question is a bit more specific).

While Ive played around with C++ before, I have never worked with sockets... I dont know how to actually set the server up to accept connections on a port, and send information to specific connections. (Read: Im completly ignorant in this department) Could anyone suggest a good online place for me to learn? Id prefer to avoid actually spending the money for a book (college will make you say such things), I realize itll probably be inevitable.

This is going to sound horribly simplistic, but how do I set up the Main function? I know itll have to go into an nigh endless loop (with the condition for exiting being an admin command, etc)... but Im a bit fuzzy on what should be done. Let me take a guess: I check the incoming commands from each player, then execute them (as well as constantly update some things)?

Let me say that while someone is inevitably thinking at this point I should just give up and go with modifying a stock codebase, I know I can learn how to do it, and I do know how to do alot of the rest.

Also, what do you guys think about custom clients? I already know how Id set up the client aesthetically/functionally and I get the impression that Id know how to do the code (Visual C++) once I get my MUD actually functioning. Would it be a good idea to make this custom graphical client required to connect to my MUD (assuming that its well done)? Or would it be worth the trouble to instead make the MUD use normal clients, then later add in the custom client as an optional thing (essentially having two different formats for data to be sent the user), to avoid people being turned off by the idea of -having- to download something to play a MUD?

Id really appreciate your feedback - Im looking for both places I can teach myself, as well as any specific instructions you might be willing to share... and thanks for those of you whove responded to me in the past.

(Comment added by Sekket on Mon Aug 16 4:41:20 2004)

Notice - Ill be coding and running the MUD on a Windows computer.

Have a google for Beej's socket tutorial. Take a look at the microsoft documentation too.

The best way to learn is to look at existing examples. If you want to avoid all kinds of legal troubles in the future, only look at code with a forgiving licence. I recommend Yui Unifex's Aetas or Deus - there are some nice ideas there too. He has very kindly released his code without a licence.

I highly recommend an optional custom client. If you exclude telnet, you are missing out on a huge core of players and it will be a lot harder to get the MUD off the ground.

If players don't want to download an executable file, Java is a nice compromise.

Well, to be honest, if you don't know exactly what you're doing, try and experiment, but don't expect to make something usable (yourself) for quite some time. Take time in digesting how others have put their code together, and learn from their mistakes. There are also various guides online, but it'd probably help to use a portability library. Even if you're only programming for Windows, it'd be best not to get locked into the Windows environment. Like what if your MUD gets popular? You might be able to get inexpensive or even free UNIX (ie: Linux, FreeBSD) hosting, which usually scales better for MU* and website hosting. Even if you have a 'spare' Windows computer that's fast enough to run a large (or inefficient) MUD (lucky!), it'd still be better to make it multi-platform now, just in case.
Personally, I'm using C++ and a well-known runtime library to try and start another attempt at a custom MUD. A nice abstraction library can provide nice features like simple sockets and threading programming, or even nice features for making your program running with a usefully tight delay loop so it won't use all of your spare CPU cycles, and also won't delay unnecessarily that it causes lag. Sometimes using a library will make it easier, but usually the ideas are the same.
You need a main function to start it, it's what starts the whole program. That can call a loop, which can call other loops to do things. The main loop usually needs to repeat, along with all other loops, to poll for event info. If you're lucky enough to've found a library which can help you with it, you can make more of your loops event-based rather than polling to make it more efficient in some cases.
C++ isn't a language with built-in functions for things like that, though. C# might be an okay alternative if you don't want have to take certain things like multi-platform into consideration, especially since it has built-in functionality for making fairly efficient events, but overall C++ is going to be far faster for most purposes.

As far as custom clients go, making one in Visual C++ will also suffer for portability, and a lot of people who might be likely to check out your MUD would be reluctant to have to try and force a custom (Windows) client to run if it was the only way to get in. A lot of people prefer using their own clients, because they're just the way they like it and have everything setup there. Graphical clients tend not to be feasible at all unless the graphics are superb, and if the graphics are that good, typically you're pushing away a lot of players who simply don't want graphics, or who don't have the requirements for fancy graphics (and a custom client). Note, though, that a lot of clients support MXP, and some support MCP (don't forget to implement MCCP, though) for custom client-end functionality and all are now available through telnet specs, so can't really be considered completely non-standard. MUSHclient and zMUD (for Windows) support MXP, though as far as I've seen, only a few 'icky' clients support MCP, so it may not be a very good idea yet. Also, it's not strictly the idea of having to 'download' something to play a MUD, but that it probably won't be what they prefer to use in the first place. If you're going to be going for graphics and all, you might try programming an (awful, because almost every single one is awful :P No offense) MMORPG. If you're not familiar with basic MUD design principles, like having to change socket functions and how the main loop works, try (manually, by reading information about different things, not using patch!) adding Win32 (winsock) support to an existing MUD server as well as MCCP. It should give you an idea on what to do as well as what NOT to do with your own MUD, should you still decide that you want to write something from scratch (which is far harder than it sounds, even to a veteran like me :p).
One last note, though...try not to host it on your personal machine all the time, especially if it's Windows. You'll probably forget to backup properly (or make purely automated backups), it'll probably crash a little too often for players' likes (even if the newest, fastest Windows 2003 machine ever made), and you don't want your MUD being down or erased or hacked because you happened to leave a NetBIOS port exposed or because you applied a Microsoft patch that made a new vulnerability.

Hey, as someone who actually went through what you're doing right now(though I'm on to way more difficult troubles now), I know what you're dealing with. First thing you need to know-

this will take a long time. A VERY long time. My codebase is 35000 lines right now, starting from a usable core including things like emote and say(I wrote the core itself as well, althought my collaborator did the output buffering system - a masterfull piece of tangled pasta) which was about 1000 lines.

That said, Your code is going to look like this for every straight application(this is C btw, it will work for you though if you like C++ you will want to attach it appropriatly to a world object and have some fun with it. Anyway.):

int main(void)
{
int quit=0;
load_stuff();

while( quit != 1 )
{
get_input();
quit = parse_input();
parse_world();
}

do_clean_shutdown();
}

When you're starting a socket in FreeBSD sockets(which is what I use - it's highly portable through all unix/linux varients. I don't believe it works in windows though I may be mistaken) the process is essentially setting up a set of outgoing sockets, and then initiating them to listen for activity and then limiting the set to only those showing activity. From there it's simply a matter of reading the data. You'll most likely need to play with ioctl, accept, listen, read, and write, among other functions in your code.

Food for thought: My basic C mud took 1000 or so lines, though it had a fair number of features at that point. Similer work in perl took 17 lines.

Good luck :)
Kyros - rolf.yuss.org 5001, home of ages of eternity.

> When you're starting a socket in FreeBSD sockets(which is
> what I use - it's highly portable through all unix/linux
> varients. I don't believe it works in windows though I may
> be mistaken)

BSD sockets is pretty much the standard. Windows took BSD sockets so much of the API is identical. The only real differences are you must use send/recv instead of write/read, and you need to run the WSA_Init() and WSA_Cleanup() functions.

WSA_Init() and WSA_Cleanup()

Or WSAStartup() and WSACleanup(). :)

> C++ isn't a language with built-in functions for things like
> that, though. C# might be an okay alternative if you don't
> want have to take certain things like multi-platform into
> consideration, especially since it has built-in
> functionality for making fairly efficient events, but
> overall C++ is going to be far faster for most purposes.

In general, speed simply isn't a consideration for muds, so please don't make it a deciding factor. The Mono project brings a fair amount of portability to C# as well, and I would recommend it as a language when it and scripting language bridges mature a little more.

Paragraphs, man. They do a body good.

Woops, shows how much I code on that side of the fence =)

Speed isn't a consideration?

Well, timing is. The issue is how to devide tasks so every tick at least internally is the same period of time. Having your says() take longer one tick then another is unacceptable, ergo efficiency is fairly important. Besides that, unless you have a dedicated host it's only polite to have speed in mind.

Kyros, implementor of Ages of Eternity

> Speed isn't a consideration?

In general, yes. If there's a bottleneck then that sort of thing should be corrected, but that's the exception not the norm.

> Well, timing is. The issue is how to devide tasks so every
> tick at least internally is the same period of time.
> Having your says() take longer one tick then another is
> unacceptable, ergo efficiency is fairly important.

What if you don't use ticks? I understand what you mean, though, but that concept wasn't necessarily what my statement was referring to. One can have extremely slow tasks, such as user input, partitioned out with a proper state machine (or coroutines, or continuations) so that the rest of the system is plenty responsive. In that sense what matters is how it handles responsiveness, not how it handles efficiency. And indeed, even though it is a less efficient language, all of this is perfectly accessible in C# and scripting languages.

> Besides that, unless you have a dedicated host it's only
> polite to have speed in mind.

Sure! Which is why you should write your code for maintainability and flexibility first and efficiency second. That way you can easily swap out algorithms and strategies that greatly increase efficiency.

Well I've collected a bunch of links and put them up on
SocketsProgramming.

You'll definately want to read the Winsock FAQ. It has a lot of sample programs, facts and trivia, do's and donot's pertaining to winsock2.

Thanks for the responses.

Ill be sure to look through the links. But a thought occured to me, I dont need to reinvent the wheel. I know bare minimum MUD servers exist for download, but I dont think I added that link to favorites...

Ill still learn all the sockets buiseness when I get around to the whole custom client deal, but at start I have more important things to worry about.

And as far as servers go... I dont know what you people are talking about =P The computer Ill be using as a server usually stays up for weeks at a time... and thats with me using it for gaming while I have AIM running in the background. Generally with no problems. But when the only thing thats running on it is a MUD... unless I screw up horribly, I dont see how that could possibly be -that- severe of a system drain. I mean, if it wasnt for the fact I lucked out and got this box for free, Id still be using that one.

Server: Good.
Sockets: Work in progress.
Bare Bones MUD: Searching for.

(Comment added by Sekket on Tue Aug 17 2:37:58 2004)

I found a barebones MUD: http://www.daimi.au.dk/~jobo/socketmud/

It says its designed for compiling under linux. Any ideas on either what modifications need to be made to it so that itll compile under windows, or how to get Cygwin working properly (attempts in that area have failed laughably in the past)?

"30-35 Kbyte of pure code"

That's far too large. There's a page somewhere on a 16K MUD engine source competition ;-)

... ah here it is.
http://www.andreasen.org/16k.shtml

And (all?) those 16k MUDs have stripped down symbols to make the cutoff - making them not easy on the human eye.

Any ideas on ... how to get Cygwin working properly (attempts in that area have failed laughably in the past)?

Yes. click.. click.. whir.. click.. click.. click.. click... click... click... click.. ..whir... click

It's actually a seven click install (between the whirs there) instead of the typical one click install. Maybe that's where the problem is. :-P











(Comment added by Tyche on Tue Aug 17 11:14:53 2004)

My bad there's actually another final click or two at the end where it says "finished" click "okay" click "r u really ok we were concerned about you" click.

Maybe it's just my aversion to C# talking, but approaching a mud with it seems a little bit silly. On the other hand, so does hosting a mud on a windows machine to me. *shrugs* Too much linux, too little windows ;)

Anyway, you probably shouldn't take the approach of replacing things later; it tends to not get done. The approach of flexibility of code is a good one, I tend to code in modular groups myself that can be swapped out, or more importantly, have their algorithems used for other things with a minimum of change. The use of threads or a seperate demon or whatever for coprocessing defferent parts of the data is a pretty smart one actually. It was debated doing this with scripting events in my mud because of the CPU time needed. That said, it is again a mental patch - if you take the easy way out you're liable to allow things to take too long anyway, which can still happen in a world where you've got tasks seperated from vital timeing. Afterall, if those two didn't interact, you wouldn't have a mud worth playing. That said, you've given me food for thought :)

Kyros - implementor of Ages of Eternity

Ahaha that was hillarious. :|

No, seriously. I downloaded and installed Cygwin, thats not the problem, sorry if I wasnt clear. I also downloaded the patch utility someone else had pointed out, and tried using that, following all the directions exactly. However, it says it doesnt recognize the patch command when I actually enter it.

Also, what commands are neccessary to actually compile the source code? For references sake, I have Dev-C++ from bloodshed.net as well as Microsoft Visual C++ 6.0

As opposed to building a gay custom MUD?

(Didn't read the thread)

No, seriously. I downloaded and installed Cygwin, thats not the problem, sorry if I wasnt clear.

If you are using cygwin you'll also need to rerun setup and pick the patch utility package, the gcc compiler package, and the binutils package (which includes make and ld), and probably the crypt library package and zlib library packages. If your still missing something there's a nice package search utility on the cygwin website that will tell you which package contains the utility or file your looking for. Assuming of course you know you're missing something.

I also downloaded the patch utility someone else had pointed out, and tried using that, following all the directions exactly. However, it says it doesnt recognize the patch command when I actually enter it.

If you installed a windows patch progam and you got Command not recognized, it means the exec is not in your path. So you might want to learn the Windows Command shell as well, if you are going that route.

Also, what commands are neccessary to actually compile the source code? For references sake, I have Dev-C++ from bloodshed.net as well as Microsoft Visual C++ 6.0

There are changes you'd have to make to the source code to compile it using a 'native' windows compiler like VC++ and DevC++.


(Comment added by Tyche on Tue Aug 17 15:42:28 2004)

Curiously the Socketmud cygwin patch appears to disable the MCCP compression code and password encryption code even though libz and libcrypt are available on cygwin. *shrug*

> Maybe it's just my aversion to C# talking, but approaching a
> mud with it seems a little bit silly. *shrugs* Too much
> linux, too little windows ;)

I don't see any reason for this, except for the lack of mature scripting options. And the Mono project allows you to run C# code on Linux, in fact my own codebase has an editor written in C# that's crossplatform to whereever GTK# and Mono are ported.

> Anyway, you probably shouldn't take the approach of
> replacing things later; it tends to not get done.

Huh? You probably shouldn't take the approach of replacing things earlier, because you never know just what your bottlenecks will be. For the most part my only slowdown has come in the form of database access, but the solutions we've come up with to handle them are universal.

> The use of threads or a seperate demon or whatever for
> coprocessing defferent parts of the data is a pretty smart
> one actually.

But be wary of it. Martin Fowler writes in his book, "Patterns of Enterprise Application Architecture":

Concurrency is one of the most tricky aspects of software development. Whenever you have multiple processes or threads manipulating the same data, you run into concurrency problems. Just thinking about concurrency is hard since it's difficult to enumerate the possible scenarios that can get you into trouble. Whatever you do, there always seems to be something you miss. Furthermore, concurrency is hard to test for. We're great fans of a large body of automated tests acting as a foundation for software development, but it's hard to get tests to give us the security we need for concurrency problems.