Author Topic: Oh boy, adventures in rebinding variables!!! (Python)  (Read 31988 times)

Gr3yling

  • Rogueliker
  • ***
  • Posts: 168
  • Karma: +0/-0
    • View Profile
    • Email
Re: Oh boy, adventures in rebinding variables!!! (Python)
« Reply #30 on: May 22, 2014, 04:07:14 AM »
Wow, you were right. This is turning into an enjoyable discussion. So what does the interpreter say after you fix that line?

(i.e. when you change object.Hostile_AI.take_turn() to object.ai.take_turn() ?)

I found the problem.  There were a number of errors, but the main one was that Hostile_AI was the name of the class itself, not of an instance of the class.  I had forgotten to instantiate it at all. 

There are a number of bugs still left, but I think I can probably fix them.  I actually had a successful program and was at the step of implementing an inventory system when I decided that the roguelike tutorial's way of making almost all in game objects (the PC, monsters, items, etc) members of the same multifunctional class was better than my way of having a separate item and actor class.  And then when I tried to implement that, there were a bunch of errors that popped up from the changes I made.

Anyway, thanks for the help turoturo.

AgingMinotaur

  • Rogueliker
  • ***
  • Posts: 805
  • Karma: +2/-0
  • Original Discriminating Buffalo Man
    • View Profile
    • Land of Strangers
Re: Oh boy, adventures in rebinding variables!!! (Python)
« Reply #31 on: May 22, 2014, 07:18:33 AM »
I decided that the roguelike tutorial's way of making almost all in game objects (the PC, monsters, items, etc) members of the same multifunctional class was better than my way of having a separate item and actor class.

A good idea might be to implement various kinds of game objects as subclasses. Eg.:
Code: [Select]
class Being:
   generic_tile=None # properties that go here, are shared by all instances of the class
   def __init__(self):
      self.tile=self.generic_tile # now you can change an instance's self.tile without affecting the class as such
class Critter(Being):
   generic_maxhealth=0
   def __init__(self):
      Being.__init__(self)
      self.maxhealth=self.generic_maxhealth
class Chicken(Critter):
   generic_tile="c" ; generic_maxhealth=1
This way, you can implement generic functions and properties in the Being class, and still get to code special make-up for classes that need it, like having different destroy() functions for items and critters.

On a more general note, your book will surely get you going once it arrives. Worrying about what's going on under the hood will yield a game much slower than going at it with the mentality of a chaos mage: if it works, just do it. The python shell is a good tool to check out what stuff does that you're unsure of. Consider this:
Code: [Select]
x=5
x is 5 # returns True
y=x # the same as calling y=5, considering that (x is 5)==True
x+=1
x # 6, obviously
y # 5, even though we changed x

As always,
Minotauros
This matir, as laborintus, Dedalus hous, hath many halkes and hurnes ... wyndynges and wrynkelynges.