With yesterday’s release of iOS 7 and hence Sprite Kit, many cocos2d developers will face this question sooner or later: switch to Sprite Kit or Kobold Kit or stick with cocos2d-iphone or perhaps move on to cocos2d-x?
I’ll give you some guidance and things to consider …
Sprite Kit / Kobold Kit
Sprite Kit made quite the splash. There are new tutorials coming out by the minute. Two books will be available within days after release. Several high profile tutorial & starterkit authors have jumped on the bandwagon. Tool developers are hard at work adding Sprite Kit support. Instructors are already offering new mobile game development courses based on Sprite Kit. Heck I even started a new game engine based on Sprite Kit: Kobold Kit.
With almost everyone jumping ship, it seems a safe bet to jump ship, too. You’re guaranteed to get excellent documentation from Apple, plus a stability of the framework until at least iOS 7.1 and even then Apple is known to carry on supporting deprecated methods for several versions. It’s easy to learn, and once learned you won’t be thrown off guard by new releases. And the developer community will soon surpass that of cocos2d-iphone. Continue reading »
Continue reading »
With the release of iOS 7 (ETA: Tuesday, Sept. 10th):
Kobold Kit will be available as open source under the MIT License!
We spent a lot of thoughts on how we like to run an open source project. And also why. I’ll start with an executive summary with more (perhaps too many) details in the text.
The Idea: make the project as open and inviting as possible. Let contributors gain control over and take on responsibility for the project based on their contributions. Provide them with ways to promote their work on their own accord.
The Goal: build the Sprite Kit game engine with the help of many developers.
Kobold Kit is supposed to become the “patron project” under whose roof the most valuable Sprite Kit extensions are combined. Website, forum, wiki, blog and store are extended playgrounds shaped by community members. If you’re part of the project, we want you to proudly present and benefit from it.
In essence: we want to get out of the way as much as possible and enable anyone to find their place in the project. Guidance, not dictating, is our guideline.
I got a lot of questions in the past why I’m not contributing my work to the cocos2d-iphone project.
One of the obvious reasons being that what I did is simply too radical technically and I don’t want to compromise. Another reason being a fundamental difference in attitude towards developing and managing open and closed source projects.
These questions made me wonder – in particular because there was often a notion associated with these questions: because I do so much with cocos2d-iphone I should somehow be obliged to contribute back to it. Weird, right? I am contributing a lot already, just not code to the repository.
So if I don’t contribute (code), why don’t you? Or generally speaking, why aren’t we all contributing more (code) to open source projects?
I have been using open source software for as long as I can remember doing programming work. Yet I’ve probably contributed no more than a few dozen lines to all projects together. And realizing this it’s easy to see that this is the case for 99.9% of the developers out there.
So why aren’t we contributing more to open source projects? What is stopping us? I’ll give you some probable causes and ideas how to improve it for your own open source project. Continue reading »
Continue reading »
For Kobold Kit (the Sprite Kit game engine) we’re working on Super Stick Spy, a 2D platformer game. Like so many others, we started out using the (Box2D) physics engine that’s so neatly integrated in Sprite Kit to get everything up and running quickly.
But we knew full well that for the final product, we’ll have to scrap the physics engine altogether and follow best practices when it comes to platformer-programming.
Now with the demo version nearing completion (see video) I can tell you in full detail why you don’t want to use a physics engine for a 2D platformer!
Moving Platform Hell
A moving platform with physics needs to be a dynamic body. Don’t even try moving static bodies, at least in Box2D that will end up in jumpy movement of the body. Though kinematic bodies work better (if available).
The player or other game characters standing on a moving physics body will have the platform slide underneath their feet. The characters won’t magically move along with the platform! And there is no feature in the physics engine that lets you set this up. You have to program it to synchronize character movement with the platform they’re currently standing on, and end the synchronization as soon as a character lifts its feet up from the platform.
Which can be a problem for downward-moving platforms as the player loses contact with the platform every other frame, starts falling, and lands right back on the platform. To put it in Homer’s words: “Doh, doh, doh, doh, doh, doh, doh …”. So you need to make the character stick to the platform, yet allow him to fall off of the ledges and jump, and possibly also allow him to be forced off the ground by normal collision events (projectile impact, platform moving through a tiny crevice). Continue reading »
Continue reading »
How do you measure the popularity of a game engine and compare it with others?
So I sat down and concluded that I can do a simple manual test rather quickly. These are the measurements anyone can take easily:
- Forum topic, post and member counts (if available)
- Stackoverflow.com and gamedev.stackexchange.com tag counts
- Google search query results
Popularity of Cocos2D Variants
Let’s begin by comparing the popularity of the various Cocos2D variants. The difficulty here lies in properly excluding all the other cocos2d variants. That cocos2d-iphone is commonly referred to as just “cocos2d” makes it difficult to measure just the cocos2d-iphone popularity and to remove that number from all other engine variants.
I tried to overcome this by including or excluding specific tags in Stackoverflow and Gamedev searches:
- cocos2d-android: [cocos2d-android] or [cocos2d] [android] -[cocos2d-x] -[c++] -[python] -[objective-c] -[html5]
- cocos2d (python): [cocos2d-python] or [cocos2d] [python]
- cocos2d-xna: [cocos2d-xna] or [cocos2d] [xna]
- cocos2d-html5: [cocos2d-html5]
- cocos3d: [cocos3d]
- kobold2d: [kobold2d]
- cocosbuilder: [cocosbuilder]
Stackoverflow.com tag search results:
Okay, let’s try that again with cocos2d-iphone removed so the other variants can be compared in relation to each other: Continue reading »
Continue reading »
This post will be unusually short because I’m going on vacation tomorrow (July 12th) and won’t be back before July 22nd.
I’ll use this post for a quick progress report on Kobold Kit.
Kobold Kit Progress
Kobold Kit is going more and more in a rapid-development direction, with fewer interruptions. Here’s the corresponding video to that:
It is also heavily gearing towards tilemap rendering and physics integration. We’re making a game with Kobold Kit which will become a Platformer Starterkit as well as a published game. It will also be featured in an upcoming book.
When I say we, I mean that a former colleague of mine (Marcus) has teamed up with me. He’s a game designer and Tiled user, so I get lots of good feedback on how to improve and move things in the right direction. You’ll see more of his work when we’re both back from our vacations in August.
The fact that I haven’t posted on the koboldkit.com blog for a week only means we were very busy making lots of smaller improvements to the platformer game we’re developing. I’ll be away for 1 week so I wanted to ensure that Marcus can get some work done while I’m away.
This is one other plus about this partnership: Kobold Kit will decouple as many tasks as possible from programming work and offload them to editing tools, configuration files and scripting. These improvements are beneficial to the programmers as well because they enable or speed up rapid prototyping.
And if you do happen to work with designers, your attention will not be required as often. If you haven’t done so in the past, you probably can’t appreciate what that means. But try anyway. 😉
Since Kobold Kit is so heavily integrated with Tiled, we decided to sponsor Thorbjørn Lindeijer and Tiled beginning August 1st. I also sent him my old Mac mini so he can setup daily builds for OS X.
We have also secured several sponsors ourselves, and we’re very excited about one in particular, but we don’t want to spoil the fun with a premature announcement. All in due time.
PS: In case you haven’t built the latest Tiled source code: you’re seriously missing out on the reworked properties pane (no longer a modal dialog). Here’s a OS X build of the Tiled source code (June 29th) if you want to give it a try. Thanks to Andreas Löw who built it for me.
I have received very little support or feature requests in the past weeks. I take this as a sign of maturity. At this point development on KoboldTouch is on hold until some time after the release of Sprite Kit (iOS 7). I will tend to serious bugs of course, and already made a compatibility fix for iOS 7 and Xcode 5.
I can’t say whether KoboldTouch will continue to incorporate cocos2d v3 or not. This depends on too many hard to predict variables:
Will cocos2d-iphone v3 be competitive compared to Sprite Kit and still used by a considerable number of developers? Will users be interested enough in an MVC framework with extras? Will cocos2d v3 perhaps take the chance and improve in ways that make KoboldTouch much less attractive? And how much or for how long is development time best spent (exclusively) on Kobold Kit, how much danger is there in splitting efforts?
I take a “wait and see” approach. The hope I have is that cocos2d will trim down its own API and copy the Sprite Kit API and behavior to become a natural, seamless “upgrade path” for Sprite Kit developers (drop-in replacement).
It won’t work any other way, or would you willingly switch from, say, MapKit to an open source alternative (route-me)? Only if you absolutely have to, am I right? Though the only “must have” feature that cocos2d will always offer over Sprite Kit requires an advanced skill set to exploit it in the first place.
But all of that is speculative at this point. If you’re a KoboldTouch developer or want to become one, you’ll get the support as always and you’ll be able to publish your game two years from now. That’s guaranteed.
As KoboldTouch user you’re also going to be Kobold Kit customers, I won’t charge KoboldTouch users twice. And if you want early access to Kobold Kit, sign up to Kobold Touch and check the forum. Since I can only unlock you manually you’ll have to wait until I’m back though.
Signing up to KoboldTouch now makes perfect sense because you’ll pay forever less than Kobold Kit customers, and it helps our efforts in more ways than just financially.
See you in 10 days!
Looking for a Sprite Kit Game Engine? Check out Kobold Kit!
Two weeks ago I blogged about Why Apple Created Sprite Kit and What It Means For Cocos2D.
Two weeks since WWDC 2013 is also a good time to take a first look at the impact of Sprite Kit on the economy. Everything and everyone seems to be in turmoil right now as far as 2D game development for iOS and related tools and services is concerned.
To understand the impact of Sprite Kit, let’s first look at Kobold Touch for which I have actual data to back up my impressions.
KoboldTouch Signup Rate – Bummer!
I have been taking notes of the exact days new KoboldTouch users signed up in an Excel sheet. I found it entertaining and thought that maybe some day I will have a use for it.
That day has come. I can present you the KT sign up rate from post-WWDC dates June 10th to 24th with the sign-up rate of the same two-week span in the preceding months: Continue reading »
Continue reading »
Cocos2D is a rendering engine. Note the emphasis. 90% of what it does is draw stuff onto the screen and animate it. It adds some input processing and scheduling and the rest is up to you.
A game engine is to cocos2d what cocos2d is to OpenGL. The list of things I want in an actual game engine is long.
The iOS mobile platform has advanced far enough that a pure rendering engine just isn’t that much of a help anymore. We’re effectively moving back towards where we were back in 2008 if we don’t start pushing the boundaries, hard.
Here are some ideas I have for and would like to see in a 2D game engine, in no particular order. It is not a feature list for Kobold Kit, but it does reflect what I want to make possible with / encourage for Kobold Kit. Continue reading »
Continue reading »