Learning to build a MUD

[Sean Dolbec]

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 (e-mail address removed).

 

[Bill Kelly]

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 (e-mail address removed).

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

 

[Kyle Schmitt]

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 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.
</rant>
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 it's a fun project!
--Kyle

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 (e-mail address removed).

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

 

[Han Dao]

[Note: parts of this message were removed to make it a legal post.]

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

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 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.
</rant>
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 it's a fun project!
--Kyle

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 (e-mail address removed).

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

 

[Jason Roelofs]

[Note: parts of this message were removed to make it a legal post.]

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

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

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 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.
</rant>
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 it's a fun project!
--Kyle

From: "Sean Dolbec" <[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 (e-mail address removed).

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

 

[Kyle Schmitt]

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

 

[Justin Collins]

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 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.
</rant>
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 it's a fun project!
--Kyle

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 (e-mail address removed).

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

On the other hand, it can be fairly simple:

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

-Justin

 

[Kyle Schmitt]

Call me Mario

1-uped.

 

[Daniel Berger]

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.htm=

li 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 (e-mail address removed).

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

Regards,

Dan

 

[fedzor]

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.

 

[Marc Heiler]

I'd talk to Michael Granger 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. ;-)

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...

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...

And let's not forget client-server stuff. This is the most boring of
everything ...

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.

 

[fedzor]

On Jan 26, 2008, at 12:50 PM, Marc Heiler wrote:
<snip>

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

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