Xcode’s QuickLook debugging feature allows you to get more details, and be more visual with your debugging data.
For example you can even grab a screenshot of the cocos2d screen and display it right within Xcode:
How QuickLook works
This is an update to the Mobile Game Engine Popularity Index I published 2.5 months ago.
Game Engine Popularity on Stackoverflow.com
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 »
Continue reading »
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:
Cocos2d-iphone is rebooting … please stand by.
Click any link to develop!
SpriteBuilder is the successor of the design tool formerly known as CocosBuilder. It is specifically designed to work with cocos2d-iphone v3. SpriteBuilder now has its own website with a dedicated SpriteBuilder forum that you should use for any questions about and suggestions for SpriteBuilder. Continue reading »
Continue reading »
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 »
Continue reading »
Well, that’s that. Enjoy your holidays!
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: