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.
--
Posted via http://www.ruby-forum.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
From: "Sean Dolbec" <helbuns@gmail.com>
I'd talk to Michael Granger or Martin Chase. Take a look at
Regards,
Dan
On Jan 22, 7:03 pm, 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/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 helb...@gmail.com.
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
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
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
--KyleOn 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
>
>
>
>
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
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
--KyleFrom: "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
On the other hand, it can be fairly simple:
http://redhanded.hobix.com/bits/mudIn15LinesOfRuby.html
-Justin
On Jan 22, 2008 8:36 PM, Bill Kelly <billk@cts.com> wrote:
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
> 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
> --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
> >
> >
> >
> >
>
>
Call me Mario
1-uped.
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 25, 2008, at 12:49 AM, Justin Collins wrote:
On the other hand, it can be fairly simple:
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
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.
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.
--
Posted via http://www.ruby-forum.com/\.
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 24, 2008 5:18 AM, Kyle Schmitt <kyleaschmitt@gmail.com> 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.
--
普通じゃないのが当然なら答える私は何ができる？
普通でも普通じゃなくて感じるまま感じることだけをするよ！
http://stormwyrm.blogspot.com
<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
On Jan 26, 2008, at 12:50 PM, Marc Heiler wrote: