FicEngine: Physics
Sorry for the lack of updates in the past week or so, I’ve been busy getting addicted to disc golf, and moving a good friend away to Reno, so I’ve been largely taking it easy on the code/blog front.
Today I want to talk about the Physics Manager in the FicEngine. I had to give a good deal of thought to creating my own system versus using an existing engine such as Newton, ODE or Chipmunk. This has a hard decision, since as I’ve mentioned before, if a system exists, it means there are people whose job is to specifically maintain and improve that system, and it will be better than anything that you could come up with by yourself. But on the other hand, I really enjoy coding physics, and I don’t need nearly the functionality that a lot of these major systems offer.
In the end, I have decided to create my own system, for the following reasons:
- Focusing on features I need, instead of wasting resources on features I don’t. For instance, I don’t need rigid body dynamics. No, really. I don’t. I have 28 game ideas documented in my notebooks, and none of them require this feature. Personally, I think it adds very little to games. Shit flying around is cool, but when it needs to accurately collide and react with other shit at the expense of other things that need that CPU power, that sucks. Don’t need it. This kind of thing can be faked and look just as cool.
- More control over the behavior of physics objects. Every physics engine I’ve seen has the same problem: the objects all have this floaty-ness to them that not only isn’t very believable, it just looks bad. This could be more the fault of the application code, as this has gotten better over time, but it’s behavior that’s even present in games like Bioshock and Halo 3. Additionally, having tighter control of the objects allows me to prevent the shoot-off-into-fucking-space bug that I STILL see in games, even Halo 3. (Killing a scarab from the inside shot me clean off the fucking map, killing me. Thanks, physics engine.)
- Integration with my game logic. This is a big advantage and has been the focus of my physics code. The physics gels perfectly with my other systems, and adding physics to ANY game object is as easy as registering it with the physics manager. This integration allows things like logical partitioning, which I’ll talk about next.
The most important part of any physics system is collision detection and response, and this is where I think I hit it out of the park. I wanted to make sure this part of the code was fast and robust, because it will be at the center of all my games. Collision detection was the biggest CPU hog by far in Kill Dr. Cote. The sheer amount of carnage and gibs flying around means that collision detection must be lightning fast, extendable, and reusable.
The biggest concept that simplifies the physics greatly is separating the graphical representation of an object with its physical representation. Meaning, regardless of how an object looks on screen, it has a separate shape that is used in collision checks. These shapes are very simple, making collision checks very fast. Circles, axis-aligned bounding boxes, points, halfspaces, and rays are currently supported, with object bounding-boxes and arbitrary polygons to be added when (and if) I need them.
The class hierarchy of these shapes, plus a good RTTI system means that checking two objects is as easy as CheckCollision(objectA, objectB). The collision system knows what shapes to check and automatically makes the right function call. And adding new shapes (and the required collision code) is fast and easy.
The physics manager uses two systems for reducing the number of collision checks that need to be executed per frame: spatial partitioning, and logical partitioning. The spatial partitioning system uses a grid to separate faraway objects- so objects that are in different cells with no overlapping have no chance of colliding, and do not need to be checked. Many systems use some sort of spatial partitioning, but what I don’t see often is logical partitioning. I’ve seen the term used in other contexts, but in the context of the FicEngine it means this: Objects, along with having a shape, have a faction. Think factions from MMORPGs- it’s kind of an allegiance, and certain factions will hate other factions, or be peaceful towards others. Game objects use this same concept- if two objects have the same faction (or if the two factions are peaceful with each other) the collision system doesn’t waste time checking them. So for instance, in Kill Dr. Cote, I would separate game objects into factions by Player, Enemy, PlayerBullets, EnemyBullets, and Walls. This also serves a purpose when it comes to collision response.
The collision response system is one I’m especially proud of. I use a matrix that tells me what happens when Faction A collides with Faction B. It is here where I decide if game objects take damage, are removed from play, are obstructed, etc… a very simple, powerful, and extendable system that allows me to define game logic in a matter of minutes, which is one of the main goals of this engine. The responses I have coded in there so far are enough for the vast majority of my ideas, but if and when I do need more, it’s a very simple matter to add them.
And the final big advantage to this physics system is that I can use it effectively in both 2D and 3D games. Being able to create these games with much greater speed and without sacrificing functionality is something that will aid me greatly when I start prototyping. Which, I might add, is getting dangerously close…
… stay tuned.
No comments yet.
