A preview version of cocos2d-iphone v3 has been available for a couple days now. I thought I’ll take a closer look and summarize what’s been done, what’s working and what isn’t, what’s new and what’s old but revamped.
Installation
The installer script has been revamped. It has a different name (install.sh) and different parameters (-force instead of -f).
The first thing I noticed is that the installer is downloading Chipmunk2D. Made me wonder why, so I double-checked to confirm: Chipmunk isn’t included in the archive. This means no offline installation.
I’ll explain later why Chipmunk isn’t included.
Project & File Templates
In the preview there’s only one project template. It doesn’t demo any physics features, it’s your typical “Hello World” example with buttons.
There seems to be an issue with the template where any attempt to save it to a custom location caused Xcode to crash. In fact every time the “Save File” sheet came up and I didn’t click on “Create” right away, Xcode would crash. That’s just one of the reasons why it’s still a preview.
The CCNode File Template isn’t worth mentioning at this point, it creates an empty Objective-C class and is barely different from the regular Objective-C class template at this time.
Hello World v3
Continue reading »
Topics: Overall interest in cocos2d is waning. Unity and libgdx fighting for 1st place. Sprite Kit skyrocketing from day one.
This sums it up. Now for the details. Since my last game engine popularity measurement I tried to improve and streamline the process.
Game Engine Popularity on Stackoverflow.com
For stackoverflow.com data I’m searching for tagged questions created in a specific month. The search query looks like this:
[cocos2d-x] is:question created:2013-11
I repeated this for every tag for every month as far back as there were questions with the given tag. Continue reading »
Don’t multiply velocity/position changes with delta time! End of story.
Okay, not quite. There’s a rationale that goes with it. And there are situations where applying delta time is important, if not required - but probably not in the way you’ve been taught by tutorials and fellow developers.
This is important stuff because applying delta time wrongly makes for a bad game experience.
What is this delta time thing anyway?
If you integrate velocity to a node’s position every frame, you have the option to multiply that velocity with the delta time passed in the update: method. Delta time is simply the time difference between the previous and the current frame.
Actually that is not entirely accurate - delta time is the time difference between the last and current execution of the update: method. This usually occurs every frame, but doesn’t have to be. On a scheduled selector that runs every second, the delta time is - tadaa - one second.
Okay, not even that is accurate. On a scheduled selector that runs every second, delta time is at least one second. It could be slightly more. This can depend on the resolution of the timer and how well one second divides with the time allocated to render a frame, or (as you’ll see later) whether time delta was calculated with the same means as the screen refresh rate.
What does multiplying with delta time do?
The effect of (not) multiplying a node’s velocity with delta time is as follows, assuming that 60 fps is the maximum achievable framerate as on iOS:
- Don’t multiply with time delta: the node slows down as the framerate drops below 60 fps.
- Multiply with time delta: the node moves the same distance regardless of the framerate.
Multiplying with delta time is often referred to as “framerate independent” (updates, movement, gameplay, etc). In contrast not multiplying with time delta is often called “framerate dependent” (updates, movement, gameplay, etc).
Unfortunately, framerate independent updates are said to be “important” and often taught by fellow game developers without actually teaching the implications, drawbacks and situations where you don’t want to apply delta time. Here’s one key point to take away early:
Applying delta time only makes a difference when the framerate drops below 60 fps.
If your game always runs at 60 fps there’s absolutely no point to multiply with time delta. If time delta is only used to combat the effect of short-lasting framerate drops, possibly introduced by system events, you’re doing it wrong.
In this case, and most others too, you’re almost always better off not applying delta time on iOS. And if you do, there’s a whole set of things to consider, including the architecture of both the game and the engine.
Continue reading »
How to write code that is relevant for both Cocos2D and Sprite Kit, and as an extension to that the Kobold (2D/Touch/Kit) projects?
Because for the past months I shifted my attention to Sprite Kit, in order to create Kobold Kit and an accompanying Starterkit. While it’s obvious that Sprite Kit has everyone’s attention, I don’t want to turn my back on cocos2d-iphone and KoboldTouch. So from that came the need to create as much code as possible in a portable way.
The result is OpenGW, the world’s first game world simulation engine available to the public (in Nov/Dec). This is the holy grail I’ve been unknowingly searching for the past couple years!
What is OpenGW?
OpenGW stands for Open Game World.
It is a data-driven, engine-agnostic, cross-platform game world simulation engine.
I’ve set up a stub page where you’ll find more info on OpenGW.
Why OpenGW?
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 »
How do you measure the popularity of a game engine and compare it with others?
Reminded of the TIOBE Programming Language Index and the Transparent Programming Language Popularity Index I couldn’t find a comparable site measuring game engine popularity.
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-iphone: [cocos2d-iphone] or [cocos2d] -[python] -[java] -[javascript] -[c++] -[html5]
- cocos2d-x: [cocos2d-x] or [cocos2d] [c++] -[python] -[java] -[javascript] -[html5]
- cocos2d-android: [cocos2d-android] or [cocos2d] [android] -[cocos2d-x] -[c++] -[python] -[objective-c] -[html5]
- cocos2d-javascript: [cocos2d-js] or [cocos2d-javascript] or [cocos2d] [javascript]
- 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 »
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.
KoboldTouch Update
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 »
