After a long time tweaking and puttering with the physics engine I think I have finally gotten close to the kind of settings that are needed for the kind of simulation that I want (dContactApprox is the flag that finally fixed a lot of my problems). I have also introduced projectiles into the mix by adding the “Shell” class. The Shell class is actually just an Actor and is treated the same was as any other tank or other object in the game. It just so happens that tanks create shells and they initially have a great force exerted on them.

I have also put a lot more work into NSObjectInspector (probably to be renamed in the future) so as to be able to support more debugging of the plugins at runtime. I am getting the hankering to spin it off as a general debugging tool for developers because it is just so darn useful.

The idea behind NSObjectInspector is that when you debug a program sometimes you want to just change a value in an object while you are debugging your program at runtime instead of recompiling or writing some sort of user interface to interact with an object’s value. Because the Objective-C runtime affords us a lot of information about what instance variables an object has or what methods it has implementations to, we can provide a general class that can inspect other objects and provide a user interface with which to poke at them with.

Currently it provides interfaces to object instance variables, accessors (method or method pairs in the form of -(void)setMethod:(type)a and -(type)method) and commands (methods in the form of -(void)method). It currently excludes anything in the class NSObject and well known methods that have substantial peripheral effects such as -(id)init, -(void)dealloc and -(void)finalize. Currently supported values are any sort of number type and ids of type NSString. Eventually I plan on creation of class specific exemption lists as well as control hookups.

After doing a lot more research I decided that I don’t really want to implement the physics engine in Razor myself. Thus I have decided to use the Open Dynamics Engine and I am already pleased with the results. It took me about a day to hook it in (had trouble for a while because my tanks were falling through the ground because of some weird collision setting). It might take a bit to figure out how to do movement and projectiles correctly but it might not be long before we actually have little tanks running around doing battle with each other.

And now I give you pile o’ tanks:

So I have been thinking about what level of physics model I want to implement in Razor. Specifically I have been doing a lot of thinking about collision detection. There are a lot of different ways of doing things with their own strengths and drawbacks. I have initially made the decision of going for more precision and complexity versus speed and ease of computation. I have been spending a lot of time at Wolfram Mathworld trying to remember all the stuff I learned in college.

In preparation for the impending physics tests I have added optional bounding box drawing to all the Actor objects:

I looked around and didn’t immediately see any optimized math libraries that calculate determinants on the mac. If anybody knows of one please let me know. I did find this thread which had some helpful ways of doing it manually.

I actually had a very hard time thinking of a name for this project. Nothing really seemed to fit too well or sound that good. But I needed some sort of name for my new project. You have to call it something… I finally settled on “Razor”. What does it mean? Nothing. What does it have to do with the project? Nothing other than now that is what the project will be known by. After not being able to think of a name for a while and itching to just start coding on the darn thing I just picked the name and it has just kind of settled.

Ok, so what is it? On the Google Code page that it is hosted at I wrote:

Razor is a strategy game engine which is oriented around programming the AI of the units rather than direct control by humans. The idea is that human players compete by engineering the intelligence of the units under their control in order to fulfill an objective. The game world is in 3D and will employ some basic physics. Units, AI, physics models and many other aspects are extensible through a plugin system.

Razor is for Mac OS X Leopard only due to leverage of certain Leopard exclusive features such as dynamic loading/unloading of Objective-C, Garbage Collection and more as time goes on.

This is an idea I have had banging around in my head for a long time. Ever since I worked on an AI lab in college where the final semester objective was to program the AI of 5 tanks to play capture the flag against 5 other tanks controlled by one of the AIs of my many classmates. At the end of the semester the class had a tournament in which the prize was an instant ‘A’ in the class and didn’t have to take the final! My lab partner and I won the tournament and even though we both had As in the class at that point, not having to take the final exam was a big time relief at the end of a very busy semester. Perhaps I will make a blog post on our winning strategy later.

Along with that, I have always loved the great strategy involved in RTS games like Starcraft (which in my opinion is the best RTS ever made). I loved thinking of crazy new strategies that would find kinks in established defenses or play with the psychology of the other players. The only thing that prevented me from pulling off my grand designs was the limitations of my own reflexes. Some people just have the twitch and can bounce from scene to scene, keep everything in their heads at once and make lightning fast and precise mouse movements. But if the Korean Starcraft scene is any indicator, these cyber-athletes like gymnasts have a limited lifespan. Once you hit the ripe old age of 22 your reflexes aren’t what they used to be and some pretty young 16 year old is going to take your spot. What I want in some respects is AI programmable Starcraft.

Now the project is only in its infancy and is nowhere near doing anything of significant interest at this point but I decided that I wanted to get the code into an initial functional state that would at least be worthy of initial check-in. Because the project is open source I will be commenting here about the work that I am doing on it, future feature additions and other issues with great openness and frequency unlike my closed projects.

Below is a screenshot of the Simulation Viewer app that you can build and run right now from the source that is posted on the project page. It is not much but it is a start.