Asp Forum - Learning to build a MUD

Sean Dolbec

1/23/2008 2:03:00 AM

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/MU... 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 helbuns@gmail.com.
--
Posted via http://www.ruby-....

11 Answers

Bill Kelly

1/23/2008 2:37:00 AM

From: "Sean Dolbec" <helbuns@gmail.com>
>
> 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/MU... 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 helbuns@gmail.com.

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

Regards,

Bill

Kyle Schmitt

1/23/2008 8:36:00 PM

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

On Jan 22, 2008 8:36 PM, Bill Kelly <billk@cts.com> wrote:
>
> From: "Sean Dolbec" <helbuns@gmail.com>
>
> >
> > 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/MU... 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 helbuns@gmail.com.
>
> 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/eve...
>
>
> Regards,
>
> Bill
>
>
>
>

WikipedianKiba@gmail.com

1/23/2008 8:41:00 PM

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

On Jan 23, 2008 3:35 PM, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:

> 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
>
> On Jan 22, 2008 8:36 PM, Bill Kelly <billk@cts.com> wrote:
> >
> > From: "Sean Dolbec" <helbuns@gmail.com>
> >
> > >
> > > 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/MU... 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 helbuns@gmail.com.
> >
> > 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/eve...
> >
> >
> > Regards,
> >
> > Bill
> >
> >
> >
> >
>
>

Jason Roelofs

1/23/2008 8:50:00 PM

[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

On Jan 23, 2008 3:40 PM, Han Dao <wikipediankiba@gmail.com> wrote:

> I heard MUD is second to MMORPG in term of project scale difficulty.
>
> On Jan 23, 2008 3:35 PM, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:
>
> > 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
> >
> > On Jan 22, 2008 8:36 PM, Bill Kelly <billk@cts.com> wrote:
> > >
> > > From: "Sean Dolbec" <helbuns@gmail.com>
> > >
> > > >
> > > > 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/MU... 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 helbuns@gmail.com.
> > >
> > > 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/eve...
> > >
> > >
> > > Regards,
> > >
> > > Bill
> > >
> > >
> > >
> > >
> >
> >
>

Kyle Schmitt

1/23/2008 9:19:00 PM

On Jan 23, 2008 2:49 PM, Jason Roelofs <jameskilton@gmail.com> 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

Justin Collins

1/25/2008 5:49:00 AM

Kyle Schmitt wrote:
> 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
>
> On Jan 22, 2008 8:36 PM, Bill Kelly <billk@cts.com> wrote:
>
>> From: "Sean Dolbec" <helbuns@gmail.com>
>>
>>
>>> 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/MU... 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 helbuns@gmail.com.
>>>
>> 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/eve...
>>
>>
>> Regards,
>>
>> Bill
>>

On the other hand, it can be fairly simple:

http://redhanded.hobix.com/bits/mudIn15LinesO...

-Justin

Kyle Schmitt

1/25/2008 5:03:00 PM

Call me Mario

1-uped.

Daniel Berger

1/25/2008 6:53:00 PM

On Jan 22, 7:03=A0pm, Sean Dolbec <helb...@gmail.com> 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/MU...
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 helb...@gmail.com.

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

Regards,

Dan

fedzor

1/25/2008 9:26:00 PM

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

> On the other hand, it can be fairly simple:
>
> http://redhanded.hobix.com/bits/mudIn15LinesO...

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

1/26/2008 5:51:00 PM

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

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. ;)
--
Posted via http://www.ruby-....

comp.lang.ruby

Learning to build a MUD

Sean Dolbec

Bill Kelly

Kyle Schmitt

WikipedianKiba@gmail.com

Jason Roelofs

Kyle Schmitt

Justin Collins

Kyle Schmitt

Daniel Berger

fedzor

Marc Heiler

x Login to ForumsZone