Best practice for organizing the physics of objects?

Question

Apologies because this is a long post and I am inexperienced. I would really appreciate the input from some experienced developers.

These are my two goals for this project:

1. To learn the best method of managing the game loop and flow of the program so that it is easily understandable, clean, and reusable.

2. To learn about how to efficiently and cleanly handle the physics calculations of a game. I would like to learn the method that is implementable on a scale that can accommodate a lot of collisions.

The project will be written in using Javascript/HTML 5.

The way I was thinking about it is to include attach implement an physics object constructor that attaches a physics object to each class object that will have physics done to it.

For example:

var playerBullets = [];
playerBullets.push(Bullets()); //Bullets() is the constructor

//inside the Bullets() constructor I would have the following:
this.physics = Physics();  //where Physics() is the constructor for a physics obj

The physics object would be set up like the following:

{
  x: 0,
  y: 0,
  xVelocity: 0,
  yVelocity: 0,
  xAccel: 0,
  yAccel: 0,
  mass: 0,
  restitution: 0,
  angularVelocity: 0,
  linearDampening: 0,
}

Then from the gameLoop:

Function gameLoop() {
  ...
  update();
  draw();
}

Function update() {
  ...
  //code here to iterate through objects to update them individually
  handleCollisions();
  handlePhysics();
 }

Function handleCollisions() {
   ...
   //detect collisions between objects and mark which ones have collided with each other
}

Function handlePhysics() {
   ...
   //code to iterate through objects and update the velocities
   handleCollisions();      
}

Questions

1. What might be some problems I would run into by doing it this way?

2. Should I include any methods in the physics object or should I handle all of my physics operations in a special function inside the gameloop?

3. Is it better to handle the physics together, or handle the physics of each object separately in its own update function?

4. What is the best practice way to handle physics in a game?

EDIT I learn better by seeing examples so it would be very helpful, and I'd really appreciate it, if I could see some accompanying pseudo-code.

Answer 1

Typically a physics engine will follow these steps:

• Broad-phase collision detection. Typically using bounding volumes, this reduces the set of all objects to a small subset of potentially colliding objects. Some data structures to handle broad-phase are AABB trees, KD-trees, Octrees, etc.
• Narrow-phase collision detection. From the subset of potential collision, test if a collision actually occurred by using the actual physics body. This typically involves calculating things like point of contact and normals.
• Solver. Resolve collisions by pushing objects apart and enforcing constraints.

Because of the global nature of these calculations, it's typical to have physics objects centralized. You'll have them classified in a hierarchical structure, organized based on their bounding volumes (which is also handy for spatial queries, like finding objects near me). You might also want to separate static and dynamic objects, for efficiency (as only the latter can move, so the former don't need to be updated).

It's ok to put the physics object inside the normal game object as long as you also register it with the physics system. When you find a collision you'll want to notify the game object back; this is typically done by embedding a piece of data in the physics object that points back to the game object, so they both know about each other. You can do that in the Bullet constructor, in your example.

You can add methods to the physics objects like you would do with any other object in OOP. It may make sense for internal operations, related to the physics body, physics material, etc.

I'm curious why you didn't show a time delta in your update functions. Was this omitted for brevity or are you assuming a lockstep framerate? I find having a variable timestep gives you more flexibility but it can make the physics engine unstable (due to integration issues) if you don't run it at a high enough framerate. I've seen engines run several physics updates per frame in these cases, while still running the logic and rendering only once.

EDIT: If writing a broad phase is too much, I'd probably start with a simple array that contains the physics objects, and test everything against everything (which will become expensive once you have many).

PhysicsManager.physicsObjects = []; 

// In Bullet constructor
this.physics = Physics();
PhysicsManager.physicsObjects.push(this.physics);

// Then in physics update    
for (var i=0; i<physicsObjects.length; ++i)
    for (var j=0; j<physicsObjects.length; ++j)
         if (i != j && collides(physicsObjects[i], physicsObjects[j]))
               // Handle collision