Recommended Reading (also: Arrays/Hashes)

Hi all,

Apologies for the long post, but just want to introduce myself and
also make sure everyone understands where I am coming from, and that
I’m not some n00b on a fools errand. I fully appreciate the
complexities involved in the ultimate goal I have set for myself and
have no illusions that there will be long, difficult lessons,
scrapping and rewritting of lots of code, and the typical stuff that
happens during development.

(For Array/Hash question skip to bottom of post)

Just to give a little background about myself. I am one of those
people who always wanted to learn to program, but was never able to
teach themslves to a large degree. I’m 27 now, but I started my
love/hate relationship with C++ when I was about 15. Over the years
I’ve made various attempts but always ended up stumped at some point,
I think mostly because I was unable to see the big picture in terms of
setting goals for myself, etc. I probably tried to do too much at
once. C++ in particular I got hung up on math related stuff and
learning integers in general, for what reason I don’t know why. But
I think it was a matter of wanting to actually comprehend what I was
reading and being frustrated that I literally could not understand
things or grasp certain concepts.

A few months ago I renewed my efforts once again, this time starting
with Python. I structured my learning as I had when I originally
taught myself HTML when I was 13/14. That being, have a goal to do
something overall, but break my learning into parts I could complete
to get immediate results, and gain knowledge at the same time. I had
a lot of success and experienced the joys of cracking a tough problem
with a (in retrospect) simple solution. However I’m largely not keen
on certain things about Python that are largely, minor annoyances but
nevertheless, I decided to give Ruby a try. Although my progress has
been a bit slower (Python really was just so easy to use and write out
syntax, Ruby is similar and I like it, but a little more difficult
for me), I think I will like Ruby a lot once I get to know it better.

So far the plan is to fulfull a long time goal of making a game. Don’t
worry I’m not looking to make the next DOOM blockbuster or anything
like that. Right now I am focusing on Text driven games in
particular. I have a long history and love of MUD style games, and
their complexity / interactivity even as a “solo” player. I’m NOT
interested in “Interactive Fiction” type games which are probably
simple in comparisson, but I am interested in creating and interactive
text adventure environment, with the included intricacies and level
of complex interactions that a typical MUD style game can provide,
even to a single player.

I am using this goal as a means to teach myself to program in general,
and right now it looks like that project will be used to teach myself
Ruby. I don’t have any concerns about the speed of Ruby vs even
Python, or even a compiled language such as C/C++ etc. Although I
know text game systems are notoriously complex and do involve tons of
calculations per second (in the case of a MUD server hosting hundreds
of players) but I am confident that whatever I design, Ruby should be
able to handle, especially when run on fairly modern hardware.

I have ideas about how I want to design the game in general, and what
I want to be able to do with it, and stuff like that. I also know at
the very least, that the persistant data backbone will be one or more
integrated SQLite databases. However from a design concept point of
view I would appreciate some recommended reading specifically aimed at
MUDs and Text Games in general. Stuff that deals with how to
organize certain data overall and keep track of it as it changes. In
particular I need to get an idea of the architecture of these types of
systems I will be developing, such as a “World Map” type reference
that contains the present location of a piece of generated loot, or a
generated MOB / NPC / The Player, etc. I do have general ideas and
theories but I don’t want to waste hours designing this or any other
system only to find out it is a flawed design, hard to update and add
functionality to, etc.

If anyone knows of good general reading targetted at Text/MUD games in
particular, and the various systems and design concepts, as well as
how they are implemnented. It would be very appreciated.

Arrays/Hashes: This is a secondary question I have regarding
efficiency and speed… It is highly likely I would be using both of
these in a given scenario, to hold game data coming from a database or
generated/updated by real-time calculations. Are there any
guidelines for which is more appropriate for a given situation? For
some tasks I definitely like the idea of using Hashes to keep track of
certain data, but can see a use for Arrays in other situations where
using a Hash may mean redundant data or redudant references to data…
For examples storing character, room, and NPC data in a Hash would be
pretty easy to manage with Key/Value pairs that make it easier to
read and understand in the large scope of things. Whereas keeping a
“Map” object to reference each instance of a Hash, and changes in its
state would probably be more efficient and easier to read versus using
a Hash where the key and value might essentially be the same string.
(i.e a instance of Room, called “0xc4” would be easy to manage in an
array whereas in a hash the Key and Value would both be 0xc4 and thus
a little redundant). Hope that makes sense.

