Learning to build a MUD

Hello i was recently introduced to ruby out of desire to make a mud and
to teach others how to while i learn.
http://helbuns.dvrdns.org/MUD/MUD.html i have understood enough to make
areas but i do not understand multithreading to make good combat. im
looking for a good mud guide, whys’ and pragmatic where aliitle rough
since i only want a mud. anyway anyone who could help i would really
appreciate it, please email me at [email protected].

From: “Sean D.” [email protected]

Hello i was recently introduced to ruby out of desire to make a mud and
to teach others how to while i learn.
http://helbuns.dvrdns.org/MUD/MUD.html i have understood enough to make
areas but i do not understand multithreading to make good combat. im
looking for a good mud guide, whys’ and pragmatic where aliitle rough
since i only want a mud. anyway anyone who could help i would really
appreciate it, please email me at [email protected].

Keep in mind, that if you are writing the MUD from scratch, even though
you “only want a mud” they are complex enough that you’ll have to learn
a lot about programming in general before you’re through. In other
words,
what I mean is, the statement, “whys’ and pragmatic where aliitle rough
since i only want a mud” doesn’t really make sense in the long run.

Anyway, I’d recommend looking into EventMachine[1] to handle the network
code. You can avoid multithreading that way (and likely get a
performance
boost as a bonus.)

[1] https://rubyforge.org/projects/eventmachine/

Regards,

Bill

