Sign in to follow this  
popsoftheyear

Y.A. game logic question

Recommended Posts

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

Share this post


Link to post
Share on other sites
Do something.

I know, sounds dumb. The best advice I've ever gotten for stuff like this is to focus on the goal. Get stuff done. Any of the designs will work, and any you implement is probably going to be crappy. You'll learn a lot implementing any of them (even the switch statement), and you'll get stuff done; move on to more problems to learn more stuff. Sitting around waffling over options teaches you little and gets nothing done.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this