So in general, are there speed considerations to take into account for
using one over the other?

-Zach

On 13.01.2010 22:55, Zach B. wrote:

Hi all,

Apologies for the long post, but just want to introduce myself

Mission accomplished, I’d say. :slight_smile:

Welcome to Ruby.

Arrays/Hashes: This is a secondary question I have regarding
efficiency and speed… It is highly likely I would be using both of
these in a given scenario, to hold game data coming from a database or
generated/updated by real-time calculations. Are there any
guidelines for which is more appropriate for a given situation? For
some tasks I definitely like the idea of using Hashes to keep track of
certain data, but can see a use for Arrays in other situations where
using a Hash may mean redundant data or redudant references to data…

you pretty much understood the guidelines already: Use what fits your
situation. If you need key => value pairs, use a Hash. If you need an
Array of data, use the array.

If you read the Ruby Style Guide thread a few threads down, you’ll
notice it’s the same answer here that I gave there.

Basically, use what feels natural to the situation you are in.

So in general, are there speed considerations to take into account for
using one over the other?

Probably not any you have to worry about (i.e. measurable, but not
noticable). In any case, you trade off convenient access with a little
speed. Speed you’d lose if you implemented, say, Array#keys “by hand”.

Especially in Ruby 1.9.1, Hashes keep their ordering, so the look up of
key => value pairs would be rather fast, I guess (Ruby Gurus will
certainly correct me, since I’ll be wrong :P).

As general advice, I wouldn’t worry too much about speed just now, while
you are getting into the Ruby language. Once you know your way around,
you’ll be able to judge the trade offs involved in using option A over
option B. :slight_smile:

Zach B. wrote:

Hi all,

Apologies for the long post, but just want to introduce myself and
also make sure everyone understands where I am coming from, and that
I’m not some n00b on a fools errand. I fully appreciate the
complexities involved in the ultimate goal I have set for myself and
have no illusions that there will be long, difficult lessons,
scrapping and rewritting of lots of code, and the typical stuff that
happens during development.

Welcome to the Ruby community!

[…]

So far the plan is to fulfull a long time goal of making a game. Don’t
worry I’m not looking to make the next DOOM blockbuster or anything
like that. Right now I am focusing on Text driven games in
particular. I have a long history and love of MUD style games, and
their complexity / interactivity even as a “solo” player. I’m NOT
interested in “Interactive Fiction” type games which are probably
simple in comparisson, but I am interested in creating and interactive
text adventure environment, with the included intricacies and level
of complex interactions that a typical MUD style game can provide,
even to a single player.

I am using this goal as a means to teach myself to program in general,
and right now it looks like that project will be used to teach myself
Ruby.

Be prepared for a long learning period. This is a complex project on
which to learn to program. I’m not saying you can’t do it, but it will
be difficult.

Big tips that you may already know: do all development test-first,
probably with Cucumber and RSpec. And make sure you have decent version
control (I recommend Git).

I don’t have any concerns about the speed of Ruby vs even
Python, or even a compiled language such as C/C++ etc. Although I
know text game systems are notoriously complex and do involve tons of
calculations per second (in the case of a MUD server hosting hundreds
of players) but I am confident that whatever I design, Ruby should be
able to handle, especially when run on fairly modern hardware.

I have ideas about how I want to design the game in general, and what
I want to be able to do with it, and stuff like that. I also know at
the very least, that the persistant data backbone will be one or more
integrated SQLite databases.

Nonononono. SQLite can’t handle concurrency issues very well, and a
multi-user game will certainly run you into concurrency issues. I’d
recommend PostgreSQL.

