For the past two weeks I’ve been running a Cocos2D Developer Survey. As of today, 236 developers started the survey and 189 finished it completely. That’s 80% despite the many questions they had to answer.
Here are the results with my observations. I started the survey also to see if I was on track with KoboldTouch, and whether certain assumptions hold true. Specifically I had a hunch that cross-platform development is only perceived to have great value or appeal. Let’s see if I was right.
Click on each image for full resolution.
Who are you?
I was very curious how many cocos2d developers consider themselves to be hobbyists and indies compared to professionals, who either work for a mobile developer or are taking on freelance jobs as one.
Almost half of those who answered the survey are hobbyists. Nearly 30% consider themselves indies who make a living making mobile games. This is great! Continue reading »
For the second edition of the Learn Cocos2D book I compiled an alphabetically sorted list of tools that developers can use for cocos2d projects. Please let me know if there’s a tool missing from this list or if there’s one that won’t work anymore and hasn’t been updated in months.
The following tools can be used for development with cocos2d:
Bitmap Font Tools
BMFont (Windows)
Fonteditor
Glyph Designer
bmGlyph
Hiero
LabelAtlasCreator
Particle Editing Tools
ParticleCreator
Particle Designer
Physics Editing Tools
Mekanimo
PhysicsBench
PhysicsEditor
VertexHelper
Scene Editing Tools
CocosBuilder
Cocoshop
LevelHelper
Texture Atlas Tools
DarkFunction Editor
SpriteHelper
TexturePacker
Zwoptex
Tilemap Editing Tools
It’s coming along great!
I completed the revisions on Chapter 1 through 5. The entire source code is now updated to use cocos2d-iphone v1.0.0 rc2. To make future code updates easier I also wrote a script that allows me to copy a newer cocos2d version to all projects, which essentially does Steps 1 & 2 described in the Updating Cocos2D in an Existing Project tutorial.
Most Notable Changes
Chapter 4 now includes a description of Glyph Designer for making Bitmap Fonts, and only mentions Hiero on the side. Glyph Designer is the better tool hands down.
Chapter 5 has seen a revision of the paragraph that explains subclassing from NSObject. I think I went too far off course here and subclassing from CCNode will make a lot of things easier while still giving the same benefits regarding class composition.
In Chapter 6 I decided to replace all descriptions of Zwoptex with TexturePacker as the preferred tool for making texture atlases.
For a while it looked like Zwoptex and TexturePacker would be competing on the same level. But recently Andreas Löw (TexturePacker & PhysicsEditor) made the move to work full-time on his tools, whereas Robert Payne is busy with a full-time job. I think the prospects are looking much better for TexturePacker now, and it is already leading in terms of features and update frequency.
That’s it for now.
The previously command-line-only TexturePacker tool now has a nice GUI. It’s called the “Pro” version and for a reason. So far, I’ve been using Zwoptex for creating Texture Atlases, but I’ll certainly give TexturePacker Pro a try.
At first glance, what I liked was that it told me when the Texture Atlas was “full”, eg. not all sprites could fit into that Texture Atlas. And the always present list of image filenames on the right side is a welcome feature. Although Zwoptex does have this list as well, it’s almost rendered useless because it’s a seperate view option.
Zwoptex’ price has changed since I checked last time, it’s now at only $14.95. TexturePacker Pro costs $17.95, it’s command line version $9.95 and the upgrade from command line to Pro is $7,95, so you’re saving a whopping $0.05! 
A couple words on pricing
I find both tools are underselling themselves. Zwoptex was initially at $24.95 and even that price seemed “cheap” to me, given how much trouble it saved me and how much faster and more memory efficient it made my projects. I would say that a price range of $30 to $50 would be more than fair for those tools. I can imagine that the TexturePacker command line version at $9.95 and now the Pro version probably forced Zwoptex to adjust its price.
Problem is: this isn’t a market where people choose their tool based on a $3 price difference. Also, it decreases margins for upgrade prices, with TexturePacker upgrade already below $10. Those low-end prices incur a proportionally large amount of transaction fees, paid to the eCommerce vendor, making them less viable. Since this is also not a mass market, but a niche, it would be wiser if both upgraded their prices back to reasonable regions, around or above $30.
Likewise, Particle Designer is also absolutely undervalued at $7.99. Those low prices undercut the value in tools, and make tool development less and less attractive than it already is. And if anything, cocos2d and the other engines need one thing above all else: tools. And good ones!
Be it Ricardos mysterious “world editor” or the Physics + Tilemap IDE (website) or the other game editing tools currently being worked on - if any one of them is being released as a commercial product but sold for less than $30, I’m going to be very mad at you! If it’s less than $60 I’ll still be mad at you, not very, but still mad.
Rant
Seriously, this isn’t the App Store! It’s developers you’re selling to, and they do value useful tools. Just because cocos2d is free doesn’t mean that all tools surrounding it need to be cheap (or free for that matter). Take Sprite Manager 2 for example. It sells for $75 (per seat!) and isn’t all that different from Zwoptex or TexturePacker Pro. If it were a standalone app it would probably pale in comparison! You might argue that SM2 is for Unity, and their developers are less price sensitive - I don’t think so, and some are even more price sensitive because they just made that huge investment in the first place.
In general you could say that those developers who invest several hundred $$ into a game engine (and toolset) are simply more serious about game development. You do have those enthusiasts working with cocos2d as well, but they’re probably outnumbered by a lot of hobbyists and “I’ll give it a try” kind of people who simply join because of the fun involved, and because the only investment in cocos2d is time and they got plenty of that. The question is: do you want to be kind to the hobbyists, or do you want to build a sustainable business? Plus, Zwoptex and Texturer Packer are also being used by Corona developers.
Now you may also be arguing that a cheaper price allows more developers to enjoy the tools and we’re a friendly bunch and not a commercial, greedy corporation. Sure. But those prices do devalue everyone’s tools, so if anyone wanted to build a tool that takes maybe not just 1-2 months to build (initially), but maybe 4-6 months or more before it’s going to be useful, those price points are not very encouraging to start such a project. That doesn’t mean it won’t happen, but I do know that those people who could pull this off, are generally terrible at doing business. And easily influenced by comparable prices, punching a few numbers, and then getting on with their next train of thought which probably involves solving an obscure programming problem.
And the kind of tool that needs this time investment is the one I’ve been looking forward to since I first started working with cocos2d in May 2009. Back at the time I was convinced that by the end of 2009 cocos2d would be having a game editor or at least something to build the GUI and screens with. I wished for a fully-fledged, professional game level editor, with a physics editor, sprite animation builder, asset management, and whatever else you can dream of.
Now, if that ever happened, it shouldn’t cost less than $100. If you can provide killer features like Box2D integration or scripting game logic, ask twice as much. And offer Lite and Pro versions with a variety of feature sets to make the most out of what developers need and what they are willing to pay extra for niche, but very useful features if you need them.
And here I thought Zwoptex, and that’s going to be it in terms of Texture Atlas creation. Much to my surprise I found the TexturePacker tool. But in comparison to Zwoptex, it doesn’t have a GUI, it’s a command line utility. On the other hand, it does everything automatically and is probably going to be a great choice for any automated procession. It can output in both Cocos2D and Corona formats.
The TexturePacker is available from the code’n’web website and costs around $15 (€10).
It has a few very interesting features, for example removal of duplicate images and color reduction. Check out the feature comparison chart on the Cocos2D wiki.
Chapter 12 - Physics Engines: Box2d & Chipmunk
This chapter gives you an introduction to physics engines and what they can do. Since cocos2d supports two physics engines out of the box, Box2d and Chipmunk, I will explain how to do the same things in both physics engines and I aim to cover at the very least the basic elements like shapes, joints and collisions.
Because choosing either physics engine is often done on subjectively. Some developers may prefer the Object-Oriented C++ nature of Box2d while others may feel more comfortable with the C-based interface of Chipmunk (*). At the very least I want to present both and show their strength and weaknesses by example.
(*) Note: there is an Objective-C binding for Chipmunk made by Howling Moon Software. It’s free to use on Mac OS X and iPhone Simulator but costs $200 per title if you want to publish to the App Store. I believe that most cocos2d developers wouldn’t mind spending up to $30 on a tool or library that is essential, that is why I included Zwoptex and Particle Designer in the book. This product however is in a different ballpark price-wise.
On the other hand, the free Chipmunk SpaceManager also aims to offer better integration with cocos2d-iphone and promises a simplified Objective-C interface. I will have a look at the SpaceManager and then decide whether I’ll discuss it in the book, I say it’s likely. Another physics tool that has gotten some attention is the VertexHelper which I’ll at the very least will refer to.
Summary of working on Chapter 11 - Isometric Tilemaps
Isometric tilemaps rock! That is, if you can get all those nasty issues solved. Even though all the issues like graphics glitches at tile edges, correct z-ordering and the proper blend functions have all been discussed and solved by now, it’s still very challenging to get an isometric tilemap on the screen and a player walking over it, with no glitches at all. I believe this chapter will give a lot more developers the chance to delve into the exciting world of isometric tilemaps. I too learned a lot making this example game, and part of me now wants to write an old-school isometric RPG game. Again. For the n-thousand-th time. Sigh. Some day, some day …
Anyhow, the project I made over the course of this chapter features properly z-ordered tiles and a player sprite, which moves tile-by-tile over the isometric tilemap. You control the player by simply touching in the direction relative to the player that he should move to. One specialty of this project is that the player always remains centered on the screen, he doesn’t move at all! It’s simply the tilemap that is moved under him, which makes a couple things much easier.
Nevertheless you also learn how to find the tile coordinates for a tile that you touch on the screen. And how to avoid the isometric, diamond-shaped tilemap to show the “outside” of the world by adding a border around the tilemap and limiting movement to the playable area. Similarly, the blocking tiles like walls, mountains and houses all block the player’s movement by drawing over the map with a collision layer and a tile whose property is set to “block_movement”.
In the meantime, if you want to gain a better understanding of how isometric tilemaps work, I can recommend the Isometric Projection article by Herbert Glarner. And in case you’re wondering how I suddenly and dramatically increased my art skills, I’ll be honest: I didn’t. I used the terrific tilesets from David E. Gervais which are published under the Creative Commons License. It means you are free to to copy, distribute and transmit those tiles as long as you credit David Gervais as their creator. You can download these tiles from Pousse Rapiere’s website or you can directly download them all at once as 6.4 MB ZIP file here. If you like to hear it from the man, here’s a bit of insight and history from David explaining how these tiles were made.
Chapter 8 - Shoot ’em Up
This chapter will finish the shoot ’em up game. There will be enemies and powerups. It raises the issue of good code design when certain things like shooting and moving are common to all objects while other things such as what to shoot and where from and to depend on who is shooting. And then to determine who is hit by whose bullets.
Of course no shoot ’em up game is complete with a boss monster that takes a couple hits to kill. So it’ll need a healthbar. At the end of the chapter this shoot’ em up should be a fully playable game, with Chapter 9 complementing it with visual effects by using the cocos2d particle system. But I’m getting ahead of myself here.
Summary of working on Chapter 7 - Scrolling With Joy
Once again I renamed the chapter a bit since it’s divided into two parts: a parallax, infinitely scrolling background and input via SneakyInput, featuring a fire button and an analog thumbstick respectively at the end changed to a 8-way digital pad.
The parallax scrolling background consists of several bands or stripes which were created on different layers each in Seashore and then saved as individual 480×320 images. They were then added to the Texture Atlas by Zwoptex. The cool thing about this is that Zwoptex preserves the original image’s size while stripping away all transparent parts. So the images take up little space in the Texture Atlas but in game you don’t have to position them individually, you’ll simply place them at the center of the screen.
To achieve the endless scrolling effect two of each image where added side-by-side to each other, with one flipped on the X axis so the images align neatly. Whenever one image has scrolled outside the screen it is moved back to the right side of the screen. At the end I also fixed the vertical flicker lines which can appear due to round-off errors when moving the sprites. And of course they all are drawn with a CCSpriteBatchNode.
The SneakyInput fire button allows continuous shooting and faster shooting when you just tap it, while the thumb stick controls the ship’s movement in both analog and digital (8-way) variants. The Ship class’ setPosition method is overridden to keep the player’s ship within screen boundaries at all times. Finally an extension class gives SneakyInput the same autorelease initializers used by cocos2d, and adds another good example of just how useful Objective-C categories can be.
Chapter 7 - Side-Scrolling Shooter
The shooter game will be controlled with a virtual joystick using SneakyInput. The background parallax scrolling will be implemented not with the CCParallaxLayer, as it does not support endless scrolling (as far as I know, please correct me if I’m wrong). The rest will be gameplay code, mostly spawning enemies, moving them and collision tests.
The chapter will be submitted on Friday, August 13th. Yup, Friday the 13th. Scary.
Summary of working on Chapter 6 - Sprites In-Depth
I decided to rename this chapter to Sprites In-Depth as it deals mostly with Sprites, Sprite Batching (formerly known as Sprite Sheets), Texture Atlases and Zwoptex as well as general texture memory management. All the while laying the foundation for the game to be made in Chapter 7.
While working on this chapter I noticed that it’s awfully complex to create a CCAnimation class, especially if you’re not using a Texture Atlas. So I decided to illustrate how to add helper methods by adding them via a Objective-C Category to the CCAnimation class. Now you can create a CCAnimation with just one line of code, instead of around ten.
Once more I created some of my now famous doodle artworks. If anything this should show that even a programmer can do art. Or, well, at least something that vaguely resembles art.
I was a bit surprised by one thing though, and that is how little the use of the CCSpriteBatchNode contributed to the framerate in this particular case. I added all the bullets to a CCSpriteBatchNode and found only a 15% increase in performance, it went up from 45 fps to a little over 50 with all those bullets flying. I sort of expected a bigger impact from previous experiences.
