Summary: Game physics works per frame, and is discretely accurate. Normal physics engines simulate real physical principals, and do integrate. Design is what keeps your game from having errors, not the engine integrating better / more accurately.
Game Physcis. The long debated quitnessential problem with most all games. Do you take an existing physics engine and force it to work the way you want? Or do you roll your own collision system for perfect accuracy at the cost of far greater development time?
Obviously, I chose to roll my own since I've never seen a "game" physics engine. I've seen bullet, novodex, Aegia PhysX, ODE, tokamak, Newton, ect... and they all attempt to be "physics" engines, not game physics engines.
What is the difference between a physics engine and a game physics engine?
- 1. Game physics do not model reality; they model fixed frame impulse systems; IE they are not time based.
- 2. Game physics generally have multiple levels of physical objects, static objects are handled vastly differently than dynamic objects, and objects that have one way interactions are handled differently still.
- 3. Game physics trades accuracy for quantity & speed. Also, their accuracy has no real physical model to use, other than the most basic physical principles (ray reflection, momentum, mass)
So, the worst part about rolling your own (maybe 500~ lines of code if you're good) is the geometry. The nastiest part about any collision engine is simply generating all the 'trivial' geometry intersection and distance functions you will need. I've consulted more than 3 PhD mathematicians on this subject, and none of them were able to solve these "trivial" problems. And these guys are seriously brilliant professors! So don't arrogantly think that these are ever trivial questions to ask; they only appear trivial because the solution seems so logically simple. Much like, if you asked what the arc length is on an ellipse. Seems innocent enough at first, go research it.
Also, game physics use special models of collision, specifically the ray-bounce-slide model, so you character will slither along corridors and walls with great clarity and smoothness, and essentially have perfectly inelastic collisions with just about everything. Lots of optimizations present themselves for broad phase testing, especially when you break up the static / dynamic environments.
So for my purposes, I made a simple little game physics engine that lets me run objects like I would expect them, it's discrete time stepping, fully consistent, but it does allow something I have always hated, which is possible penetrations. I'll have to think more to figure out how to integrate that type of dynamic into a system like this, but the truth is, if you have dynamic/dynamic object collisions, there are very few ways to solve them (refer to the classic 3 body problem, and enjoy your porkchop with cyclic coordinate descent.) So, stepping your dynamics works against dynamic objects, but you can make much more accurate collision assessments against the level. But wait! if you set your steps and velocities right, guess what? You can just completely ignore that problem all together.
Your levels, collision areas, rooms, whatever; If they are designed right, you can make it so they can't mess up on the even inaccurate stepped integrations. So, it's never been a question of 'physics engine', it's only been a question of how smart you really are when it comes to designing the actual game. This would be called 'cheating'.
The difference here, is all of this is a beautiful, easy to plug into anything C/C++ class relying on the core components I have made.
Here's some balls moving around in the physical simulation. Note the time in the upper left (milliseconds / FPS) and the quantities of object in the upper right. The broadphase method used is taking a bounding sphere for each object, then calculating the best axis based on the minimum position along x,y,z axes (O(N)) using the in-line variance sum ( 3*O(N) ), then taking that axis, and making a vector with all the minimum positions and pointer back to the object, sorting (O( log2(N)*N )), then running along that sorted interval list, and testing all unique overlapping interval pairs (O( N * m ), m is far less than N). This methods worst case is N^2, as in all broadphase systems, and it's best case is O( log2(N)*N ) because of the sorting. It performs very well and has no physical size restrictions, and it can use AABB's instead of spheres for greater reduction to m.
