Learn SpriteBuilder Phew!

I’m done writing the Tome of SpriteBuilder.

There’s only edits and reviews left, page proofing and then it goes out to print. Meanwhile, I’m cleaning up and extending the Bouncy Beast project for its App Store release.

Time to share some insights as I haven’t been able to slice some time off to write about the process as I originally intended to.

What’s in the book?

In the Learn SpriteBuilder book you will learn SpriteBuilder step-by-step while building the Bouncy Beast game.

The book will guide you through the creation of a physics-driven, parallax-scrolling game with the help of SpriteBuilder, Cocos2D (cocos2d-swift) and Objective-C. The level-based structure will enable you to add more content to the game, even without writing additional code.

As your guide I will walk you through the individual steps necessary to create the game project. Along the way I’ll explain the SpriteBuilder features, caveats, workarounds and helpful tips and tricks as you are most likely to come across or need them.

978-1-4842-0263-0_Figure_13-16 At the end you’ll have a complete game reminiscent of games like Badland.
The game also runs on Android devices thanks to Apportable’s Android plugin for SpriteBuilder.

The Bouncy Beast project’s source code will be available.

Bouncy Beast Demo Video

Here’s a video demonstrating the game. Notice the subtle particle effect on the main menu’s background, the paginating scroll view, the soft-body player character.

NOTE: the suboptimal framerate in the video is 100% attributable to the iOS Simulator from which I recorded the video. On an iPod touch 5G the game runs with a constant 60 fps.

Continue reading »

Learn SpriteBuilder book: Progress Update #1

On July 11, 2014, in book, idevblogaday, by Steffen Itterheim

978-1-4842-0263-0_Figure_04-11

Since the announcement of the Learn SpriteBuilder book I’ve submitted the first three chapters to Apress.

Actually it’s chapters 2 through 4 because I’ve learned that the details in the first chapters tend to change significantly. This includes version numbers but also highlighted features, tool and project names, and so on.

Chapter Summary

Following is a summary of each chapter thus far.

Chapter 2 “Laying the Groundwork” first introduces the SpriteBuilder user interface but also Cocos2D (-iphone/-swift) programming basics. I really went above and beyond existing SpriteBuilder user interface tutorials to explain even the smaller details that boggled my mind when I was learning SpriteBuilder. You’ll learn the difference between Scene, Node or Layer CCBs. The effect of position, content size and scale modes (points, UI points, %, insets). What all the nodes are and what they are used for. But also how to make the code connections and what the difference between CCBReader load and loadAsScene is. The importance of Sub File nodes and the Tileless Editor View.

At the end you’ll have a firm grasp on SpriteBuilder basics and a project framework with two scenes and transitions between both scenes.

Continue reading »

I’m excited to announce that I am writing a new book, titled Learn SpriteBuilder. It will be published by Apress and is both sponsored and supported by Apportable with top-notch graphics.

Over the course of the book you will create a level-based, parallax-scrolling game that’s not unlike Badland with some elements from Leo’s Fortune. The game will be complete with main menu, settings, level selection, pause and game over menus, music and sound effects, and room to extend the game with your own ideas, levels, code and other content.

Learn SpriteBuilder is not a direct sequel to ‘Learn Cocos2d'; its focus is on teaching efficient workflows with SpriteBuilder and demonstrating the connection between SpriteBuilder and cocos2d-iphone v3 (now known as cocos2d-swift). Still there’s plenty of Objective-C code necessary to build an iOS game and I’ll take extra care to explain it well, in particular the new Cocos2D v3 features.

The Learn SpriteBuilder book is aimed at beginning to intermediate Cocos2D and SpriteBuilder developers but also experienced Cocos2D developers who are interested in learning more advanced concepts. Among them are the new visual effects system currently in development for Cocos2D and a fully textured, deformable soft-body player character.

Three chapters alone are dedicated to physics editing with SpriteBuilder and physics programming with Objective-Chipmunk.

Frequently Asked Questions

Please leave a comment if you can’t find your question answered in this FAQ.

Continue reading »

Tagged with:  

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:

Screen Shot 2014-03-20 at 12.15.08

How QuickLook works

Continue reading »

Tagged with:  

Migrating to cocos2d-iphone v3 – Tips & Tricks

On March 6, 2014, in idevblogaday, by Steffen Itterheim

This is a collection of Tips & Tricks for users who are migrating to cocos2d-iphone v3 from v2. Mostly refers to questions posted on stackoverflow.com.

Please excuse the short, bullet-pointed format. I’m a little short on time but didn’t want to miss out on another biweekly post like I did two weeks ago (first time in about 4 years, ouch).

General Tips

  • Many classes have been renamed…

“Use the source, Luke!” If you don’t find what you are looking for:
– Check the cocos2d API class reference
– Start typing the class or method name, see what suggestions Xcode autocomplete has for you
– Use part of the class name (ie “repeatforever”) and perform a “Find in Project” to search through all source code files

  • Tutorial XYZ won’t work with v3!

Yes, it won’t. Most likely it was written for cocos2d-iphone v2.
Question is: do you have to use v3? And do you have to use it right now?
Because if you’re in the process of learning cocos2d it’ll be easier to learn from and with v2 tutorials/books for the time being until more v3 tutorials have been published.

  • How to upgrade an existing cocos2d v2 project to v3?

Continue reading »

The Mobile 2D Game Engine Popularity Index – January 2014

On February 6, 2014, in idevblogaday, by Steffen Itterheim

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

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 »

The Guide to Building and Customizing SpriteBuilder v1.x

On January 23, 2014, in idevblogaday, by Steffen Itterheim
Custom-built SpriteBuilder with MySprite node plugin

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:

Continue reading »

Tagged with:  

Why “Free to Play” is bad for Indie Game Developers

On January 9, 2014, in idevblogaday, by Steffen Itterheim

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 »

Tagged with:  
Page 1 of 712345...Last »
Powered by WishList Member - Membership Software