My good friend Mike has for many years had a pet gaming project called Caster which he has worked on in his free time for graphics experimentation and his own entertainment. And for almost as many years I have been working with him to port it to various platforms such as Mac OS X and iPhone OS (as of this writing I am currently poking around with a Dreamcast build of Caster). Recently Mike gave a presentation we co-authored called iPort: How to Bring Any C++ Game to the iPhone at the GDC Austin 2009 iPhone Games Summit based on our experiences with porting Caster to the iPhone. Even before the GDC presentation Mike and I thought it would be cool to write a postmortem on porting Caster to the iPhone. At the time we thought we could turn it into a blog post or web article or something. After being accepted into the iPhone Games Summit at GDC we adapted a lot of the notes and material that we had produced for the postmortem into the presentation slides. The presentation went well and the slides were jam packed with a lot of good tips and tricks for both iPhone porting newbies and experts alike. However, I thought it would still be fun to use the original material to organize a story-like postmortem.

After a long time coming, Caster 1.1 for iPhone was released about 2 weeks ago to the App Store. A lot of care has gone into listening to feedback and deciding what can be addressed now. It is a really nice update that should be a delight to existing customers and more enticement for new purchasers. Changes include:

• The first three levels of Episode Two are playable.
• Caster theme music cover by Mega Ran.
• Controls tweaked to fast-paced shooting perfection.
• Customizable draw distance (for people with the new 3GS or iPod Touch).
• In game menu re-arrangement (to avoid hitting menu buttons inadvertently).
• Tweaked visuals like the lifebar.
• Small gameplay tweaks.

We learned a lot at GDC Austin 2009 about iPhone optimization, development and marketing strategies so be on the lookout for more updates in the future with improvements with regard to both technical aspects and content.

My good friend Mike has released his 3rd person action game Caster on the iPhone App Store! The entire desktop experience has been faithfully reproduced and tuned for play on the iPhone with remarkable performance. The game is really fun on the Mac and PC but it really shines on Apple’s handheld devices. The graphics performance is amazing and the relatively complex control scheme has has been adapted perfectly for the touch screen without sacrificing any functionality and is arguably easier to use.

If you are a fan of fast paced action games be sure to grab Caster. I think you will dig the gameplay and love the unique pseudo Mega Man/Anime art style. It is only $5 but there is also a free Lite version with one playable level if you want to give it a test drive first. The best part of all is that the value of your purchase will increase over time as it updates with episodic content for free.

At long last my friend Mike‘s game Caster has been released to the world! It is available for both Mac and Windows as a free demo or for $9.99, a full version with episodic content. Caster is a fast paced third person action game featuring fun weaponry (such as terrain deformation guns), nifty music and slick graphical effects. Mike has really poured his heart into the game and it is truly impressive to think that one person engineered and authored almost every aspect of the it. Yours truly handled the Mac port of Caster and it was a really great experience to watch Caster grow up into a full game. I am looking forward to seeing where Caster will go in the future!

My friend Mike over at Elecorn has been working hard for a long time on an action game called Caster. Fairly early on I started maintaining the Caster Mac OS X port and have had the unique opportunity of experiencing the game evolve over its development cycle. Caster has really matured into quite a fun and graphically impressive indie game. Mike has made use of a lot of neat techniques that produce slick looking graphical effects without shaders or vendor specific extensions. This emphasis on back to the basics GPU effects means that Caster runs pretty well even on older systems and doesn’t break compatibility across GPU vendors or even operating systems.

For the month of November, Mike has instituted a Caster fan art content. Caster itself has a neat feel to it and I am looking forward to seeing what people come up with. The winner gets to have their art featured in the final build of the game as well as a free copy! So if any of you out there have an artistic streak in you, see what you can come up with and it might get published in the game!

I have spent quite a few hours with the iPhone SDK now and must say that I am quite impressed. The experience of bringing some of my code written for Mac OS X over to the iPhone with no changes and having it just work is quite a pleasant experience. I REALLY enjoy being able to use Objective-C 2.0 synthsized properties and fast enumerators in my code (garbage collection would have been nice but hey, this is a mobile device). I maintain Tiger support for Language Aid and develop purely for Leopard in Razor and it is kind of an interesting mix of both to code for the iPhone. I am really excited to to flesh out a game I have been thinking of for the iPhone that would take advantage of a lot of its unique features.

So the posted requirements say that this beta version of the SDK requires an Intel Mac but so far I have not run in to much trouble developing with it on my G5 (the only Intel mac in the house right now is a Core Solo mini which is already pulling duty as a source server, build server, DVR and media center). Inspecting the simulator and the xcode plugins show that they are all universal binaries. The only gotcha that I ran into is that I had to make sure that in my build settings that the “Architectures” setting is set to “Native Architecture of Build Machine” so that the binaries produced are ppc so that the simulator (I have heard a surprising number of people errantly referring to it as an emulator) can load and run them. For some reason this reset itself to i386 one time and I had to track it down to that setting.

Other small quirks that may or may not be related to me running on ppc are that it seems like every 10th click event or so on the simulator window seems to fall through and hit the window behind it. Also, for some reason the simulator is also not responding to the “Rotate” commands whereas it would correctly respond on my Intel mini. Of the example code on the developer website there are a lot of projects that will not run in the simulator due to a pragma that intentionally errors itself out if built targeting the simulator:

#if TARGET_ASPEN_SIMULATOR
#error This application cannot be run in the Aspen Simulator. Please change Active SDK to "Device" and ensure a device is connected.
#endif

Simply build the sample using Xcode and run it on the device (OpenGL ES is not supported in the simulator).

It is inevitable that I will plunk down the $99 to be able to perform remote debugging/use Instruments/use Shark with a real iPhone. However, for now while I am busy bringing up the core game engine and getting used to the new platform, the simulator is doing just fine.

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.