Why iCauldron3D?

Why iCauldron3D?

This is a good question. Why create another iPhone / iPod touch game engine when there seems to be a number of good ones out there. Well I looked at iTorque3D the price is right, you get the source and it comes with an editor. It also comes with a lot of source code that you will need to familiarize yourself with. This is not a problem for one such as I... I read code better then English. To be honest I was tempted, but then I saw it was a pre-order price. Later, when talking to a colleague whose studio currently uses this for iPhone games, he assured me that you do get it right away. It's just your part of their beta. That's fair enough and I'd still be tempted if I had not started to travel down another path already.

So next I looked at SCIO2.. Great little engine. 3D has some good games out in it.. and looks nice. However it's so reliant on Blender3D for everything and being so closely tied to Blender3D, this was a turn off as we use Lightwave currently. This would mean writing a Lightwave layer and stripping out all the Blenderness.

So next on the list was Oolong. Nice engine again. Pretty bare bones. The demos are good they show up to 60,000 polys rendering at speeds of over 50 FPS. The engine is all in C++ with some Objective-C++, of course (.mm files instead of .m). It's pretty bare bones and is good to look at to learn different specifics about iPhone OpenGLES development. Documentation is lacking which isn't really a problem. Examples are good but there seems to be some core simple things missing. For example; device orientation. Most of the examples run from a left rotated device orientation, and yet this is not set in the application. You just need to tilt your device. It left me wondering why and what sort of other stuff was like this. One of the examples that attempts to use VBOs in an expensive way (uploading every draw cycle) left me wondering what else was like this. Honestly I can't complain about this engine, but I really didn't want to review all the code.

The engine which will remain nameless.. Price is insane for what it is, you must by a pro license for the main desktop engine and THEN buy a pro license for the iPhone. In Canadian dollars this will run you about 4K. The two license requirement is ridiculous, if all you want to do is iPhone development. Also you get no support and no source code. Well after my experience with our desktop game that uses this engine, I will NEVER get into an engine again where we don't have access to the source code. Memory leaks, performance problems in which I have no control over and no support to get fixed, things that if I did have access to the source I could fix easily. As well it's based on a bloated library in which they blame ALL their problems on. Well in my day as a developer, we just didn't have the excuse of blaming a library or SDK for our problems. Business side would just say "You chose it, no one held a gun to your head, so take responsibility for it and fix it". Beyond the fact this library is opensource, they can't be bothered to take responsibility for it and just shrug their shoulders and focus on PR propaganda to say how great they are. Personally if they spent that time, effort and money just improving their product it'd be much better and benefit their current customers that they ignore. Enough said...

Next I looked into Cocos2D an excellent 2D engine, all in Objective-C, great clean coding, easy to follow, good documentation and great community. However the name says it all - Cocos"2D" and we wanted to be able to do 3D or at least 2.5D. So we thought maybe 2D would be better. So off we went. Creating sprite sheets was easy, I could use our current 3D models and export key frames to a single image and generate a sprite sheet. Though looking at all the angles we wanted, quality and so forth, we saw that it would take up less space and less memory to simply use the 3D models directly. As well creating the sprite sheets would leave some fringies which Teri had to clean up. To do all our characters in all their positions, including monsters would be time consuming and texture-wise take of up a lot of space. So down this path with Cocos2D we went. I brought in our 3D skeleton based skin meshed animation system. Next I had to bring in zip 7 compression to keep the mesh files and animation files small. So initially we were at a 30M install and with zip7 down to a 6.7M install. However this is a 2D engine, which doesn't have support for 3D transparent meshes. Sure I could hack something in and own the source code that way. But why? There are many features within Cocos2D that we just wouldn't use and re-architect Cocos2D to support 3D just started to make less sense. One of the pains I started to run into, is I had to maintain two sets of world coordinates; one for Cocos2D features and one for the 3D world. Cocos2D sets the the 2D images very far away from the camera view, which is ok if your not using lighting. But once you start introducing lighting and shaders for 3D objects it may look great on the emulator but on the device itself it looked terrible.

Now we come to iCauldron3D. None of the above engines really fit our needs and requirements to the exact specifications for the game we wish to make. As well we wanted to offer modding to our customers to extend gameplay. I've always wanted a game engine in C, no C++ no C# just the straight pure speed and power you can get from well written C code. I've been programming in C for 29 years and not just as a job but as a hobby as well. A lot of great things are made in C today, and when dealing with embedded devices you really want to get as much out of that little processor as possible. Secondly I though about other developers who do iPhone / iPod touch games more as a hobby. What if they could edit their game and levels right on the device? So while commuting to work or school or standing in a shopping mall, you could work on your game. Sure it would be lovely to have XCode right on the device, but now we're just getting a little crazy. Over the past 5 years I've developed and built on a solid custom mesh format, custom animation file format and skeleton based skinned mesh animation system. It was written all in C with the intention for cross platform development. Most of our games have focused around the features within this system; up to 32 mount points per character and 200 bones on average with up to 400 bones for high poly characters with little impact on speed performance. As an animator and programmer it as given me a unique perspective on this process and pipeline. As well I've had to write and maintain exporter plugins, converts and so on.

iCauldron3D Logo

iCauldron3D was born. When I described the types of features we were looking at, the image of a melting pot or Cauldron came to Teri's mind and since it's aimed at iPhone / iPod and eventually iPad devices it only seemed logical to call it iCauldron3D. It's a mixing pot for game developers, to put in their ingredients for their game, light the fires of imagination, boil it up and presto like magic have a game. We decided to opensource the engine under zlib license since we have benefited from opensource projects over the years ourselves.

Being a maintainer of Irrlicht for OSX some have asked why not Irrlicht? Well to start with the person who did the initial port to iphone, sat on the code for over a year promising to contribute it back. When they finally did the code is broken. Sure I could dig though the code and fix it and deal with any other issues that may come up. But why? Sure irrlicht offers many features loads many file formats, but those are not features we want for our iPhone game. Also it's all in C++ which is fine, but does have some overhead costs. Certain performance issues would have to be dealt with (needless tight loops and too many of them). Irrlicht is great for desktop and anything that has power to run it. But it lacks in an Editor, irrEdit which seems to be dead, just doesn't cut it. And it's also Windows only, kinda pointless with iPhone developed on OSX. So to use Irrlicht would mean stripping it down and rebuilding parts specifically for iPhone in mind. But as I said before I always wanted a C based engine.

sprite wink

Once we launch iKrabbit we'll be uploading the source for iCauldron to SourceForge, the page is already setup, domain is already registered http://www.icauldron3d.org. Be expecting to see this launch within the next month.