Kobold2D v1.0 is now available from the Kobold2D Download page!
This is mainly a maintenance release, I found and fixed all the bugs that had been reported, including some nasty linker issues that occurred with a preference on Snow Leopard. Kobold2D is now thoroughly tested with Xcode 4.0.2, 4.1 and 4.2 under Snow Leopard and Xcode 4.2 under Lion.
Of course the latest updates of cocos2d-iphone-extensions 0.2 and cocos3d 0.6.3 are also included.
And I can’t say it often enough: Kobold2D supports ARC (automatic reference counting) out of the box! There’s nothing you need to do! Just have Xcode 4.2 installed and start writing code without retain, release and autorelease ever again.
Forward Looking Statement
The motto for the next updates is still “Get Connected!”. I want to add more online features and update the KKGameKitHelper class with remote config support provided by AppMynx. I will evaluate ShareKit and hopefully be able to implement that with (if necessary) a reasonably simple interface for Cocos2D apps.
I also have a commercial product for iOS in development that will make sending data over the network a lot simpler. The basic idea being that if, for example, you want to synchronize a sprite’s position and rotation properties with all other devices, you simply write something like this:
[cc lang=”cpp”]
[KKConnect addSharedObject:self
identifier:@”Player1″
properties:@selector(position),
@selector(rotation),
nil];
[/cc]
It works with any properties (except id/pointers). Whenever one of the property values changes, its value is sent to all connected devices and assigned to the property of the local object with the corresponding “Player1” identifier. Dead simple. And coming soon.
Learn Cocos2D Game Development with iOS 5
It’s also no coincidence that the print and PDF versions of the Learn Cocos2D Game Development book (2nd Edition) are available since a few days.
The book uses Cocos2D v1.0.1, the chapters have been significantly improved, Chapter 3 is almost a complete rewrite. There are also two new chapters discussing integration of UIKit views in a Cocos2D app, as well as adding Cocos2D to an existing UIKit app. The other new chapter is about Kobold2D and introduces Lua and Cocos3D.
Readers keep asking me when the Kindle or iBooks versions of the new edition will be out. To be honest: I don’t know. But I’m confident that there will be a Kindle version and one for iBook eventually, and I expect these to be available soon. After all the first Edition is also available through these channels, and so are most (if not all) Apress books. Plus Xmas is coming, just like most companies book publishers are eager to get their best products out the door in time for Xmas.
This is just a quick report that my recent efforts on Kobold2D and on other fronts seem to be paying off. I looked at the sales of my Line-Drawing Starterkit over the past couple months, and I noticed a pleasant trend:
Many thanks to all supporters and customers! Continue reading »
The Ultimate Cocos2D Project is: Kobold2D!
Put simply: Kobold2D is designed to make Cocos2D developers more productive.
Original Post
Last week I wrote that I’m Building The Ultimate Cocos2D Xcode Project. In today’s weekly update I wanted to give you some more details on the use of libraries in that project.
Cocos3D included
So there happens to be a Cocos3D now. Rather than being part of the Cocos2D distribution, it’s an extension project. Guess what that means? Right, installing Cocos3D means fumbling with the dreaded install-templates.sh script (see this Cocos3D tutorial). Of course the first user reactions were: how do I install it? Installation failed, what am I doing wrong? And so on …
The Ultimate Cocos2D Project wouldn’t be ultimate if it didn’t include Cocos3D out of the box. And unmodified of course, as with all included libraries I want to make it as simple as possible to replace one library version with another. Once you get to half a dozen of included libraries, maintaining them all can become a hassle, so the very least I can do is to make it easy for everyone to upgrade specific libraries.
Obviously: Cocos2D included
Of course Cocos2D is also included as a static library as opposed to cluttering your project with all of its source files. Xcode project references make it very convenient to add external code and keeping it seperate. I’ve described the process in detail in my Cocos2D Xcode Project tutorial but since then I’ve learned a couple more things about how to make this even better.
For example, I no longer include cocos2d-iphone directly, instead there’s a seperate Xcode project in between so that I have full control over build settings (using XCConfig files) and make it possible to build both iOS and Mac OS targets in the same Xcode project. I will also include the current version of Cocos2D in the download because my goal is to make everything work out of the box.
No fumbling with install scripts, no additional downloads necessary, no need to modify any Xcode build settings - including developer certificates and header search paths. Build configurations for Ad Hoc and App Store release builds are also included, which will create .IPA and .ZIP files for you ready for Ad Hoc distribution respectively upload on iTunes Connect.
Popular libraries included
Now let’s get to the juicy part. Early on I realized that Cocos2D users often needed (or wanted) to include other libraries. Some of them have become so popular among the Cocos2D crowd that they could as well be part of the official distribution. Alas, they’re not. That’s a service I want to provide.
Often those libraries require special and non-obvious steps to successfully add them to an existing project. All too often those steps are either undocumented, untested, hard to follow, refer to outdated versions of Xcode, iOS SDK, etc. and generally require technical expertise of project configuration and compiler settings.
This is all taken care of for you. Here’s the list of libraries that are already included in the Ultimate Cocos2D Xcode Project:
- Cocos2D (iOS & Mac OS in the same project)
- Cocos3D (ready to use of course)
- Wax & Lua (Wax is enabled and setup, essential Lua functions have an ObjC interface)
- ObjectAL - “iOS Audio, minus the headache” (has excellent documentation!)
- iSimulate - lib included with permission, requires separate iSimulate Lite App or full version
- Cocos2D Gems: GameKitHelper, ClippingNode, Multiple Update Selectors, FrameOrFile, more…
- iAd (already setup in RootViewController, just enable it)
- Chipmunk SpaceManager (ObjC interface for Chipmunk physics)
- SneakyInput (or alternative Joypad library if there is one)
- Objective-C Optimized Singleton Macro (gets rid of @synchronized to improve speed)
- LOG_EXPR (logs any statement, no format strings needed: LOG_EXPR([self contentSize]) )
- … did I miss an essential library? Please leave a comment!
That is quite a list. All you need to do to use these libraries is to either enable them in code or merely include the header file and start using them. If you worry that all these libraries will bloat your App, rest assured that Xcode is very clever: if you don’t actually make use of a static library (eg don’t include any of its header files), it will not be linked with your App and not waste any space or performance. I verified that.
Update policy
These are a lot of libraries to keep up to date. I plan to make about 4-8 point releases each year, usually triggered by a major (speak: non-beta) release of Cocos2D. If updating other libraries justifies an update depends on the library’s importance and the significance of the update.
Your libraries
Adding your own libraries to the project will be easy and the process will be documented. This will encourage code-sharing because your library will just work with other user’s project, it only needs to follow a few simple guidelines to become plugin-capable. This opens the door for better and tighter integration of 3rd party code into your projects. Even if you don’t intend to share your code, you’ll still benefit because your code will be easier to re-use and maintain.
Also, if you like you can make a request for a specific library or additional source code that should be included in the project, please leave a comment. I’ll see what I can do. 
An ongoing discussion about how to correctly send/receive data with Game Kit on Cocos2D Central prompted me to write a demo project to complement the Learn Cocos2D book’s Game Center chapter. The resulting working code is in this post, and also reprinted below.
The Game Kit Data Send/Receive Demo Project (download here) is based on the Learn Cocos2D book code made for the Game Center Chapter. It’s called Tilemap16 just to stay in line with the naming scheme.
You control the little Ninja as usual, but this time anytime you move it, it will also move on all other connected devices because the tile coordinate is sent via Game Kit to all connected players but only when it actually changes. The demo even allows you to move the Ninja on any device, and all others will follow, so it truly works in every direction. In addition, a score variable (int) is transmitted every frame just to show how to send different types of data at different times.
I wish I could have made a movie to show how cool this is but alas, my iPod was busy running the demo, so all I can show as proof is my iPod and iPad running the game with both Ninjas at the same position (mushy image made with my already-ancient iPhone 3G under perfect programming but terrible lighting conditions):
Source Code Example
In summary this is the code that’s used to send/receive data with the help of the GameKitHelper class I wrote for the book (also included in the download and free to use for anyone and any purpose):
[cc lang=”ObjC”]// add this to the header
typedef enum
{
kPacketTypePoint,
} EPacketTypes;
typedef struct
{
EPacketTypes type;
} SPacketInfo;
typedef struct
{
EPacketTypes type;
CGPoint point;
} SPointPacket;
[/cc]
Sending a packet:
[cc lang=”ObjC”]
-(BOOL)ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event
{
CGPoint location = [touch locationInView: [touch view]];
SPointPacket packet;
packet.type = kPacketTypePoint;
packet.point = location;
gkHelper = [GameKitHelper sharedGameKitHelper];
[gkHelper sendDataToAllPlayers:&packet length:sizeof(packet)];
}
[/cc]
Receiving the packet:
[cc lang=”ObjC”]
-(void) onReceivedData:(NSData*)data fromPlayer:(NSString*)playerID
{
// first, assume it’s the general SPacketInfo, that way we can access type
SPacketInfo* packet = (SPacketInfo*)[data bytes];
switch (packet->type)
{
case kPacketTypePoint:
{
SPointPacket* pointPacket = (SPointPacket*)packet;
CCLOG(@”received point: %.1f, %.1f”, pointPacket->point.x, pointPacket->point.y);
break;
}
default:
CCLOG(@”received unknown packet type %i”, packet->type);
break;
}
}
[/cc]
Requirements & Setup
You need:
- 2 devices which are Game Center capable, eg they must have the Game Center App installed. If it isn’t, that device is not ready for Game Center. 1st & 2nd Generation devices up to iPhone 3G do not support Game Center. In addition Simulator will not work due to Matchmaking/Invites not being supported on the Simulator.
- 2 Game Center accounts (you can create dummy accounts via the Game Center App)
What you have to do:
- Create a new App on iTunes Connect, enable Game Center for that App, and replace the Bundle ID of your App with the one in the project’s info.plist. Please refer to the Game Center section in the iTunes Connect documentation.
- Make sure Push Notifications are enabled on all devices via Settings App.
- Run the Game Center App on both devices, login and make sure each device is logged in with a unique account. Then invite the other device’s account as friend and accept the friend request, this makes it easier to join each other’s matches.
- Build the Tilemap16 App and deploy it to both devices. Whenever you make a change to the code, you must deploy the App to both devices again, to make sure they run the same code.
- Run the App on one device, wait for the matchmaking screen to appear. Invite your other device’s friend account to join the match.
- Wait on the other device for the match invite to pop up. Tap Accept. The Tilemap16 game will launch.
- Tap Play Now on the first device once the other player has successfully connected and is ready.
- Move the Ninja on either device and watch it move on the other.
Enjoy!
Chapter 15 - The Final Chapter
This is it. The last one. I don’t know what’s going to be in it. It’s supposed to give the reader a “where to go next” kind of outlook. I hope that one of the places will be here, but obviously there’s tons of places to go and tons of things for cocos2d developers to learn.
If you have a particular idea what should be included in the greater cocos2d developer outlook kind of sense, please let me know!
Summary of working on Chapter 14 - Game Center
Amazing! Simply amazing. I think I fell in love with Game Center in the process, I haven’t worked with a networking API that’s so smooth, straightforward and easy to comprehend. No thanks to Apple’s already excellent step-by-step documentation. Still, there were a couple pitfalls and things that one could forget, and I did, that I’ve obviously included in the chapter.
On the other side, with almost a week late for this chapter, I realized how time consuming network programming is. There’s a lot of testing going on, and especially if you’re testing on two devices the process is incredibly inefficient compared to a simple single-player game. You always have to deploy to two devices for every test, and every time the delay between request and response adds to the time spent on testing. Add to that common network errors such as a drop in connection or something blocking the line with a download, and you’re up for a fun ride.
But that alone didn’t account for the one week delay. In the past two weeks I’ve been helping to renovate someone’s apartment, I got a cold, I held a presentation at the Macoun Mac OS X conference (about cocos2d obviously) while still recovering from the cold. Then our pet cat Yoshi had to see the vet and almost died during anesthesia because of a pulmonary edema. On the brighter side I’ve also attended a wedding and wrote a GameKitHelper class for this chapter which contains more stuff than I could describe in the book, including storing achievements which failed transmission, as is recommended but not implemented by Apple’s Game Center Programming Guide.
That’s also why I haven’t been answering emails timely recently. Please be patient, I’ll get to yours soon!
What’s left?
Now that I’m almost finished writing the book, what’s left? Obviously I have to review technical and other edits done by Apress. Current chapter 13 is in technical review while chapter 6 is in editorial review, after which it’s ready for production. So I’ll still be busy reviewing and making changes and additions to chapters during October and probably even November.
Then there’s the issue of the example projects having used three different versions of cocos2d, starting with 0.99.3. That was actually an oversight on my part because at the time I had 0.99.4 available. Luckily those changes are really insignificant for the first few projects. The DoodleDrop game already uses 0.99.4 and so does most of the book’s code. But for the Game Center chapter, I had to migrate the Tilemap project from 0.99.5 beta 1 to beta 3 and that was a huge step. It was easier to simply create a new project from the latest cocos2d template, then re-adding all game source code and resources to the new project. Still, that’s doable.
The bigger issue I have here is the fact that I can’t change anything in the book anymore, so the code should reflect what’s in the book. If the book mentions CCLabel then the code should use CCLabel and not CCLabelTTF. What I think is probably going to be a good compromise is to update the important (final) versions of each chapter’s example projects to cocos2d v1.0 once that is released. Obviously the code supplied with the book will remain as it is described in the book, so the upgraded code would be for reference only and a separate download. Whether I wait for v1.0 depends on how progress towards v1.0 is coming along around the book’s release date some time in December 2010.
In hindsight, I really wished I had used my Xcode template project and used that throughout the book. Back then I decided against it because it was important for me to write the code like almost all cocos2d developers would do. Now I regret the decision because I could have changed the way cocos2d developers start new cocos2d projects for the better. The whole updating process for cocos2d is a major PITA and then some, so I think I need to bring this issue to the table more frequently, more actively. At least until the cocos2d template installation procedure is changed to not copy all of the source code into each new project and then leaving it up to the developer to deal with upgrades.