Way way back when, after my first CS class (101, C++ programming), I
thought I’d make a mud. I literally spent months (of free time, not
solid, I was in school after all :wink: creating underlying structures,
and a few bizzare little maps.

  1. Writing a MUD is harder than writing a web app (even a really
    complicated one), harder then writing a good http server, possibly
    harder then writing a simple database.
  2. See #1, it really ain’t easy.
  3. Multi-threadding won’t get you much other than overhead. Use a
    ready-made library for handling events, or slice up time and handle
    the action in a frame by frame way: Make an event loop, check for
    input, process all the events, etc. The clients that are connected
    will happily wait (and not even notice), that your program was waiting
    on processing the input.

And good luck :slight_smile: it’s a fun project!
–Kyle

I heard MUD is second to MMORPG in term of project scale difficulty.

Well, take out the graphics of an modern-day MMORPG and you have a MUD.

Game development is rated in the same complexity, sometimes more,
usually
slightly less, than an operating system.

In short, it’s NOT the way to teach yourself programming. Start simple,
like
a blackjack clone, tetris (a lot harder than it looks), or any of the
old
arcade games. From there move into making something with simple
networking
(say poker, connect 4 or what have you).

The trick is giving yourself a project that you know is achievable in a
short enough time period through which you will learn the concepts
needed
for your final goal.

For the OP, definitely start out writing a single-player text game and
move
on from there. Start simple: display text about area, area has exits,
user
and move around (n s e w), and build from there.

As for multi-threaded programming, if you find yourself talking about it
non-challantly, “Yeah, and I’ll do this multi-threaded!”, then you have
no
idea what your getting into. Stay away from threads until you’ve got
single-threaded programming under your belt.

Hope that helps.

Jason

On Jan 24, 2008 5:18 AM, Kyle S. [email protected] wrote:

It’s a good idea actually. Make a zork/adventure-like game.
Heck, hard-code the map into it if it makes it easier for you to write it…
Then make it zork like (the zork series was an engine that could
load scenario/game file if I’m recalling correctly.) by turning it
into a seprate engine and scenario.

The adventure game description languages I’ve seen (such as that
created by David Betz) all seem to be heavily based on Lisp, and it
seems natural to do things that way. I don’t see it being that much
harder to make a DSL for adventure games in Ruby. At its heart an
adventure game is really a database with a lot of business logic
attached to it… hmm, not really that much different from a complex
web application. The hard part in making an adventure game is writing
the scenario. That takes talent quite apart from coding, and is more
in the domain of creative writing.

On Jan 23, 2008 2:49 PM, Jason R. [email protected] wrote:

For the OP, definitely start out writing a single-player text game and move
on from there. Start simple: display text about area, area has exits, user
and move around (n s e w), and build from there.

It’s a good idea actually. Make a zork/adventure-like game.
Heck, hard-code the map into it if it makes it easier for you to write
it…
Then make it zork like (the zork series was an engine that could
load scenario/game file if I’m recalling correctly.) by turning it
into a seprate engine and scenario.

–Kyle

Call me Mario

1-uped.

Kyle S. wrote:

ready-made library for handling events, or slice up time and handle

From: “Sean D.” [email protected]
Keep in mind, that if you are writing the MUD from scratch, even though

Regards,

Bill

On the other hand, it can be fairly simple:

http://redhanded.hobix.com/bits/mudIn15LinesOfRuby.html

-Justin

On Jan 25, 2008, at 12:49 AM, Justin C. wrote:

On the other hand, it can be fairly simple:

http://redhanded.hobix.com/bits/mudIn15LinesOfRuby.html

But that is very incomplete and neither maintainable or extensible…
but you already knew that.

Hack out your ideas first, and then make sure it works. Then, go back
and reorganize and rework things to be cleaner and faster.

On Jan 22, 7:03 pm, Sean D. [email protected] wrote:

Hello i was recently introduced to ruby out of desire to make a mud and
to teach others how to while i learn.http://helbuns.dvrdns.org/MUD/MUD.htmli have understood enough to make
areas but i do not understand multithreading to make good combat. im
looking for a good mud guide, whys’ and pragmatic where aliitle rough
since i only want a mud. anyway anyone who could help i would really
appreciate it, please email me at [email protected].

I’d talk to Michael G. or Martin Chase. Take a look at

Regards,

Dan

On Jan 26, 2008, at 12:50 PM, Marc H. wrote:

Also, maybe to support a minimal combat system (which I recommend you
implement LATER), you use a system thats simpler than D&D. D&D is
very mathematical, but you might have an easier time implementing
something like Fate.

http://en.wikipedia.org/wiki/FATE_(role-playing_game_system)

Awesome stuff :slight_smile:

I tried writing a MUD over the summer - all went well until school
started. Then coding time ran out. But this summer, I intend to
finish it, since I have learned a LOT since then and have thought
about it more.

Good luck

I’d talk to Michael G. or Martin Chase. Take a look at
http://www.faeriemud.org/

I know I won’t make many friends with the following, but I am now bold
and claim that FaerieMUD, albeit it has a superior concept (just look at
some older docs, or talk to them), is a dead project. Dead insofar that
the progress is gone.

There seems to be a lack of motivation within a short time frame. I am
not raising fingers at all. In 10 years it may very well be the best
existing MUD. :wink:

I have been following its progress when I started with ruby years ago,
and there were only marginal changes to the project as far as I can see.

You can try to convince me otherwise with solid arguments, but other
than that I will claim that this is a dead project. I do not really know
why, maybe they need a real dictator that kicks em.

About 15 lines of ruby… it surely is a fun project, to showcase what
may be possible, but it is not realistic to have a MUD in 15 lines of
code.

To do a proper MUD - which is on my todo list as well, and I am coding
on my own engine only in my free time and only sparingly - there are
different “concepts”, some I find hard, some I find easy.

Among the easy ones are of the LPC Model (everything is an object, i.e.
you pick up a sword object from your environment object, into your
inventory object).

Description, stats etc… is all done easily too. I very much like the
inventory model, where i just stuff worlds, planets, and humans into a
bag… :wink:

Combat code can actually become very very complex though. I dont so much
refer to the boring AD&D way to find out who wins, and the concept of XP
gaining through monster hacking pretty much just bores me - but
ultimately this is a trivial thing. Hit or not hit with one roll. If
hit, roll damage. Deduct damage from enemy hitpoints (and consider
damage reduction of enemy, but damage reduction is rather rare).

The more complex the combat code gets though, the more difficult
everything becomes.
I am still thinking of proper combat engine which affects not only
“physical rules” but also location implications (a hit on the arm may
lead to a drop_weapon() event, hit on the head may lead to temporary
blinding effect, or problems to stay on your legs, not to forget that
loss of blood may affect negatively too etc… etc…)

If you make sacrifices on the features (like AD&D with its super-simple
hit-or-no-hit model), then it becomes quite easy (and by the way, I
would demand of my combat engine to model different combat ways, so that
I can use it in reallife pen and paper roleplaying games just as well).

But there is more than combat to a MUD. All the LPC MUDs i know treat
rooms as objects wich some exits to other room (objects). This is a
simple and workable model, but I myself actually favour a slightly
different model, which focusses on “event locations” instead - although
my MUD engine would have to support both anyway etc… etc… yada yada a
lot of work… :frowning:

And let’s not forget client-server stuff. This is the most boring of
everything … :wink:

I think even if you do a very minimal, yet functioning MUD, it becomes
very complex and a lot of work.

I thus applaude everyone that tackles this task! Dont let the naysayers
stop you. :wink: