From: Jörg W Mittag on
Seebs wrote:
> On 2010-01-15, Marnen Laibow-Koser <marnen(a)marnen.org> wrote:
>> Actually, the early text games (particularly the Infocom ones) often
>> have better parsers than most MUDs I've played.
> Which leads me to an observation which may not be popular around here:
>
> If you want to write text adventures, do it in Inform6.

Actually, "Use The Right Tool For The Job" is very much appreciated in
the Ruby community. If you look through the archives, you will find
that recommending languages *other* than Ruby for solving particular
problems, is pretty common. R, Erlang, OCaml, Tcl and Python are some
that are regularly mentioned.

"There's More Than One Way To Do It" is one of the pillars of The Ruby
Way, and that not only applies to different approaches *within* Ruby,
but also to different languages as well.

jwm
From: Phillip Gawlowski on
On 15.01.2010 06:15, J�rg W Mittag wrote:

> "There's More Than One Way To Do It" is one of the pillars of The Ruby
> Way, and that not only applies to different approaches *within* Ruby,
> but also to different languages as well.

In short: We are lazy pragmatists. ;)

--
Phillip Gawlowski

From: Jeff Peng on
在 2010-01-15五的 14:15 +0900,Jörg W Mittag写道:

>
> "There's More Than One Way To Do It" is one of the pillars of The Ruby
> Way,

This is the most famous motto from Perl.
But in Ruby it seems there are more ways to do the same thing than
Perl. :)

Jeff.



From: Bill Kelly on
Marnen Laibow-Koser wrote:
>
> Once you have 2 users -- or 1 user doing multiple simultaneous things --
> you have potential concurrency issues. SQLite is not a suitable
> database in that case. Fortunately, there are enough decent database
> abstraction layers for Ruby (ActiveRecord, Sequel, DataMapper...) that
> if you use one (and you probably should), switching DBs later on will
> not be a huge problem. Just be aware that you're likely to hit a wall
> with SQLite fairly soon.

On the other hand, a MUD may not require the sort of arbitrarily
generalized support for concurrency provided by postgresql.

I have an architecture at present which, although I am currently
using postgresql, it should work similarly well with SQLite.
(It's not a MUD, but I suspect a MUD could work similarly.)

Players connect to servers in their geographical region, and
each of those game servers in turn is in communication with a
single central master server. Ultimately there is a single ruby
process on the back-end providing database services.

So even though there are game servers on multiple continents,
ultimately there is one single-threaded ruby process running
EventMachine brokering all requests to the database.

I can get away with that because I don't need arbitrarily
granular concurrency at the database level. The single client
of the database is the "master game server", and the set of
different kinds of queries and updates it can make to the
database service is limited and known beforehand.


(Actually I do have one separate database services process
for handling long-running non-indexed administrative queries,
so I am taking advantage of postgres' concurrency abilities
there a bit -- but such queries aren't part of the game
proper, but are made occasionally by admins.)


Oh well, just some thoughts...


Regards,

Bill


From: Zach Bartels on
I've been away for a bit.. Sorry for the delayed response(s).. I've
been erm.. stuck in video encoding land for a while.

So its seems I've opened a can of worms wrt/Sqlite, hmm. But hey if
I'm wrong, then I'm on the wrong track, it's that simple :)
Sometimes you have to learn through your failures. I'm sorry if that
reads as arrogance to some of you, but I'm simply not afraid to fail.
Although I don't -like- to fail, I treat it as a learning experience.
I appreciate input from all perspectives, but at the same time there's
no need for some of it to be so condescending, "matter of fact"
either. I'm not here to do anything but discuss my ideas and benefit
from a little wisdom when I feel its been given. After all, it seems
I'm not the only one who believes concurrency probably isn't as big a
problem as its being made out to be. I likely won't be doing
multiplayer with my current project as it is. It's just hypothetical
banter, for the sake of it; as I said, any attempt at multiplayer
would be a start from a fresh code base / perspective as it is, only
taking over what useful bits I've learned up till then.


Fair point on the Inform recommendation, but it's more of a case of
me combining two aspirations into one task. So it's not a text game
solely for the sake of one, but also because I want to learn to
program in some kind of useful language. So why not do both at the
same time? I didn't mean to sound dispariging about early text
game's either, so sorry for that. I'm sure there are plenty of
complex parsers out there I could only begin to understand.

As far as what I've been exposed to, Simutronics' GemStone IV
(current incarnation of GemStone, I started when it was still GS III
) has pretty rich world and I'm guessing very good parser. I often
found myself frustrated that I couldn't use commands that seemed like
"common sense" on a lot of the free MUD's I've tried over the years,
as compared to what I was used to w/GemStone. It is a pay to play
MUD (one of the few I know of) that has been around for almost two
decades now. Although I fear its reaching the end due to poor
decisions on the companies part. But it's where a lot of my
inspiration for the kind of "single player environment" I'd like to
make, comes from.

On that subject. re: "Why'd you say you were making a MUD?", I don't
recall explicitly stating any such thing. Sorry if anyone read it
that way. I've always maintained it would be of a similar environment
wrt/ complexity and interactivity with the game objects. Hinting that
MP would be cool, but I had no real desire to make it a priority.

That's all I was really trying to say.


Re: Google wave. Never heard of it until I looked it up, sorry! :p
I'm not sure I would make for good conversation anyway. I'm also
terribly shy when it comes to actual verbal conversation.... so..
yeah. But I'm sure anyone in the discussion would be lightyears
ahead of me in terms of implementation - I do make for good
"brainstorming" of ideas though, no doubt. Part of the reason I
decided it's best to start learning is, I knew I'd never find any sane
coder who would let me dictate all these weird ideas and the ways
things should work, especially for free! ;) So until I get some
real free time to start development and get some retainable knowledge
under my belt, I don't think holding creativity chats is gonna help
me or anyone else any. At least for now I will have to just torture
you guys with my random questions about stuff I should know already.

I do appreciate everyones input. It does help.

-Zach