------art_23152_21289372.1201121388980
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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/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 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/eventmachine/
> > >
> > >
> > > Regards,
> > >
> > > Bill
> > >
> > >
> > >
> > >
> >
> >
>

------art_23152_21289372.1201121388980--