Dev Blog

My goal for this weekend was to get a collision and physics library into C2.

We used ODE for PubCrawl and it didn’t leave me with much confidence. This time I chose to use the Bullet Physics Library because I’ve heard good things about it. Bullet is geared more towards game engines and is much simpler than ODE. I was able to get a quick test program up using Bullet in about a day. After another day I had integrated Bullet physics into the engine itself very nicely.

In C2 physics can be added to any SceneNodes by creating and attaching a PhysicsObject. A PhysicsObject does two things:

1) provides a description of an object for simulating physics
2) updates the transformation of the SceneNode after simulation each frame

For example a PhysicsObject can be created with a mass of 10 and a sphere collision shape of radius 2. The simulation is run: objects are moved, collisions are found and resolved. Then the PhysicsObject copies it’s simulated transformation to the SceneNode’s transformation. Then the scene is rendered.

The PhysicsObject class is actually a very simple wrapper around Bullet rigid bodies. It is mainly meant to keep the engine from using Bullet directly. This hides library and header dependencies. Once compiled into a library only the C2 engine headers are necessary to use the engine. If this were not the case using the engine would be a nightmare of dependencies.

I was able to add physics information to the scene file format as well. Any SceneNode with physics definitions has a PhysicsObject created and attached to itself on load. It’s very gratifying to write a quick scene file and load it up and watch objects fall and collide. It is surprising that good physics can be had at such a low investment of time. I highly recommend the Bullet Physics Library to anyone interested in adding physics to their game engine.

The next step in the physics system is to add constraints. Constraints would allow large static objects made up of multiple PhysicsObjects that act as one. Dynamic constraints would allow objects to move relative to each other in interesting ways. There also needs to be a way to fire scripts events on collision.

Portal was awesome and the ending is fantastic.
“The cake is a lie…”

Our build servers were turned back on over the weekend. They weren’t being used because we have drastically changed how our projects are built. Perforce and Visual Studio files have been replaced with Mercurial and CMake. So, I spent the weekend reconfiguring the buildbot setup Tony had on the servers. I had never configured buildbot before and I was surprised to find it was so easy. I only had to change the repository location and build commands on the buildmaster server. I didn’t have to touch any of the build slaves.

This time around we’ve got both linux and win32 versions of C2 building any time we want. It used to be very difficult to manage both versions of the engine. On win32 we used Visual Studio projects and on linux it was scons or make files. Any change on win32 had to be manually added to the linux project files and vice-versa. Even worse, making a change on a different platform usually meant rebooting into another operating system. With CMake there is now one build file for all platforms and it’s easily edited in a text editor.

The buildbot setup has been extremely beneficial for my linux oriented workflow. I can work on the engine on linux and have buildbot compile it for win32 without the incovenience of booting into windows myself. Judicious unittests catch many issues that can be rectified without having to run the engine proper. In the worst case I rdesktop into our win32 build server from linux and run Visual Studio to fix any build problems. Unfortunately the build server doesn’t have the graphics hardware required to run the engine outright so I still have to boot into windows to test the actual game.