Zach Bartels wrote:
> Hi all,
>
> Apologies for the long post, but just want to introduce myself

Welcome.

> So far the plan is to fulfull a long time goal of making a game. Don't
> worry I'm not looking to make the next DOOM blockbuster or anything
> like that.  Right now I am focusing on Text driven games in
> particular.  I have a long history and love of MUD style games,  and
> their complexity / interactivity even as a "solo" player.   I'm NOT
> interested in  "Interactive Fiction" type games which are probably
> simple in comparisson, but I am interested in creating and interactive
> text adventure environment,  with the included intricacies and level
> of complex interactions that a typical MUD style game can provide,
> even to a single player.
>   

[snip]

Oh, boy. Okay. I've been down this road, myself, as have many others. 
Let me try to warn you now: turn back. It is actually easier to pick up 
a Ruby game library and write graphical games. Plus, they will look cooler.

But I know it is unlikely you will be dissuaded. So, to start off, I 
will point out one end of the spectrum: Jon Lambert's 15-line Ruby MUD:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/154208

This was expanded into TeensyMUD: 
http://sourcery.dyndns.org/wiki.cgi?TeensyMud
You may wish to take a look at it to get ideas.

You may also want to look at my attempt, which takes a pretty different 
approach: http://github.com/presidentbeef/kams
I could be wrong, but I think these are the two most complete Ruby MUD 
servers out there, and they are not that complete. You should steal as 
much as you can, though. You can always go back and re-implement things 
yourself.

There is also rocketmud, which is a very bare-bones implementation that 
you can use as a starting point: 
http://www.mudbytes.net/index.php?a=files&s=viewfile&fid=753

However, my guess is you won't want to start with any of those, because 
you are like many of us and want to do it all yourself, so I'll try to 
make some suggestions as best I can.

First, don't try to put everything into a structured database. It 
quickly becomes a mess as you change your design, adding and removing 
fields, realizing that different objects need different things and are 
related in weird ways. Keep everything in memory and then write it out 
to disk periodically. As I understand it, this is actually how most MUDs 
do it. Trying to keep everything in a database that is updated in 
realtime is just not practical.

On the other hand, don't try to be -too- flexible. I suggest going with 
a room-based system and having a coordinate system for your maps, 
probably with three dimensions. It will simplify things like showing 
in-game maps, path-finding, etc.

Next, do not be lured into the world of threaded programming. Use 
something like Eventmachine and try to have as much as possible happen 
in a single thread. You will have to deal with concurrency, but try to 
minimize it. Make everything event-based, with a single, global queue of 
events which are executed one at a time. I know this may sound slower 
than having all sorts of crazy threads executing in parallel, but this 
is how nearly all MUDs work, and it will save you many, many headaches.

Along with that, remember that laziness is often a programmer's best 
friend. If there is a library to do something, use it. Don't write your 
own networking code, use Eventmachine or Rev or something of that 
nature. Utilize whatever you can.

Lastly, don't worry about performance. You can do that when you've 
finished everything else.

I'm sure there is more I should caution you about, but that is what I 
can recall at the moment.

> If anyone knows of good general reading targetted at Text/MUD games in
> particular, and the various systems and design concepts, as well as
> how they are implemnented.  It would be very appreciated.
>   
You can look over these articles, I found them helpful/inspiring:
http://www.skotos.net/articles/BSTG.shtml

And hanging out at mudconnect.com will give you some opinionated ideas.

Good luck.

-Justin