Recommended Reading (also: Arrays/Hashes)
in [Ruby]
|
From: Zach Bartels on 13 Jan 2010 16:52 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
From: Phillip Gawlowski on 13 Jan 2010 17:27 On 13.01.2010 22:55, Zach Bartels wrote: > Hi all, > > Apologies for the long post, but just want to introduce myself Mission accomplished, I'd say. :) 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. :) -- Phillip Gawlowski
From: Marnen Laibow-Koser on 13 Jan 2010 17:31 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 marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/.
From: Jose Hales-Garcia on 14 Jan 2010 08:42 Zach Bartels 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 jose(a)stat.ucla.edu -- Posted via http://www.ruby-forum.com/.
From: Zach Bartels on 14 Jan 2010 11:32
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 |