Re: Recommended Reading (also: Arrays/Hashes)

Zach Bartels 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
[e-mail]
-- 
Posted via http://www.ruby-forum.com/.