Yet another game logic structure question... Lately I've read post after post, articles, forums on other sites, and so on about this kinda thing, and it's still not clicking. I have a game with a few different types of objects (maybe 5ish). Any of them can collide with each other, but depending on what collides with what, and even what some of these collided with the last time, different things will happen in the game (ie game logic). I started it with "C"-style code with publicly accessible structs and a few functions to handle all logic and it worked out really well and was really easy, but things started to get bloated and not-very-modular. So I decided to smarten up. Oops. So the question is... how in the world is the best way to structure this? Specifically, I've got all my bounding types (there's a couple of them) in the physics "sub-system", and it handles all collisions, and knows nothing about the objects or what they are - only the bounding types and how they collide. I've read numerous responses to this kind of thing, but none of them seem good to me (I'm using C++ by the way). Should I implement code to help me double-dispatch? Should I implement an explicit event system? I'm half tempted to give each bounding box a pointer to its parent, have an Id for the entity type and another Id for the entity itself (to differentiate between the entities of a same exact type), and just have a giant switch statement. But then I wouldn't be learning better ways now would I? It's a small game, but the point of it was to 1) Actually complete something and 2) Learn some things to move up to more complicated games. Needless to say I'm failing miserably and I feel stuck. Advice? Cheers -Scott