What is Kobold2D?
It’s the Ultimate Cocos2D Project, of course. Or more precisely, the official name for it. Right now, the website www.kobold2.com is only a “coming soon” page while development is under way.
What’s in a name?
Calling it “The Ultimate Cocos2D Project” all the time would have become tedious rather quickly. I wanted a name that is reminiscent of Cocos2D yet completely different. As luck would have it, I’ve recently watched a lot of Battlestar Galactica episodes. You might remember that in this show humanity’s home planet is called Kobol. I couldn’t help but think of COBOL all the time. 😉
From there it was a small step to Kobold, which in germany is widely associated with a famous cartoon Kobold called Pumuckl. As a kid, I was a big fan of Pumuckl, so picking Kobold2D as the name was a no brainer. Even more so since it has the same ring to it than Cocos2D.
Why create a new brand name?
For one, giving the project a name of its own clearly makes it more attractive. It expresses a certain dedication to the project. It should also signal that it’s no longer just about Cocos2D. With all those extra libraries and additional glue code, plus an experimental project I’m working on, I’m tempted to call it a Game Development Kit (GDK). That’s the long term vision for Kobold2D: more power, easier - for everyone!
Speaking of long term, that’s another reason to give it its own brand name. The visionary thought being that ultimately, something like Kobold2D could be implemented for other game engines as well, with the same core values: give the developers more power, greater flexibility but at the same time make it easier for them to get started.
The Kobold Team
I’m not the only developer who is aching for a more professional work environment. Kobold2D is a joint-venture with another senior software developer and a couple helping hands who help out wherever and whenever they can. We agreed to share the development burden on a voluntary basis. We all have different stakes and interests in the development of Kobold2D.
For me personally the most important aspect is my ambition to develop a project for its users, both professional and casual. I know I can build professional systems that are easy to use, well documented and thus get the job done painlessly. This basically sums up what I’ve been doing for the past 10 years.
What we’re not doing …
There’s one issue I think i going to come up, which might confuse some people, so I want to be clear about this: we are not creating a branch of Cocos2D. We have no intention to do so. We use the library as is, and we stick to the stable builds. The same goes for all other libraries of course.
At the same time, we don’t push each and every line of our additional code back or even contribute to the development of the libraries in Kobold2D. That’s not what we set out to do, and we simply don’t want to spend too much time consulting with and compromising on changes with others when our code is already there and working for us. Our code uses the MIT License, so it’s there for the taking.
In very few cases we can’t get around to modify library code. We only do this where necessary, for example if it breaks our build and the fix is rather simple. Other than that, if a library doesn’t work to our satisfaction, we try to add our fixes and improvements on top, either by subclassing or by making use of Objective-C categories. So far this has been working very well and allows us to keep updating the underlying libraries with far fewer hassles.
Next steps
One big task that I set myself out to complete before continuing with Kobold2D is figuring out the Xcode 4 template format for File Templates and Project Templates. I almost have everything together after spending practically the whole week on it. I’m also documenting all my findings and I’m going to publish the Xcode 4 Template Tutorial / Reference / Documentation / Manual (not sure about the name yet) by the end of the month.
The goal for Kobold2D is to have various project templates, which is why I’m doing extensive research on the new Xcode 4 template format. Unfortunately at the moment it seems that it will not work satisfactory with cross-referenced Xcode projects, but I remain positive that I can find a solution.
Kobold2D private beta!
There will also be a private beta test for Kobold2D starting in a couple weeks (couple == definitely more than 2 weeks). Reply to the private beta sign-up thread if you want a chance to be picked for the private beta test.
The Ultimate Cocos2D Project is: Kobold2D!
Put simply: Kobold2D is designed to make Cocos2D developers more productive.
Original Post
Time for a weekly update. This time about startup code and configuration. One of the things that I frequently encountered following the development of Cocos2D and working with it, is how any change to the startup code - the main function, the App delegate and the root ViewController - caused issues and headscratching among developers.
I decided it doesn’t need to be this way.
The main() function
A code snippets speaks more than words:
[cc lang=”ObjC”]
int main(int argc, char *argv[])
{
return KKMain(argc, argv, NULL);
}
[/cc]
That’s right, all of the startup code is now part of the project’s source code. You can still do whatever you need to do before and after the call to KKMain (probably nothing, except maybe anti-piracy code). And the third parameter (NULL) to KKMain is reserved for future use, to pass in any configuration parameters if the need arises.
Let’s see what KKMain does:
[cc lang=”ObjC” height=”650″]
int KKMain(int argc, char* argv[], SMainParameters* userParameters)
{
SMainParameters parameters;
initMainParameters(¶meters, userParameters);
#ifdef __IPHONE_OS_VERSION_MAX_ALLOWED
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
#else
// Mac OS X specific startup code
[MacGLView load_];
#endif
// This makes the CCDirector class known to wax:
[CCDirector class];
// wax setup is sufficient for all intents and purposes
wax_setup();
[KKLua doString:kLuaInitScript];
[KKLua doString:kLuaInitScriptPlatformSpecific];
[KKLua doString:kLuaInitScriptForWax];
// This loads the config.lua file
[KKConfig loadConfigLua];
// run the app with the provided general-purpose AppDelegate which handles a lot of tedious stuff for you
#ifdef __IPHONE_OS_VERSION_MAX_ALLOWED
int retVal = UIApplicationMain(argc, argv, nil, parameters.appDelegateClassName);
[pool release];
#else
int retVal = NSApplicationMain(argc, (const char**)argv);
#endif
return retVal;
}
[/cc]
The usual, really, except that it also initializes Wax and thus Lua for your App as well as providing the necessary startup code for both supported platforms: iOS and Mac OS X. The KKLua class is an Objective-C wrapper around the most imortant Lua functions, most notably it has the doString and doFile methods which allow you to run any Lua code or file containing Lua code.
KKConfig is a class that loads a Lua table and stores it in a NSDictionary for fast access to Lua parameters at runtime. I’ll discuss it in detail another time. The main purpose of KKConfig is to loadConfigLua, which loads the config.lua script returning a table containing startup parameters and making those parameters available to Objective-C.
Config.lua in detail
Let’s have a quick look at an excerpt of the config.lua file. It contains all of the startup parameters a developer using Cocos2D would ever want to tweak in a conveniently editable Lua script:
[cc lang=”Lua” height=”400″]
local config =
{
KKStartupConfig =
{
— load first scene from a class with this name, or from a Lua script with this name with .lua appended
FirstSceneClassName = “GameScene”,
— set the director type, and the fallback in case the first isn’t available
DirectorType = DirectorType.DisplayLink,
DirectorTypeFallback = DirectorType.NSTimer,
MaxFrameRate = 60,
DisplayFPS = YES,
DisplayFPSInAdHocBuilds = NO,
— Render settings
DefaultTexturePixelFormat = TexturePixelFormat.RGB565,
GLViewColorFormat = GLViewColorFormat.RGB565,
GLViewDepthFormat = GLViewDepthFormat.DepthNone,
GLViewPreserveBackBuffer = NO,
GLViewMultiSampling = NO,
GLViewNumberOfSamples = 0,
Enable2DProjection = NO,
EnableRetinaDisplaySupport = YES,
— … and many more settings!
},
}
return config
[/cc]
Since you don’t want to guess what those settings mean, I’ve documented them for you:
Config.lua Parameter Documentation (PDF)
This should also illustrate the kind of documentation I’m striving for. Documentation will be available online. It’s created in a Confluence Wiki with the help of ScreenSteps for more visual, step-by-step documentation.
App Delegate & Root ViewController
You may be wondering how you can modify and tweak the App Delegate and Root ViewController if they’re both part of the distribution, rather than copied into each project? That’s actually very simple: both are regular Objective-C classes, so they can be subclassed and methods overridden as needed.
Both KKAppDelegate and KKRootViewController provide a default implementation which you can tweak with the config.lua parameters. If that shouldn’t be enough, for example if you have to plug in some 3rd party code into the App Delegate, each project will have a subclass of KKAppDelegate and KKRootViewController in which you can override any of the UIApplicationDelegate and UIViewController protocol methods. Usually you would first call the super implementation, unless you want to entirely replace the default behavior.
The KKAppDelegate method calls one specific method called initializationComplete at the end of the delegate method applicationDidFinishLaunching. This allows you to run any custom code right before the first scene is shown. You can use that to call the CCDirector runWithScene method manually, in case you have more than one scene which might be run as first scene depending on certain conditions.
If you set the FirstSceneClassName config.lua setting, the project will first check if there’s a classname.lua file. If so, it will run this Lua script, assuming it contains the implementation of the first scene (more on that some other time). Otherwise it checks if there’s an existing Objective-C class derived from CCScene with that name, and if so allocates and initializes this scene and calls runWithScene for you.
In essence
From your point of view, the execution of the App now starts with the first scene, before that there’s no code that you’ll have to concern yourself with. Any startup configuration tweaks that you need to do can be done comfortably via the config.lua file, and the only setting you’ll need to change is the name of the first scene’s class name or Lua script. In addition you’ll get access to some features out of the box, for example adding iAd banners is now a simple on/off switch.
Moreover, any time there’s a change in Cocos2D’s startup code, or the startup code in any other library (most notably Wax), I can just make those changes for you and release a new version. This isn’t something you need to concern yourself with anymore, and makes upgrading existing projects to new versions of Cocos2D and other libraries even easier.