From: Robert Klemme <shortcutter@...>
Date: 2010-01-14T17:20:35+09:00
Subject: Re: Recommended Reading (also: Arrays/Hashes)

2010/1/13 Zach Bartels <no@spam.com>:

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.

> 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?

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/