On Thu, Mar 6, 2008 at 7:25 PM, Nathan <[EMAIL PROTECTED]> wrote: > > I commonly run into this scenario, and I'm wondering what the "best" > pattern is for handling it: > > On my game client, I have collections of things. Often these things > need to access all the other things (for collision detection, mostly). > So I have a list of "other players", a list of rockets, a list of > "lines" which you can walk on, etc. Sometimes I make these lists > global with "global whateverlist" wherever I use it.
If you have a bunch of things and one or more actions to perform on them, you should put all of them into a collection object with methods that do what you want to the collection. So rather than have each object test collision with every other (a simple, but rather inefficient algorithm), you would ask the "collision space" object containing all of the objects, which objects collide. If objects collide, then the collision space could call a method on each colliding object saying what it collided with. Or the collision space itself could handle the collisions, though I prefer the former method since you let each object decide it's behavior. For example, a missile object might hit another object. When the missile's "collide(self, other)" method is called, it would explode and call the damage() method on the other object (or something like that). This encapsulates your collision handling (or whatever you do at the collection level) in one place so that the node object just need to know what to do when they collide, not how to figure out who they collide with. It also gives you an easier way to plug in a more efficient algorithm or a different implementation altogether (e.g, using ode) To make this work the collision space itself could just be attached as an attribute to a window or part of a game state object (these would tend to be globals). It would register itself to get updated regularly (either by scheduling or inserting a method call in the window's event loop, etc). -Casey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