How will users interact with this? Straight Telnet like vintage MUDs?
A Web browser? A custom client program? Depending on your answers, a
Web framework like Rails or Sinatra may be helpful.

However from a design concept point of
view I would appreciate some recommended reading specifically aimed at
MUDs and Text Games in general. Stuff that deals with how to
organize certain data overall and keep track of it as it changes. In
particular I need to get an idea of the architecture of these types of
systems I will be developing, such as a “World Map” type reference
that contains the present location of a piece of generated loot, or a
generated MOB / NPC / The Player, etc. I do have general ideas and
theories but I don’t want to waste hours designing this or any other
system only to find out it is a flawed design, hard to update and add
functionality to, etc.

I don’t know of any such references; others might. If I were going to
build such a game starting right now, I’d probably just design the DB as
well as I could, and refactor as necessary. (This is especially true if
you’re using Rails or some other environment that has good support for
DB migration.)

If anyone knows of good general reading targetted at Text/MUD games in
particular, and the various systems and design concepts, as well as
how they are implemnented. It would be very appreciated.

Arrays/Hashes: This is a secondary question I have regarding
efficiency and speed… It is highly likely I would be using both of
these in a given scenario, to hold game data coming from a database or
generated/updated by real-time calculations. Are there any
guidelines for which is more appropriate for a given situation?

Use Hashes when you want symbolic indices. Use Arrays when you want
numeric indices.

For
some tasks I definitely like the idea of using Hashes to keep track of
certain data, but can see a use for Arrays in other situations where
using a Hash may mean redundant data or redudant references to data…
For examples storing character, room, and NPC data in a Hash would be
pretty easy to manage with Key/Value pairs that make it easier to
read and understand in the large scope of things. Whereas keeping a
“Map” object to reference each instance of a Hash, and changes in its
state would probably be more efficient and easier to read versus using
a Hash where the key and value might essentially be the same string.
(i.e a instance of Room, called “0xc4” would be easy to manage in an
array whereas in a hash the Key and Value would both be 0xc4 and thus
a little redundant). Hope that makes sense.

It doesn’t really. And to the extent that it does, I think you’re
getting ahead of yourself and trying to prematurely optimize for a
problem you don’t yet have. Also, it sounds like you’re not really
thinking in terms of object-oriented design yet. Try to do that first.

So in general, are there speed considerations to take into account for
using one over the other?

Speed should not be a concern for you at this stage.

-Zach

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

2010/1/13 Zach B. [email protected]:

Welcome to the wonderful world of Ruby!

I have ideas about how I want to design the game in general, and what
I want to be able to do with it, and stuff like that. I also know at
the very least, that the persistant data backbone will be one or more
integrated SQLite databases.

Just one caveat: if you are really going to want to scale to several
hundred concurrent players you should make sure that SQLite can handle
that level of concurrency. It may be that a solution with a separate
server process is more efficient, especially if you have multiple Ruby
processes accessing the database concurrently. In that case you
probably rather want to look at MySQL or PostgreSQL. I mention this
here because this influences overall design as opposed to the question
whether you use a Hash or an Array for storing one particular set of
data. You should worry about design early and about details later.

read and understand in the large scope of things. Whereas keeping a
“Map” object to reference each instance of a Hash, and changes in its
state would probably be more efficient and easier to read versus using
a Hash where the key and value might essentially be the same string.
(i.e a instance of Room, called “0xc4” would be easy to manage in an
array whereas in a hash the Key and Value would both be 0xc4 and thus
a little redundant). Hope that makes sense.

So in general, are there speed considerations to take into account for
using one over the other?

I fully support what Marnen said. Note that for pure data containers
(and sometimes even more) Struct is a very convenient and powerful
tool, e.g.

Character = Struct.new :name, :password, :points, :lives, :current_room
player_1 = Character.new “Josh”, “oa8234sdf7”, 0, 5
puts “We have character #{player_1.name} now.”

