[MUD-Dev] New to MUD Dev, need friendly advice!

Byron Ellacott bje at apnic.net
Wed Apr 30 10:42:14 New Zealand Standard Time 2003

On Thu, 2003-04-17 at 05:04, Lance Rotten wrote:

I've been out of town for a whiles, so this reply is a bit late ;)

>   1. Connections - What is the best method for accepting multiple
>   connections? Ive heard individual threads are an awful idea, and
>   that thread pools are a better idea. But I know there must be a
>   much better way to do this. Say I want to have 1000 people
>   connected at once ( I know this isnt likely to happen, but im
>   building this to gain knowledge and experience), what would be
>   the best method to handle that many connections via sockets?

As many people have said, it depends on your OS.  Under Linux (and
other systems conforming to the XPG4-UNIX standard or using GNU libc
5.4.28 or above) you would probably want to use the poll() syscall,
which is the highly optimized form of select mentioned.

I would strongly suggest that for a MUD you avoid threads, as they
will hinder you more than help you.  I say this because a MUD must
process things sequentially - you will run into big trouble if you
allow a character to start combat with another character while that
other character is partway through moving rooms, for example.

So what I recommend you do is buffer input and output to all
connections, and whenever a read event occurs, put it into the input
buffer, check for complete lines, and execute those complete
lines. When a write event occurs, send any buffered output to the
socket.  In this way, you will not block on IO, you will only ever
execute one command at a time, and you can use timeouts to do your
background tasks, all without having to worry about what other
threads are doing at the time.

>   2. Any advice for someone completely new to building a MUD
>   Engine would be great. Good tutorials, groups etc. I am using
>   this as a vehicle to upgrade my programming skills, so even the
>   most basic tutorials are great. I cant seem to find one good one
>   that encapsulates everything involved.

My main advice would be to make it as modular and extensible as you
can.  It'll make things alot easier in the future.

Byron Ellacott <bje at apnic.net>

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list