I think it’s about time to issue a KoboldScript status update. KoboldScript is Lua scripting for cocos2d, in case you didn’t know. In the near future it’ll be released as part of the KoboldScript Game Kit project. I showcased KoboldScript before here and here.
Static bindings, manual labor
One big advantage of KoboldScript over other script language solutions available for cocos2d is that the KoboldScript binding is static, ie it is done at compile time. There’s very little runtime overhead to it, thanks to SWIG. So in terms of performance it’s miles ahead of Wax, LuaCocoa or other dynamic scripting language bindings like JSCocoa. And it is compatible with both Mac OS X and iOS.
The big problem with static bindings is that you have to somehow define each class, each method, each property and write lots of glue code. In the past, I did this manually. It involved writing a C wrapper method for SWIG and usually an Objective-C dispatch function went along with it. On the Lua side the function needed to be registered as well. It’s an error prone, repetitive, boring task. Perfect for code generation! Continue reading »
I thought I’d post a very early result of the KoboldScript scene setup. This scene was scripted entirely with KoboldScript with about 50 lines of code:
Below you’ll see the part of the Lua script that created this scene. In fact it’s not so much code as it is defining data, which behind the scenes calls the node functions like setPosition and setColor for you. Continue reading »
Chapter 9 - Particle Effects
Those tiny specks which you can see on your touchscreen after a sneeze.
Not exactly. Of course I mean the cocos2d particle system and its built-in particle effects which will be the focus of this chapter. And no discussion of particles would be complete without describing the workflow revolving around the Particle Designer tool.
Summary of working on Chapter 8 - Shoot ’em Up
This certainly wasn’t the easiest chapter for me to write. I had very ambitious goals, maybe too ambitious for 27 pages. I did manage to sneak in quite a lot though, here’s a partial list:
- how to refactor existing code to make it work better with the new features
- how to pool bullets and enemies together for easier access and better performance
- how to not use too many subclasses, instead relying on type switches
- how to use cocos2d’s node hierarchy as a simple component system for writing reusable game logic components
- how to implement basic movement, shooting and a healthbar as components
- how to detect collisions between bullets and enemies
The not so easy part was striking the right balance. Not going too technical. Not doing too much at once. Not dividing things into too many tiny pieces. But most of all I frequently encountered various bugs in the code, or just unexpected behavior of cocos2d which forced me to spend more time debugging and sometimes backtracking changes than I was prepared for.
After a long and hard work week, paired with physical exhaustion and an late-summer allergy burst, my concentration didn’t allow me to work at 100% capacity. In the end I did manage but it took longer than I had planned, I’m over a day late to submit this chapter. The next one will be easier though, and it has to be as I’m preparing for a short trip near the end of next week. I certainly am looking forward to a couple days off now. 
Chapter 5 - Getting bigger and better
The gist of this chapter will be to discuss the simple game project from the previous chapter. I threw everything into one class, clearly not what you want to do for bigger games. But getting from one-class to real code design is a big step which some hesitate to take. I’ll make that easier and discuss common issues and their solutions, such as what to seperate, what to subclass from and how you can have all the seperated objects communicate with each other and exchange information in various ways.
A big topic will of course be how to take advantage of cocos2d’s scene hierarchy and which pitfalls it may have when moving from a single-layer game to one which has multiple layers and even multiple scenes.
As for the chapter title I’m not so sure if that’ll be it. Maybe along the way while I’m writing I’ll change it. Suggestions welcome!
The chapter will be submitted on Friday, July 30th.
What’s your take on good cocos2d code structure?
Did you ever struggle with cocos2d design concepts? Or the cocos2d scene hierarchy? Or how to layout a scene and divide your game into logical parts? Tell me about it.
I know theses questions are somewhat generic to ask. It’s about the things that don’t feel right but there doesn’t seem to be a better, more obvious way. I think we all know some of those, if you do, be sure to tell me! Leave a comment or write me an email.
Summary of working on Chapter 4 - First simple game
The game I chose to make is called Doodle Drop and features dropping spiders and an accelerometer controlled alien trying to avoid the spiders. All in all it got divided into 8 concrete steps. Lots and lots of code comments, too.
It starts simple enough, adding resources to Xcode and adding sprites. It gets more gameplay-esque when the accelerometer-driven player controls got tweaked to provide acceleration and deceleration of the player object. In contrast, the spiders movements are driven only by actions.
I introduce you to two undocumented features of cocos2d, namely CCArray which is since v0.99.4 used to store all children of a node. The other are the CGPointExtension class which has all the functions normally provided by a physics engine, however not every game should link a physics engine just because one needs those math functions. That’s why CGPointExtension comes in handy.
With the ccpDistance method the collision checks are done. Simple radial collisions, and in debug mode the collision radii are drawn too.
In between the CCLabel for the score got replaced with a CCBitmapFontAtlas, because it killed the framerate. I shortly mentioned Hiero and how to use it in principle but for all the details there was no room. But while I was at it I created the Hiero Tutorial.
At the end of the project I added some polish which isn’t described in the book (too many details) but really adds to the game’s look and feel. The spiders drop, hang in there, then charge before dropping down, all done using actions. I’ve also added the thread they’re hanging from using ccDrawLine. And then there’s a game over label which shows even more action use.
One of the principles I followed is to stay away from fixed coordinates as much as possible. So the project, once finished, did run just fine on an iPad. Although the experience is a different one, there’s more spiders dropping and they drop faster but there’s also more safe space to maneuver to.
Oh and, the game art is all mine. Yes, I know … but Man-Spiders do have just six legs!