Kind regards

robert

Zach B. wrote:

Hi all,

Apologies for the long post, but just want to introduce myself

Welcome.

[snip]

Oh, boy. Okay. I’ve been down this road, myself, as have many others.
Let me try to warn you now: turn back. It is actually easier to pick up
a Ruby game library and write graphical games. Plus, they will look
cooler.

But I know it is unlikely you will be dissuaded. So, to start off, I
will point out one end of the spectrum: Jon L.'s 15-line Ruby MUD:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/154208

This was expanded into TeensyMUD:
http://sourcery.dyndns.org/wiki.cgi?TeensyMud
You may wish to take a look at it to get ideas.

You may also want to look at my attempt, which takes a pretty different
approach: http://github.com/presidentbeef/kams
I could be wrong, but I think these are the two most complete Ruby MUD
servers out there, and they are not that complete. You should steal as
much as you can, though. You can always go back and re-implement things
yourself.

There is also rocketmud, which is a very bare-bones implementation that
you can use as a starting point:
http://www.mudbytes.net/index.php?a=files&s=viewfile&fid=753

However, my guess is you won’t want to start with any of those, because
you are like many of us and want to do it all yourself, so I’ll try to
make some suggestions as best I can.

First, don’t try to put everything into a structured database. It
quickly becomes a mess as you change your design, adding and removing
fields, realizing that different objects need different things and are
related in weird ways. Keep everything in memory and then write it out
to disk periodically. As I understand it, this is actually how most MUDs
do it. Trying to keep everything in a database that is updated in
realtime is just not practical.

On the other hand, don’t try to be -too- flexible. I suggest going with
a room-based system and having a coordinate system for your maps,
probably with three dimensions. It will simplify things like showing
in-game maps, path-finding, etc.

Next, do not be lured into the world of threaded programming. Use
something like Eventmachine and try to have as much as possible happen
in a single thread. You will have to deal with concurrency, but try to
minimize it. Make everything event-based, with a single, global queue of
events which are executed one at a time. I know this may sound slower
than having all sorts of crazy threads executing in parallel, but this
is how nearly all MUDs work, and it will save you many, many headaches.

Along with that, remember that laziness is often a programmer’s best
friend. If there is a library to do something, use it. Don’t write your
own networking code, use Eventmachine or Rev or something of that
nature. Utilize whatever you can.

Lastly, don’t worry about performance. You can do that when you’ve
finished everything else.

I’m sure there is more I should caution you about, but that is what I
can recall at the moment.

If anyone knows of good general reading targetted at Text/MUD games in
particular, and the various systems and design concepts, as well as
how they are implemnented. It would be very appreciated.

You can look over these articles, I found them helpful/inspiring:
http://www.skotos.net/articles/BSTG.shtml

And hanging out at mudconnect.com will give you some opinionated ideas.

Good luck.

-Justin

Zach B. wrote:

If anyone knows of good general reading targetted at Text/MUD games in
particular, and the various systems and design concepts, as well as
how they are implemnented. It would be very appreciated.

I don’t know about games in general but a very successful OO pattern you
may consider is MVC, particularly the modeling aspect.

You might also consider Rails’ modeling API. The Rails team have
recently announced an abstraction for modeling called ActiveModel. It
gives regular objects all the goodness of ActiveRecord model objects.

http://yehudakatz.com/2010/01/10/activemodel-make-any-ruby-object-feel-like-activerecord/

Jose

Jose Hales-Garcia
UCLA Department of Statistics
[email protected]

Zach B. wrote:

Also I admit I have 0 knowledge of unit testing, version control,
etc. So I probably do need some education in those areas.

It’s like everything else - once you get past the learning curve, you’ll
be fine. Prepare to stumble though. Several times. :slight_smile:

I so appreciate the links to those MUD projects, as I didn’t know we
had that many in the community. Although I am loathe to “steal” as it
were, from other projects I definitely will want to look at them for
ideas on how I want to approach the same obstacles.

