Past unit testing to game play

I've been playing a game of catching up with unit testing and features. But after having written unit tests for XML, geometry optimizer, particle manager, and various minor tools, I feel much more confident about the code base as a whole. There are more components to be tested, such as Physics and Scene tools. They are still need to be refactored a bit to remove inter-dependencies. Mm... still need to think about this.

However, I'm not writing only unit tests at this point, I'll still pushing forward with getting second demo done. Nothing major needs to be implemented at this point. There are a few minor and annoying things to be dealt with. Things like incorrect aiming when the tank tower is not horizontal, or hitting your own tank when launching a missile from the gun.

A few mode models, a little bit more exciting level design, and second demo will be rolled out. :)

Migration to Xerces from TinyXML

I have recently migrated from MSVC 2003 to 2005, because I saw it fix and improve lots of things that I could barely stand in 2003. There was a drawback of course. My xml wrapper refused to work in release but worked well in debug mode. The implementation sat on top of tinyXML, which seemed to have problem with using latest MS SDK. So I figured it was the right time to move away from tinyXML to Xerces-c. Now I do not recommend choosing Xerces-c as an easy to start with xml library, but it certainly is powerful nonetheless. It took a bit to understand that it had some rather weird approaches to handling strings. Now I can understand having to encode strings into a format that support various encoding and such, but the usage of those character arrays is simply bad. A user must be constanly on look out for cleaning up decoded and encoded character arrays. I did a few things to make my life easier with it, but still it did not feel right.

The good thing is that unit tests helped me out to ensure that the wrapper works, so that now I can forget about Xerces-c lame duck interface, and hide behind XML tools that I have written on top of it.

Overall, it took only about day and a half to complete migration which is pretty good considering that I have not worked with Xerces-c beforehand. Xerces-c is not bad, though, don't get me wrong, there are plenty of good things like easy DOM parsing and XML tree browsing, but you need to watch your step, because there are plenty of hidden traps in its workings. But the main problem was almost complete luck of decent documentation. Website did not have any examples, instead sending you to download the examples that come with the source. Those examples weren't bad, but almost none of them were simply. It took some critical thinking to figure out what I need and what I don't.

I tried to find some tutorials for Xerces-c but could not find any. Very dissapointing. Xerces is one of the Apache components, and yet lucks useful documentation. And worse, it seems that there isn't any community around it to help out newcomers.

In conclusion, Xerces-c is good enough to be used after climbing its high wall, but it does not provide nice interface ( complete C++ and STL would be really nice ) and lucks documentation and community support.

Unit Testing

Unit testing is an old concept that has been around long before computers came to life. You test what you make to ensure its quality. I have been putting off serious unit testing in this project for a while now. But lately I decided it was time to start writing complete unit tests to ensure quality of the project.

One of the last drops was a recent performance bug, that I have not nailed, so unit tests are coming to aid.

I started from simple components: math and XML tools. Next turn will be graphics and physics components.

I am using a very simple and handy QuickTest written by Tyler Streeter. Many thanks goes to him.

Physics Optimizations

OPAL sure provides a lot of features, but I had to utilize it to the outmost to get the size of the simulation that I wanted.

First of all, grouping objects was essential for performance. So, for example a building would be made out of various blocks, which usually stay close to each spatially, so they can be grouped and their collision be optimized, because instead of checking for every block, collision can check their bounding box for the entire group. This is how ODE, physics engine, optimizes collision checks.

Second, OPAL is awesome that it can rebuild objects on the fly from static to non-static type. I used this feature to make sleeping objects static. And static object take the minimum processing power during collision.

With the above optimizations I was able to easily handle scene made out of 2000+ boxes. On the screenshot, you can see the system in action. Note that this is running on NVidia 5200 Go on a laptop, so performace is decent.

The third point is not implemented yet. Its goal is to stabilize some shakiness of the vehicle caused by a dozen of joints, which ODE does handle well at certain configurations. It will dampen small linear and angular acceleration at small values.

Simple XML tool in C++

XML is really a great format. It gives a lot of freedom. I can define any structure with it.

And this is really useful for game development. Especially in C++. Its build times are rather long, so storing and modifying parameters inside the code is not very useful. Testing and experimenting takes a long time in this case. If, however, the data is moved out of the code, as it should be done, the problem of performance is gone. Just go to your favorite XML editor, edit the data, save, then and simply restart the application without any recompilation.

So, I have tried to move as much as I could to XML files, so long as it did not take away a lot of time to do so. One of the things that I had stumbled upon was uneasy reading of XML files in C++ libraries what were available to me. In particular, I used tinyXML. However, reading many small and simple files across the entire framework took just too much effort for its price. So I figured it was time to create a simple wrapper around tinyXML. This way I could expose just enough features that I need, and thus keeping it very simple.

The product is the following: XML tools: a simple reader and looper of simple XML files. See their examples for yourself.

Boy, that really made it very easy to use XML anywhere. One line of code for one value from XML file. Quiet perfect.

Switching to Artificial Intelligence

I have switched from working on TrueAxis plugin for OPAL to designing some basic AI, because it was taking a bit too much time. And I feel that it is more important and productive to construct some basic scene and start working on the game play.

The thing about game play is that it is really hard to develop it unless there is an enemy to fight with. Here, I had two choices, either implement networking or develop some AI. Network is kind of ready for further developing, but I decided to go with AI. I had a few ideas ready to go.

At the moment I am working on navigation for AI. The current implementation does not require static environment, which is perfect for destructible physics of Ukrainian Rumble 2. It also does not require precomputation. The drawback is the luck of scalability, since at the large number of objects, navigation may become CPU-intensive. This however should only appear at a really large scale environments. It could be resolved though via use of octrees.

