Jump to content
  • Advertisement
Sign in to follow this  

Game engine design

This topic is 2732 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How should my collision system/physics system interact with the main game loop?

This is how it's kinda looking right now:

Game::mainLoop(float dt)
mLevel->update(dt); // calls Level::mObjectManager->update(dt), that calls ObjectManager::mCollisionManager->update(dt) etc ......



- Used for storing information about the level
- Contains a ObjectManager
- It's update function gets called in the main game loop
- Calls mObjectManager->update(dt)

- Has a std::vector<Object> mObjectList;
- Handles deletions of objects, adding them and loading/saving
- Has a CollisionManager

- Used for finding out if objects intersect
- Has a std::vector<Object> mCollisionList;
- Has a PhysicsManager that handles what to do with the objects in mCollisionList;
- // is it up to this to find out direction of collision, or should PhysicsManager do that?

- Handles gravity
- Handles all objects that colide with each other and tell them how to react

This ends up with this type of structure: gameLoop->mLevel->mObjectManager->mCollisionManager->mPhysicsManager

It doesn't feel right the way I'm doing it and it's probably not, I think it's really hard to figure out the best way to do this. Maybe the gameLoop should have a list of all components and then just loop through their update()? But then I dont understand how each manager should reach all the data it needs.

I hope what I wrote not weren't jibberish, but if so then basicly what I need help with is from where the object, collision and physics managers should get called and how I should do so they can acces the data they need. How would you solve this issue?

It also feels like the stuff that CollisionManager does is a part of the physics manager, combine them perhaps?

Share this post

Link to post
Share on other sites
I'm not sure how it would fit in with your design, but, for a collision/physics library I use:

Essentially, there're 3 parts: collision detection, force/torque calcs based on the collisions, physics application of the forces/torques.

1. Maintain a list (vector, etc.) of collision objects (spheres, triangles, etc.) Each collision object has a position, velocity, orientation, etc.

2. COLLISION DETECTION: The collision routine checks all dynamic objects for collision with all other objects and generates collision information for each collision which it adds to a list (vector, etc.). The collision information for each collision holds pointers to the two colliding objects, the position of the collision, a normal vector* at that position, and the depth of penetration (how much the objects overlap).

*Pick a convention for the normal vector - e.g., the normal vector always points toward the first object.

3. Set forces and torques for each collision object to 0 (no force, no torque). Leave velocities, angular velocities and positions alone.

4. CALC FORCES/TORQUES: Process the list of collisions. This depends on what you want to do with the collision information. One approach - for each object, generate a list of collisions it's involved in. Options for what to do with each object's list:
a. send the list to a callback function for that object (if it has a callback function pointer) and let the object decide how to respond (add forces/torques to itself, etc.)
b. otherwise generate forces/torques on the object using default calcs which consider the depth of penetration, the normal, etc.

5. APPLY PHYSICS: The physics routine then goes through the list of all objects and:
a. if the object doesn't have a physics callback function - use default calcs to apply forces and torques to determine new positions, orientation, velocities, angular velocities, etc.
b. otherwise, call the callback function and let the object do its own calcs

6. For each render object, determine its position and orientation from its collision object(s) and render it.

Share this post

Link to post
Share on other sites
Thanks Buckeye! I guess the step you mentioned will get called directly from the game loop and not in the way I described.

I'm actually on a ski vacation right now but I managed to bring some extracts from a game engine book. Things will 'prolly get clearer as I read on as well, designing your own game engine is more complicated than I thought. Sure I can try and learn from fails, but to have a system that is common structured from the start feels like a smart thing. :)

Share this post

Link to post
Share on other sites
You really don't need to mention ski vacations. ;) There are some of us that're sitting at home right now.

WRT game engines: integrating a collision/physics engine of your own design is a bit tedious. I cheated a bit myself and, without compunction, lifted techniques from open source engines.

I would expect that things will get clearer (as you make and correct errors). Don't forget: avoiding errors comes from experience. Unfortunately, experience comes from making errors. Learn to enjoy failure. In psychological circles is called AFGO ( Another F----- Growth Opportunity ).

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!