Design Decision: PhysX

The physics engine employed in the Emergence Game Engine is NVIDIA’s PhysX (formerly Ageia PhysX). This actually wasn’t an immediate decision, and didin’t come until later in the deployment process. Employing physics into a game engine doesn’t come right away, before you can worry about physics you need to worry about the actual architecture of your game. If physics are to do anything you need some kind of entity with an associated 3D mesh, that way you can actually render the behavior of the physics. You also need a map format, with a rasterizer for the map. And you need to have some sort of “physical” geometry defined for each of these shapes.

I originally began developing an engine called the Legacy Game Engine, which was similar in concept to the current design, but I began developing it with little knowledge of 3D game architecture. When developing this engine I began by developing my own physics engine. The original physics were based on axis-aligned bounding boxes for entities, and convex polyhedrons for world geometry. This is a common design for game engines all the way up until about 2003. I started out developing the engine like this because it was a simple solution to get physics up and running quickly. You really don’t have much of a game, until there is some kind of physics. My own physics engine had the typical features you need in a game engine: Collision detection, a model of Newtonian Mechanics, including gravity and surface to surface friction, and so forth. But it felt stiff. It felt old school. I realized that it would literally take years if I was going to develop my own physics engine.

I knew that some of the major games on the market like Half Life 2 and Oblivion were using a technology called Havok for their physics, but Havok isn’t exactly cheap, and Beem Software is currently running on a very tight budget. I was quickly introduced to a free solution called Newton Game Dynamics, this was a fully implemented game physics SDK with all the features necessary for some good looking physics. I began implementing that engine the day I was introduced to it. I had spectacular results right away. The SDK was well documented, and I was able to get much more functionality out of Newton Game Dynamics in a few hours, than from days of working on my own physics engine.

This was well and fine for a few months of development, then I started running into problems. Not major problems, mind you, but the physics engine was behaving strangely at times. Granted, this is because I was still working on my older Legacy engine, which had some problems to begin with. I’d heard of PhysX, of course. As a gamer, it had been mentioned in a few articles. So I started to look into it. When I found out that Unreal technology was using PhysX I was interested right away. PhysX was still under Ageia at the time, so I signed up for their developer website, downloaded the SDK, and began implementing it into the Legacy engine.

At the time, I actually designed the physics portion of my game engine to be modular, so that I could use any of the three physics engines (my own, Newton Game Dynamics, and PhysX) just by changing a variable.

Soo after, the Legacy engine was to be scrapped. I had taken a course in software engineering, which led me to believe that a lot of the code design in the Legacy engine was confusing to read, and overall had a bad design. There were also a lot of features in the game, where the current design was too difficult to enhance in the ways I needed. I began the Emergence Engine. The new engine didn’t completely discount the old one, some of the old code was still good, it was just the big picture that was a mess, so it didn’t take long to get Emergence into a working game engine. In my experience with the original engine, though, I found PhysX to be the most robust solution for physics, and it was my intent to build the engine to take full advantage of PhysX. So unlike the original Legacy Engine, no other physics solutions are available, it is strictly PhysX.

Entities are defined using an XML file, and the specifications for the entity are stored in that file. The PhysX portion of the game engine is still in development, and there are quite a few more features to implement, but it has proven to be a good foundation for the game engine.

Ultimately I decided on PhysX for a few reasons. First, that it is free, and second, it is used in some high profile games, so that’s a good sign that it doesn’t have any major problems, and lastly, it has a well documented SDK with example applications, so it is very easy to implement in a short amount of time.