It’s not stealing if it’s open source :wink: Just credit them!

So I am definitely going to have to learn event management.
I totally understand the mountain I have just made for myself but I
feel pretty committed to it and I know it will take me a LONG time to
do this. So I’m ready for the challenge. (I hope)

-Zach

Sounds like a lot of fun. Let me know if you want help on any of this, I
could probably learn a lot from this too (and maybe teach you some
stuff). I can be reached there: aldric at trevoke dot net
Or if googlewave is your thing, trevoke at googlewave dot com :slight_smile:
I have found that googlewave is actually pretty nice for lengthy
discussions and planning.

On Thu, Jan 14, 2010 at 6:16 PM, Aldric G. [email protected]
wrote:

were, from other projects I definitely will want to look at them for
-Zach

Sounds like a lot of fun. Let me know if you want help on any of this, I
could probably learn a lot from this too (and maybe teach you some
stuff). I can be reached there: aldric at trevoke dot net
Or if googlewave is your thing, trevoke at googlewave dot com :slight_smile:
I have found that googlewave is actually pretty nice for lengthy
discussions and planning.

Care to add me to that Wave if it happens? My free time is quite
limited lately, but I’d love to take a look at the discussions every
once in a while…

Jesus.

Thanks for those replies all, I definitely got back more input than I
expected. So let me just quell a few concerns. I’m afraid this is
going to be another long post (sorry, lol)

Yes, I am aware of the scope of this project. However I’ll reiterrate
that at this time, my goal is not to produce any kind of functional
multiplayer environment. So regarding DB issues with concurrency I
think SQLite will fit the bill nicely. Any attempt at a multiplayer
game / MUD server would almost assuredly mean a rewrite / new project
built using any knowledge I gain from building the single player
environment - and as far as modifying it for multiplayer if I wanted
to, I mean something small like allowing a couple friends to join in
(ala early examples of small MP environment from the pioneering FPS /
RTS games).

Sorry if I confused anyone on that point. I simply wished to express
my desire that the game complexity be comparable to a MUD environment
with regards to the complexity of the world mechanics, and
interactivity with objects / npcs in the environment itself. As
opposed to those really early text games which while nice, still
couldn’t compare to a MUD with a good parser.

So its safe to say while not a “throwaway” project, I intend to take
it quite seriously and probably put it out there for fun at some
point.

In reply to the Ruby games framework comment. Nothing really
satisfies me, and I am waiting for things such as Ogre.rb to mature
and become feasible for use in production. I can say I would love to
do a graphics based game at some point, something 2D Akin to the
early Final Fantasy’s, or maybe even Isometric 2D/3D strategy type
games (FF Tactics, Front Mission, etc). Those are likely YEARS in the
future for me though.

I can honestly say I feel SQlite is up to the particular task I have
in mind at this stage though. I have done a lot of thinking about
tables, rows, and specifric column fields I will need / want and if I
have to add an extra column or two in the future I don’t think I will
be too concerned. Most of the data stored in the DB is going to be
pre-made content, such as room descriptions and stuff like that. I
do plan on keeping a lot of run-time generated content in memory and
then saving out what is needed when appropriate (a new item is created
on the fly, and then it gets saved to the DB).

I think my particular approach to building my individual systems and
testing them, one at a time, before working on integrating them, will
leave me a lot of flexibility in needed changes to design and how
difficult it will be to change said design. It leaves me a lot of
time to flesh out ideas in my head, while I’m dealing with other
problems, and then write them down and whatnot. Perhaps this is not
the most efficient way to do it, but so far its worked well for what I
perceive to be a relatively small project.

I have no intention of using rails at this point, as I don’t really
see a need for it for this particular case. But I will admit I know
very little about it, and it seems like just another “web platform” to
me so maybe I am making wrong assumptions.

Also I admit I have 0 knowledge of unit testing, version control,
etc. So I probably do need some education in those areas.

