[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Cross-References



Kris Schnee schrieb:
That problem of creating a Pong demo really did get me thinking about the possible ways of organizing data and drawing objects. I've been used to giving objects lots of cross-references, eg.:

class SubPart:
    def __init__(self,**options):
        self.foo = 42
        self.parent = options.get("parent")

class BiggerThing:
    def __init__(self,**options):
        self.subpart = SubPart(parent=self)


Is this a good coding practice? If not, why not? Does it make sense to give drawable objects references to the screen, so that I can tell them to go blit themselves instead of having a manager object do so?


Also, when I last worked on my main project I'd organized it in a modular way:
-AI
-AI subsystems
-Character bodies
-Game world ("worldsim","Aquablue")
-Graphics system/tile engine ("Coral")
-Main interface


I ran the interface, which created a game world and Coral engine, then created character "bodies" run by AIs. The characters got placed in the game world, but also had references to a sprite which was placed in the Coral system. That created a complicated system to keep track of everything:

-Main
  -Aquablue
    -Characters
      -Niss (a character)
        -AI
        -Personal stats
        -Sprite
    -Tile-based world
      -Niss (a reference located in a specific tile)
  -Coral
    -Tile stuff
    -Sprites
      -Niss.sprite

Is this overkill, or is it all necessary? I'd like to have the game world independent of the graphics engine, so that if I ever make the leap to 3D the world will still work. (I also want the AI independent of having a tile-based 2D world.) But this system creates a whole lot of cross-references so that I can, eg:
-Look up a character by name/ID
-See the contents of a specific tile without asking every entity in the world "are you here?"
-Move a character within the game world
-Tell the graphics engine to move the character on screen


Re: a bit of code I haven't done, it seems like there has to be coordination between Aquablue and Coral to make sure the graphics system gets notified not just when a character moves but what animation they should start playing, and I'm not sure whether the sprite system should be explicitly told "play animation walk_north" or what.

Kris


Hi Kris

Dont know how much cross reference is good or not. I try to see the things from the point of view of information: what information is needed where. And then try to see if some part can be separated or joined. Sometimes it is also a joice how you do the things which influences how the things are connected. If you want that every object has the capablility to draw itsself then it must have access to the screen (if trough a local reference or a global variable or an method argument, how it is not so important). In my spriteengine a sprite must be added befor it appears on screen, so I have a sprite representing the object on screen. The object only modifies the position of the sprite to move it on screen. The collision system will be indipendent. Should also run without graphics and so on.

Perhaps interfaces is the way to do loosely coupled parts. Define an interface and other parts use this interface to interact with this part, then you can do it in a modular way (ok, I'm not an expert on this, but I think thats good).

The pong demo using the CMV pattern (control, model, view) made me also thinking about such things. Can it be done all event driven? I mean, anything that happens is controlled through an event (there would be many events). Is that good?

Separating the things is good but somehow they have to "talk" to work together.

~DR0ID