Sign in to follow this  
Believe82

Game design with Collision Detection

Recommended Posts

Hi, I'm making a 2D game and I have a short question regarding where the logic of border collision should be placed.

 

For my 2D game, I made a small collision engine. In game design, should the collision engine have direct access to sprites? For example if the collision engine detects a collision between the sprite and the border of my game, should the collision engine then directly change the sprites position / velocity? If the collision engine detects collision between two sprites, should it be the one that directly access information such as sprite health bars etc? 

My aim here is not to make a game engine, I am simply making a small collision engine for my game to abstract away collision logic, and have possible re-uses for the future. In order to accomplish my aim I would like to understand if it is good practice for the collision engine to access sprite data when a collision is detected. Or if there is a better / more standard design to do this.

 

Edit* Currently I am setting sprite coordinates from within the collision engine if a collision is detected.

Edited by Believe82

Share this post


Link to post
Share on other sites

One way you can implement this is for your collision code to have direct control over the state of the sprites, as you've already described. With this design, however, you'll find that things are not well encapsulated. Your collision code check for collisions, decide how to respond to the them, and then act out those responses as a side effect. I think it's better for your collision to be more "functional" and stateless, meaning that it takes as input some objects which potentially collide, find collisions, calculate a suggested response to the collisions, and outputs those suggestions. These suggestions can then be consumed by another piece of code which doesn't have to do any calculation, it simply acts. In this way, your game has smaller, simpler components which are easier to test, debug, and reuse.

Share this post


Link to post
Share on other sites
If this is your first collision implementation, I would recommend starting with simple stuff, like circle vs. circle collisions. Accessing sprite data may be slow, if it has a lot of pixels. You should have every class have a function that is called whenever a collision is detected, and have the function modify the data.

Share this post


Link to post
Share on other sites


My aim here is not to make a game engine, I am simply making a small collision engine for my game to abstract away collision logic, and have possible re-uses for the future.
So you're making a game engine the way it's meant to be made: tailoring it to your needs.

There's a lot of fuss on what the "game engine" is. At the lowest common denominator, it's your game logic.

 

Now, going to the point.

 

Because of the aforementioned encapsulation and separation of concerns, you really don't want your collision detection to have notions such as "health". You might want to give collision detection the ability to also perform collision response in some "default" way but you have to make this behaviour toggle-able.

 

In all cases, callbacks will be key. There are a few ways to do those correctly. Recent C++ versions provide std::function, which is more powerful than you'll likely need in this case. Generic inheritance can also be put to good use, I think it fits well in most cases.

There's also the chance you might not want callbacks at all, leaving further contact processing for a second system. This doesn't scale much in my opinion but it's viable as long as the game is simple (I'm currently doing that).

Share this post


Link to post
Share on other sites

Another option, if you use a entity-component system, is, when your collision engine detects a collision, it adds a "contact" component to each entity, and that contact component tells the entity what other entity it collided with, and what the possible collision response would be (velocity and position for each entity).  This contact component would stay with each entity until they stop touching.  

 

That should be generic enough to handle any game type I would think.

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