I so appreciate the links to those MUD projects, as I didn’t know we
had that many in the community. Although I am loathe to “steal” as it
were, from other projects I definitely will want to look at them for
ideas on how I want to approach the same obstacles.

Events vs Threading:
I totally understand where that commenter was common from. Threading
scares me! Its one of the biggest things I have been fretting over
once I have to move beyond the stage of building my rendering engine
(Room based of course) and can start testing a “live” environment. At
the same time, Event Management, stacks, queues, all that stuff
confuses the hell out of me. But I definitely intend to have multiple
things going on in the background even if the player is idle. I
gotta have a spawn timer/manager for mobs, potentially a
day/night/weather system, spell /item buff durations being monitored,
mobs and NPC’s actively walking around and doing tasks, as well as
quest monitors & timers.

So I am definitely going to have to learn event management.
I totally understand the mountain I have just made for myself but I
feel pretty committed to it and I know it will take me a LONG time to
do this. So I’m ready for the challenge. (I hope)

-Zach

On 14.01.2010 17:35, Zach B. wrote:

So I am definitely going to have to learn event management.
I totally understand the mountain I have just made for myself but I
feel pretty committed to it and I know it will take me a LONG time to
do this. So I’m ready for the challenge. (I hope)

The trick is to take a large, unsolvable problem, and break it down into
tiny, solvable problems.

That it is where, I think, TDD shines: It allows a lone developer to
break down a big problem into a smaller problem in the form of
assertions.

Good luck with your MUD. :slight_smile:

On 15.01.2010 02:55, Marnen Laibow-Koser wrote:

Zach B. wrote:

So regarding DB issues with concurrency I
think SQLite will fit the bill nicely.

On what basis do you think this? Have you got a reason to think this,
or is it just handwaving?

“SQLite usually will work great as the database engine for low to medium
traffic websites (which is to say, 99.9% of all websites). The amount of
web traffic that SQLite can handle depends, of course, on how heavily
the website uses its database. Generally speaking, any site that gets
fewer than 100K hits/day should work fine with SQLite. The 100K hits/day
figure is a conservative estimate, not a hard upper bound. SQLite has
been demonstrated to work with 10 times that amount of traffic.”
http://www.sqlite.org/whentouse.html

So, yeah, obviously SQLite is not able to handle multiple connections.

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.

http://www.sqlite.org/lang.html

BEGIN TRANSACTION, END TRANSACTION, and COMMIT TRANSACTION are SQL
features that SQLite supports. ACIDity is pretty much guaranteed when
transactions are used.

Zach B. wrote:

Thanks for those replies all, I definitely got back more input than I
expected. So let me just quell a few concerns. I’m afraid this is
going to be another long post (sorry, lol)

Yes, I am aware of the scope of this project. However I’ll reiterrate
that at this time, my goal is not to produce any kind of functional
multiplayer environment.

Er…OK. Then why did you say you were building a MUD if you’re leaving
off the MU part? :slight_smile:

So regarding DB issues with concurrency I
think SQLite will fit the bill nicely.

On what basis do you think this? Have you got a reason to think this,
or is it just handwaving?

Any attempt at a multiplayer
game / MUD server would almost assuredly mean a rewrite / new project
built using any knowledge I gain from building the single player
environment - and as far as modifying it for multiplayer if I wanted
to, I mean something small like allowing a couple friends to join in
(ala early examples of small MP environment from the pioneering FPS /
RTS games).

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.

Sorry if I confused anyone on that point. I simply wished to express
my desire that the game complexity be comparable to a MUD environment
with regards to the complexity of the world mechanics, and
interactivity with objects / npcs in the environment itself. As
opposed to those really early text games which while nice, still
couldn’t compare to a MUD with a good parser.

Actually, the early text games (particularly the Infocom ones) often
have better parsers than most MUDs I’ve played.

So its safe to say while not a “throwaway” project, I intend to take
it quite seriously and probably put it out there for fun at some
point.

Good. Then don’t hamstring yourself by refusing to consider anything
but SQLite.

[…]