The navigation is near its finish. Vehicle control from the navigation recommendation is still being tested and fixed, but it is operational nonetheless. Once it is done, the easy step will be control of a tank tower to aim at the target and fire. This will be much simplier than navigation, though.

Soon, the scene creation will begin: the campus of the University of Louisville, KY.

TrueAxis as a new physics engine

Lately, I have been working on new physics engine to replace a rather outdated ODE physics engine. ODE did a good job of starting the project, but its limitations have started to bog down the performance of the game.

What are those limitations? The main ones are inability to handle a lot of sleeping objects. That is, let's say we have 1000 boxes laying around the scene, while we control a tank moving around. A decent engine will be able to quickly parse out which objects need to be tested against, but in ODE collision detection is not optimized, so the product is poor performance. This is important, since I do expect all scenes to be like that: lots of sleeping objects. The second reason is instability: sometime ago I had to tweak things nicely to have more or less stable environment. But still I am running the simulation at 100 times per second, just to keep things from bouncing too much, yet it is still visible in demos. This is not only annoying but also eats up CPU.

Why TrueAxis? I had several requirements when choosing an engine. First of all, it has to be stable and perform well. Most engines other than ODE already do that (although not always for free). Second, it must support Linux. It is really hard to give up ability to develop under Linux. ;-) This cuts options down to two engines: Newton and TrueAxis. Now, this choice was easy since two engines seem to have gained a certain personality: Newton with correct physics (but slower?) and TrueAxis with handling of fast moving objects (but less correct?). My choice was a better performance for a price of less precise simulation and with an option of using super fast objects for missiles.

Any programmer out where will think: "Gee, moving to a different API, good luck on migrating your project." Luckily, I have foreseen this, and so used an abstract physics layer: OPAL. This way all I need to do is write a plugin for OPAL, without changing a single line of code in Ukrainian Rumble. Well, maybe some parameters would need to be changed around but that is handled in XML configuration files.

So, for the past 3 weeks I have been working on this plugin. It is not really hard but is time consuming. OPAL provides a lot of features, and I do use a lot of those features, so even though I implementing only stuff that I need, it will still take a bit. But I am getting close to a certain milestone: just a few things left to do.

Clean up stage.

After having added particle effects for any broken joint, and thus any destructive event, I have distributed the link to the latest demo around Internet to get some feedback. Maybe people are just nice, but the comments were generally positive. What is more important is that I have received a number of suggestions about the direction of the effects and features that I should push in. Many thanks to those folks.

One of those ideas have led to think of a way to overcome GPU bus bottleneck. Here is what it was: GPUs have been developed and optimized to handle large chunks of mesh, however, it does hot handle well, large number of meshes. 10000 triangle in one mesh is MUCH better than 10000 meshes with one triangle. Here's a link that describe this in more depth.

Why is this important to URumble? Because the physical simulation is bound to have many independent objects, thus meshes. So, this is has to be dealt with somehow. Luckily, the framework allowed an easy implementation of the idea. Tanks in the recent demo are represented as a complex object consisting out of a dozen independent objects. Here is what happens now: once a tank goes to sleep (all its bodies stop moving around) its meshes are build into static mesh, and this new mesh replaces old separated meshes. The only downside is extra memory usage, and slow downs when builds large meshes.

Overall, the approach brought a huge performance boost, sometimes it doubles the frame rate! At the moment I am considering bringing this method to a large scale, when the entire parts of the scene will be built into static meshes. This will require some special division of the environment, possibly via use of octrees.

Other than that, a lot of time has been spent into cleaning up the framework and its interfaces, which led to creation of a few minor tools. More are scheduled to come as they approach a certain level of usability.

After CGAIMS

The conference was actually quite a lot of fun. If nothing else, it is nice to meet people who speak and think on about the same wave lentgh as you. There was one physics related paper and a few on computer graphics, but most of them were on AI in games and just in general. So, I got a few ideas to look for when I get to coding in AI into Ukrainian Rumble.

Unfortunately, network did not make it to the conference. We had only an off-line (singleplayer) version to show.

Couples of demos were created: a hammer and a line scene. For more info about them, check this page.

At the moment, I plan to release this version onto Ogre forums, but before I do that, however, I would like to make a few graphical improvements to localize it for the Ogre community (my guess is that guys and gals there like graphics ;-) after all it is a forum for a graphics engine). The new feature that I want to add is actually quite simple, which is why I am willing to do it right now: add a particle effect for any joint break not just ones caused by a missile collision. This should greatly improve visual look of the hammer falling down on top of vehicles.

CGAIMS

The paper work has been completed. The Ukrainian Rumble is coming to CGAIMS 2005 at Louisville, KY, USA. The conference's website is right here.

Long story short, I have two weeks before the conference. There is plenty of stuff I want to show on the conference. Most main features have already been implemented, but there are a few rough corners that stick out, mainly vey poor ground - nothing but bunch of plains stuck together in order to form a ground.

The reason this sticks out is because the robots have decent models with couple of different particles to represent smoke and small explosions.

Of course, network are still coming, the client side is mostly done. It still needs to be connected to the server, though. At the moment the server does not anything other than ignoring all incoming packets but the ones that are send during the connection and disconnection of a client.

Summer semester is almost over, and the free time is here to help me.

Blog has been created.

This blog will be a journal of my development of Ukrainian Rumble 2: "Heritage", a Multiplayer Mechanical Shooter.

For details, visit the homepage of the project.