[Tutor] Instantiating large numbers of objects?

[Britt Green]

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:

bob.makeWithdrawl(500)
sue.checkBalance()
jim.makeDeposit(200)

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! ;)

Britt

--- 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! 
http://auctions.yahoo.com