I can honestly say I feel SQlite is up to the particular task I have
in mind at this stage though.

What you feel is irrelevant. What SQLite can actually do is what
matters.

I have done a lot of thinking about
tables, rows, and specifric column fields I will need / want and if I
have to add an extra column or two in the future I don’t think I will
be too concerned.

Right.

Most of the data stored in the DB is going to be
pre-made content, such as room descriptions and stuff like that. I
do plan on keeping a lot of run-time generated content in memory and
then saving out what is needed when appropriate (a new item is created
on the fly, and then it gets saved to the DB).

I think my particular approach to building my individual systems and
testing them, one at a time, before working on integrating them, will
leave me a lot of flexibility in needed changes to design and how
difficult it will be to change said design.

No. It will just put you in integration hell later. Follow the agile
approach of integrating constantly or nearly so.

It leaves me a lot of
time to flesh out ideas in my head, while I’m dealing with other
problems, and then write them down and whatnot. Perhaps this is not
the most efficient way to do it, but so far its worked well for what I
perceive to be a relatively small project.

This won’t be a small project, from what you’ve described.

I have no intention of using rails at this point, as I don’t really
see a need for it for this particular case. But I will admit I know
very little about it, and it seems like just another “web platform” to
me so maybe I am making wrong assumptions.

Also I admit I have 0 knowledge of unit testing, version control,
etc. So I probably do need some education in those areas.

Then don’t start this project until you’ve gained at least a little
knowledge of each. In 2010, there is no excuse for developing without
both of these in place. None.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Seebs wrote:

On 2010-01-15, Marnen Laibow-Koser [email protected] 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

On 2010-01-15, Marnen Laibow-Koser [email protected] 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. It’s a
purpose-built
language which generates games that can be played on widespread standard
interpreters (available for basically every PDA I know of, for
instance),
complete with a well-considered standard library of laws-of-physics
suitable
for making games like this.

If you want to learn Ruby, sure, go ahead and do it in Ruby. But if
your
goal is to write text adventures, Inform6 is an extremely good language
for
the task.

-s

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

在 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. :slight_smile:

Jeff.

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

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 :slight_smile:
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! :stuck_out_tongue:
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! :wink: 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

2010/1/17 Zach B. [email protected]:

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 :slight_smile:

The good news is that you’ll likely be able to reuse most of the SQL
and probably just need to write a new schema definition for another DB
and exchange the DB connector. So it might not be too big a deal.

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.

I’d go even further and claim that it’s only through failures that
we learn. Side note: I find the constructivist theory of reality
convincing: there is not absolute reality we can “see” but instead we
create our own idea of reality whenever we have to change our concept
of it (i.e. when we hit a “wall”). See also

http://en.wikipedia.org/wiki/Constructivist_epistemology
http://en.wikipedia.org/wiki/Constructivism_(learning_theory)#Learning_is_an_active.2C_social_process

taking over what useful bits I’ve learned up till then.
Good.

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.

IMHO that approach will yield best learning results because from your
project you get a motivation much better than from text book examples
(which doesn’t mean those are good from time to time as well because
they confront us with other knowledge or solutions).

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.

Frankly, I am not so sure about Google Wave either. It’s still pretty
slow and seems quirky. Use the tools you feel comfortable with.

I do appreciate everyones input. It does help.

You’re welcome! Have fun!

Kind regards

robert

Zach B. wrote:

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.

The best MUD on which I ever played was the Discworld MUD - The world is
amazing, and the parser is ridiculous.

Re: Google wave. Never heard of it until I looked it up, sorry! :stuck_out_tongue:
I’m not sure I would make for good conversation anyway. I’m also
terribly shy when it comes to actual verbal conversation…
Verbal? In Google Wave, it’s still about typing stuff, although there
are ways to talk to other people.

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! :wink:
I’m actually really curious… :slight_smile: I think I would enjoy that, as long
as I am allowed to balk at things that are too strange or too
un-Ruby-ish :slight_smile:

Good luck though… We’ll be here!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs