[Tutor] Instantiating large numbers of objects?

Britt Green cheshire_cat_sf@yahoo.com
Sun, 3 Feb 2002 13:25:34 -0800 (PST)

Hello Kirby:

I'm trying to keep things in my text adventure as simple as possible.
When I started this project some time ago, it quickly got out of hand
with all the things I wanted to add into it. So now that I'm picking it
up again, I'm definately trying to keep it easy.

Hard-coding the rooms into the code seems the simplest way to create my
rooms. I was thinking that each room would have the following
attributes, initially:

a unique room number
a description
a dictionary of exits (ie: {'n':1, 'e':3, 's':4}

Eventually I'll want to move the room descriptions into a seperate text
file, but that's further down the road. Right now my little world has
about twenty or thirty rooms total so hard-coding them is fine for now.

So...let me rephrase my question. When I was learning Java, we created
a class for bank accounts. Each account was a seperate class instance.
If you had three accounts, you'd create three instances in your code:

bob = new Account()
sue = new Accout()
jim = new Account()

and then you'd call the class methods like so:


So far this is the only way I know of to instantiate classes. Obviously
when a bank uses this software, they wouldn't open up the code to add
new accounts. How would they create new instances of the Account class?
I seem to recall being told once that in C or Java one would create an
array or Vector of objects. I was thinking I would do the same thing
with my Rooms, except Python doesn't have arrays or Vectors.

I apologize if I'm not explaning myself clearly. This is still pretty
new to me and I'm not 100% sure how to phrase my question. Hopefully
the readers of this list are smart enough to figure out what I'm saying
though! ;)


--- Kirby Urner <urnerk@qwest.net> wrote:
> >
> >Thanks to everyone who's helping me out. When I'm famous
> >and wealthy, I promise to remember you all! ;)
> >
> >Britt
> If you have lots of detailed, specific room info, then
> there's no substitute for having this info *somewhere*.
> You can have it in the code (it scales if you add to
> the code) or you can have it in a file, which your
> code reads, and uses to create objects.
> Where should these objects live?  We've talked about putting
> them in a dictionary, where they can be accessed by name.
> We've also looked at adding new objects to globals e.g.
> by going:  globals()['thegreathall']=Room()
> A dungeon or castle is a sophisticated data structure
> (potentially).  Rooms exit to other rooms, so one approach
> is to save where the exits go, as attributes of the rooms.
> You could have Connection objects and use composition
> I suppose, e.g.
>         class Kitchen(Room):
>             def __init__(self):
>                 self.exit1 = Connection("Hall")
>                 self.exit2 = Connection("DiningRoom")
> In this model, rooms are class definitions, not just
> instantiations of Rooms.  Given the info associated with
> each room, this might work better.
> Detailed advice is difficult, because what shapes the
> design is the overall structure and purpose of the game
> or whatever.  Just knowing you want "a lot of rooms"
> is an insufficient basis for more than a few tips.
> So I'll be quiet now.
> Kirby

"The ocean, she is strange and wondrous, filled with animals that disturb even a Frenchman."

Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!