This is an update to the Mobile Game Engine Popularity Index I published 2.5 months ago.
Game Engine Popularity on Stackoverflow.com
stackoverflow tag popularity
Since November’s chart I made sure the tags I’m most interested in (cocos2d-iphone, cocos2d-x, sprite-kit) were properly applied to all questions.
Furthermore I update at least the past 6 months for each tag, which caused the graph to change noticeably. This may be due to policing the site, where users remove tags or retag questions. The net result is that there are now recent months with fewer questions for some engines compared to November’s chart. In particular this flattened the up-down curve of cocos2d-iphone. Continue reading »
Custom-built SpriteBuilder with MySprite node plugin
Following the recent release of SpriteBuilder and cocos2d-iphone v3 I’m sure some of you are itching to use SpriteBuilder by building the github version in Xcode rather than downloading it from the Mac App Store. Here’s how!
This is a post for developers who want to compile the SpriteBuilder code from github. To customize it, to debug issues, to add or gain access to new features; be it for their own use or to help the project, or both.
Previous experience with Xcode, Objective-C, cocos2d-iphone, git and github is assumed.
Download SpriteBuilder from github
The download and first-time compilation procedure is also detailed on the SpriteBuilder github page. You need to clone the project, then initialize the cocos2d-iphone submodule. The necessary Terminal commands are as follows:
The “Free to Play” business model is bad for us independent game developers. If we try to implement it, that is.
Let me first explain what a typical (casual, mobile) free to play game works like. The type of game that works so well on mobile, revenue-wise, that it’s all the rave and even Indies are tempted or have tried to follow down that path.
A typical, casual free to play mobile game
As you launch the app you’re presented with colorful, charming visual imagery and characters with unnaturally large eyes. This is visual appeal 101 if you’re aware of the composition of an art style that provokes a heartfelt, warming charm. Like a meadow in full bloom it appeals to all audiences. Like a meadow in full bloom it is nothing special if you know when and where to find it.
Typically you aren’t given any choice but to start playing the game. The rules are extremely simple at the start, the interaction understood in a split second and the early levels are designed for player success. It’s a series of visual and audible successes and before you begin to truly enjoy it, the level is complete. And that is intentional.
As you progress in the early levels, they all seem over far too quickly as you’re introduced to more game mechanics. This is what gets players hooked, the simple fact that they could keep playing and enjoying themselves but the game always stops them short of getting in the zone. This is the stage where the player is conditioned to advance to level after level.
In a sense, the player isn’t really “free to play” as he or she wants to. Continue reading »
Well, that’s that. Enjoy your holidays! 
I’ve also released OpenGW Preview 1 to KoboldTouch customers. Then visit the members area to download it. Visit the OpenGW website and wiki to learn more.
In case you feel like checking it out just sign up to any of the KoboldTouch subscription plans. The KoboldTouch subscription price will not change for you if you stay signed up. Once we release OpenGW (it will replace KoboldTouch) the price will go up for new customers.
The OpenGW framework itself is fully functional and well tested. It comes with a basic code-based example and a complex Platformer example game built with the help of Tiled and Lua.
What isn’t so good yet is the way projects are set up (expected to change before release) and to start a new project you’ll have to copy an existing project and start modifying that. OpenGW is not currently meant to be added to a custom project - unless you can fight your way through some project setup steps. These rough edges will be polished next year.
Daniel Sperl, developer of the Sparrow Framework, recently posted a performance comparison on the Apple Developer forum where Sparrow ran 2.5 times faster with MRC code than the version upgraded to ARC.
A curious finding though it seemed very far off from real world observations. Being a synthetic benchmark no less. I decided to do a similar test based on the same code comparing cocos2d v2 and v3.
Fortunately cocos2d-iphone v3 has made a similar switch from MRC (v2.1 and earlier) to ARC (v3 preview). Unfortunately the internals of cocos2d also changed to some extent, for example custom collection classes written in C were replaced by Core Foundation classes. I don’t have a full overview of the changes, but at least the renderer doesn’t seem to have changed in any significant way. Yet.
So while comparability is good, it’s not like Sparrow where truly the only changes made were converting the code from ARC back to MRC. Take the following benchmark results and comparisons with two grains of salt and pepper on the side.
ARC vs MRC
The original benchmark done with Sparrow has seen MRC perform 2.5 times better than ARC in a synthetic “draw as many sprites as possible until framerate has dropped consistently below 30 fps” test:
The idea for this post really started with this poll:
I’ll present the results further down. Not wanting to spoil it before you made your choice.
This poll was just a quick test for a free web poll service. Well that and being curious how the major 3 Objective-C render engines compared against each other.
Since I added a “Other” choice and some users took it, I started to wonder what the “Other” choices might be.
I mean besides cocos2d-iphone, Sprite Kit, Sparrow and OpenGL ES, what choices could there really be? Have I perhaps not noticed the next big thing in Objective-C render engines?
Spoiler: I didn’t.
The Poll Results (as of Nov 28th 2013)
iOS 7 and thus Sprite Kit has been available for just over 2 months.
My expectation was that being so new and despite coming from Apple and developers usually slow to change their preferences, cocos2d-iphone would likely come out on top. At best it would have a head-to-head with Sprite Kit.
The actual result really surprised me: 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.
