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.
As summarized by DaringFireball, Apple has loosened their restrictions of section 3.3.1 of its iOS Developer Agreement:
In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.
Previously, the only programming languages allowed to write iOS Apps were C, C++, Objective-C and Javascript. This has now been removed. For cocos2d developers nothing changes, except maybe that you can feel more comfortable embedding a scripting language like Lua into your games. As long as you don’t allow the Lua scripts to be changed by users, or download or otherwise modify/replace bundled Lua scripts. That wasn’t illegal before, however, yet after the change in section 3.3.1 it put a lot of doubt and worry into developers looking into using Lua. So you can now feel much more comfortable using Lua in iOS games, for example by using iPhone Wax.
The removal of these language restrictions is essentially good news for Unity developers (read their statement), and those who wish to develop iOS Apps using a Flash cross-platform compiler and also those using Corona Game Edition, which is entirely Lua-based. And speaking of which, Corona offers developers to purchase Corona SDK and Game Edition at just $99 until only September 15th, after which you’ll have to pay for each product seperately and the price goes up to $249. Just in case you were eye-ing it.
Chapter 11 - Isometric Tilemaps
After Chapter 10 introduced Tiled and working with orthogonal tilemaps it’s time to step things up a notch and delve into isometric tilemaps. It starts with basic principles of isometric tilemaps and editing before going into detail on what’s different code-wise compared to orthogonal tilemaps. Obviously this has to include how to determine which isometric tile was touched and how to move a character across an isometric tilemap.
Summary of working on Chapter 10 - Working with Tilemaps
This chapter introduces you to tilemaps, what they are and what benefits and tradeoffs they provide. Without a doubt the most popular editor for tilemaps for use with cocos2d is the Tiled Map Editor. I explain how to use it over several pages before going into code and actually loading your first tilemap using cocos2d’s CCTMXTiledMap class.
Loading a tilemap is just half the story. You’ll also learn how to manipulate the tilemap layers and individual tiles, as well as scrolling the tilemap and centering the touched tile on screen. The code takes care that the tilemap is never scrolled outside its boundaries.
While working with the Object Layer feature of Tiled (CCTMXObjectGroup in cocos2d) I noticed it’ll be handy to display the rectangles on the screen. So you’ll also learn a little custom drawing using OpenGL ES respectively cocos2d’s wrapper functions in CCDrawPrimitives.
The Learn Cocos2d Alpha Book’s page now lists the source code for download. It’s 44 MB, contains the source code for the first 9 (!) chapters as zip files.
I’m not sure if everyone can download the source code, or only eBook purchaser. I wasn’t asked to login, so I think it may be available for everyone. Try it out! Here’s a direct download link:
Direct Download: Learn Cocos2d Alpha Book Source Code
Before you ask: no, Chapter 6 and beyond are still not available yet. They will have to wait until they have gone through the editorial process. I believe Chapter 5 is currently in this process so it will still take at least a week, maybe 2-3, before you’ll get your hands on Chapter 6. But I hope that once the editorial process has caught up with the already available 5 chapters, new ones should be available on a regular basis. Every 1-2 weeks I hope, but no guarantees. This process is very new to me too so I try to be very careful making any assumptions.
Or, in other words, I’ll be away from home (which happens to be my office) from Tuesday (tomorrow) to and including Friday for a much needed short vacation. That is to say I’ll probably be unresponsive for the rest of the week and I’ll catch up on emails next week, please be patient.
At one day I’ll be visiting the Miniatur Wunderland in Hamburg, the world’s largest model railroad exhibition, on Wednesdy or Thursday. On the off-chance that you’re in the Wunderland too and would like to meet me in person, send me an email. Maybe we find a time to meet up and have a quick chat and connect. Speaking of meeting, I’ll also hold a cocos2d presentation (in german) at this year’s Macoun conference in Frankfurt, October 2nd and 3rd where I’d be happy to meet up with you, if you happen to be there. And in general, if you’re able to come to Mainz we can meet up just to connect and talk about experiences, like I recently did with Johannes Seidel from Blacksmith Games. That was a meeting I enjoyed very much, I was pleasantly surprised to hear that he was also the person behind the AppventCalendar, which essentially spawned Free App A Day (run by someone else). He also had some great marketing ideas that helped make his game Plushed a success (before you ask: it’s made with Unity). And it’s a deserved success. Definetely watch out for more games from him, and follow him on Twitter.
Those developer experiences and life stories are very inspiring and a fun thing to hear and talk about. I’ve been reading a lot of Paul Graham’s Essays once again because he’s the go-to guy for those kinds of experiences in writing, and I bought Founders at Work for exactly the same reason. Motivation, inspiration and thinking outside the box. For that I’m very happy that I can read those essays, docs and eBoos on my wirelessly (meaning: no wifi) iPad by using Instapaper and GoodReader for eBooks. Have I ever used iBooks? No, I don’t need it thanks to these two excellent iPad Apps.
Before I sound too much like a product marketer … I’ll see/hear/write/email you next week!
Chapter 10 - Working with Tilemaps
This chapter dives into the depths of the CCTMXTileMap class and how to create, iterate and modify tilemaps in code, including isometric and hexagonal tilemaps. Of course there will be an introduction to the Tiled Map Editor as its the primary tool to create TMX tilemaps that cocos2d supports.
The chapter 11 will then use this newfound information and I’ll walk you through making a scrolling tilemap game, since simply loading, modifying and displaying a tilemap would just be half the story.
Summary of working on Chapter 9 - Particle Effects
This chapter was fun. Particle effects are fun indeed. That is, unless you need to tweak them in code only. I did do that an did my best to describe what each CCParticleSystem property does to a visual effect, although some things you’ll have to see for yourself. You’ll find a lot of detailed information on how to setup or simply modify a particle system in code and a couple tips for designing good particle effects.
Of course with Particle Designer everything changes. Designing a cool particle effect suddenly goes from a treadmill to a mesmerizing activity that you can waste countless hours on. If you check Particle Designer’s Online Library you’ll find four of the Particle Effects that I designed and submitted, starting with the “Colorful Burst” effect. Have a look!
Obviously these cool effects needed to go somewhere, so I added them to the Shoot ’em Up game as you can see in the screenshot (the boss just exploded into purple smudge). Along the way you learn how to load the particle effects created by Particle Designer of course.
I noticed that most of my recent posts revolve around the cocos2d book. It’s so very easy to forget one’s online presence while you’re frantically working on projects. I’ve seen it countless times and I don’t want to fall into the same trap. That is: create, create, create and then: announce. Boom. No one’s interested anymore. Everyone moved on. You lost your share of the Internet attention span. That certainly would be a shame because besides the book, I was working on other things over the past two months and I’m looking forward to making an announcement in the coming months. I think it will strike a similar nerve than the cocos2d book did. But it’s not limited to cocos2d, so it’ll get its own website, that much I can say. And yes, I love to tease. 
I think programmers are especially prone to making the mistake of neglecting their online presence, their virtual alter ego that lives on the Internet 24/7. It’s all too easy to become deeply engrossed with what you’re working on, particularly if it’s a very technical thing. Once you’re done you get a burst of satisfaction and then you’re looking for the next fix which of course is spending more time on the project. In the meantime everyone else around you, and on the Internet that means blog readers, are wondering what you’re up to. If it goes on for a while without actually producing something, readers will stop wondering and start not caring anymore.
Numerous times have I read that you need to start marketing as soon as you start creating. At least that’s true for Indie developers. And how many times have I seen people fail at this? All too frequently. Typical scenario: our game is done, now how do we go about the marketing? Your blog should be your marketing instrument from day one. The other negligence for marketing simply stems from a deeply rooted repulsion for promoting one’s efforts and products. I certainly feel that too but I manage to live with it because it helps me strike a balance. I could only make a sales pitch like this one if I was primarily in it for the money (sorry Matt, that’s the impression the site is giving me because it’s too close for comfort to Internet marketer sites).
Most blogs die before they have even started. It’s hard to get readers attention in the first place but I think it’s much harder not to lose them over time. I learned it’s finding the right mixture of blog posts that will create the most interest and attention to readers, a careful balance that one needs to strike. Let me explain the categories of blog posts which I think are valuable but, if not mixed in with other categories, may be too niche to keep readers coming back more often. Unless you explicitly target a tiny niche, in that case a focused approach works quite well.
Concrete Learning Posts
Bloggers who provide sample source code and solutions for a particular platform fall into this category. You write a small tutorial or just a quick fix for a particular technology issue. The good side is that it shows off skill (sometimes) and that you’re being helpful. The downside of these posts is that, especially in the case of Tutorials, they attract a great number of readers but few will stay or come back. Smaller code solutions and quick fixes often get reader’s attention only through google, they copy the code and are gone. The blogosphere is saturated with information everyone needs to learn, because most of us are still learning. What’s often missing are the really hardcore ideas. Take that example and it makes me wonder, could this work to get cocos2d nodes to support NSCoding just by applying this concept? I’d love to try but I don’t have any need for that and it’s on the roadmap anyway.
The problem with the smaller code snippet posts, as I see it, is that they are often only losely related. You may find just the right piece of information but the rest may be too straightforward and already known to you that you don’t give it much value. Posts like these better fit on Q&A sites like stackoverflow.com. Also, before posting those bits of wisdom it may be wise to check if that information isn’t ubiquitious. Chances are someone else came to the same solution months before you. Posting what others have posted numerous times before does devalue your blog. In that case prefer a post that sums up all the other great posts on the topic. That works so much better since you’ll be sharing your own research.
And definitely share your current development status. I love those work-in-progress posts. I’ll be writing more of these in the future.
Concrete Experience Posts
You may be surprised how interesting your (development) life’s experiences can be. About a year ago I started a german Spieleentwicklerveteranen (Game Development Veterans) Podcast, in which I simply told my experiences within the game industry. How games come to be, what life is like as a game developer, why people start working for a games company and which kind of experiences they may be going through, from good to bad. Just a very hands-on, personal opinion approach with a couple anecdotal stories. I only produced two episodes though, mostly due to lack of planning and because it’s not really that much fun to do a podcast without a regular, reliable partner. Yet to this day I frequently get emails asking me for the next podcast.
Readers love to read and hear about experiences for two reasons: either they are less experienced than you are, and get a glimpse at what it must be like to be at your level. Or they actually are at the same level than you are, and they can relate. Suddenly they’re not so alone anymore.
Recently I spoke to a former colleague of mine who set out to write his own game, I think he has all the necessary skills and he certainly had the motivation and drive to go through with it. But as time passes by, and he kept working all by himself and more often than he wanted to, faced serious technological challenges that hindered his game’s progress. Not being able to actually talk to like-minded people and getting tips from a range of professions, as we were both used to during our time at game development studios, can be a serious motivation killer. And you guessed it, he has no blog and not even a Twitter account.
For me, one thing to fight off incoming demotivational phases is to converse with the people out there and blog my experiences, at least once in a while. I like helping others answer their question because I know how it sucks to be stuck, I also learn valuable lessons from it and I feel good to be able to help or at least nudge developers in the right direction. It also leads me to think in different directions and helps connecting the dots, so that’s where the interesting experience stories are actually born. Wait a second, I was in the exact same spot back then …
I believe experiences, if they provide a meaningful resolution are the most valuable blog posts anyone could write. But those don’t come natural to most developers (or people in general - but I’m not saying that developers != people). So that’s a conundrum. We programmers love the DRY principle (if you don’t you’re not a programmer yet), but that doesn’t translate to blogging and even less to marketing. Like my Starterkit, I know I should mention it more often to make a decent number of sales over the coming months yet the programmer in me tells me that, oh well, those who’ll like it will find it regardless. Trust me, they don’t. I am tempted to mention it more often, at least on Twitter, and maybe give away some promo codes or get someone to write a review. But what to say about it? Look, it’s here. The same thing from last week. Oh great. Yeah, I think you get the picture. It’s really hard to REPEAT YOURSELF without becoming obnoxious. We all know the kind. Personally, I don’t follow Twitter accounts whose tweets mention their own product(s) about 50% of the time or more, unless they provide interesting insights into their work.
Ramblings aka Opinion Pieces
Everyone loves to have an opinion. It’s very easy, tempting and almost natural to start blogging with a lot of opinion pieces. I started in 2007 with my gaminghorror.net blog and almost all early posts were opinion pieces. I think that, unless you know exactly what you’re talking about and can construct a careful argument, that those kind of posts can easily backfire. Either you’re an expert and a critical thinker and you are able to dissect your thoughts into constructive opinion, or else you risk being regarded as a loudmouthed idiot who doesn’t know squat. There’s a fine line to walk. Certainly no one cares about whether you like a certain product or technology more than another, or yet another opinion on the same issue unless you can provide a new, fresh argument. But if you have an actual pet-peeve, something that comes from your heart and that just totally goes against everything you believe in, that’s what should become a great insightful blog post.
For example, one of my pet peeves is to fight off the Piracy Problem by saying it doesn’t really exist. Except in our minds. We don’t have a piracy problem, we have a perception problem. We just make ourselves believe that most of the time piracy is bad for business. There is a real threat but it has a much less impact than the piracy numbers lead us to believe once you factor in human behavior. For App developers it’s widely understood and appreciated that, once their App is free for a day, the downloads jump through the roof. Ten or even 100 times more downloads for free than at the $.79 price point. Yet when we consider piracy, we see great numbers exactly because the software is free yet we forget to consider that, if any pirated software would cost just $.79 the piracy numbers would drop at least ten-fold. I can’t prove it, but I sure as hell believe it because that’s how software piracy works. It’s not a market, it’s a movement that exists only because there is no money involved, set aside a few scrupulous industrial pirates.
Paul Graham puts it best in his essay What you can’t say. It’s the things that might (or will) get you in trouble which perhaps should, or must, be said. The ideas that people fear might be true. Like Galileo’s moving earth theory. Ridiculous, isn’t it?
Conclusion
So what am I saying, I forgot to market myself? Not quite, I’d rather see it as an invitation. By writing more blog posts and allowing anyone who is interested to literally “read my mind” I invite you to take part. And dozens of developers have taken this offer so far.
I get a lot of emails and I answer all of them, even if it takes me a couple days to get to each and every one of them. There are valuable exchanges of information and knowledge and some of that would be of a general interest. But because I spend the time writing to a single person I tend to write less blog posts to a greater audience. I make observations and find solutions all the time and learn from them. Some of that actually goes into the book as I’m writing it. But what I should do more is to let everyone in on more of my insights or simply what I’m up to.
When I look at this website from an outsider’s point of view, I see too much focus on the book right now. A few valuable posts in between but not enough for my taste. I have a tendency that, once I start writing, I write a lot. This is bad because it costs a lot of time and effort. So I avoid it too often. Yet, often times it’s the tiny pieces that can be just as important. Because your time is valuable, too!
Going forward I vouch to write at least one blog post per week that’s not about the cocos2d book, and may not even be about cocos2d specifically, like this post, but still generally interesting to iOS game developers of course.
I also need to write shorter posts. The sun is setting … again?!?! 😮
Chapter 9 - Particle Effects
Those tiny specks which you can see on your touchscreen after a sneeze.
Not exactly. Of course I mean the cocos2d particle system and its built-in particle effects which will be the focus of this chapter. And no discussion of particles would be complete without describing the workflow revolving around the Particle Designer tool.
Summary of working on Chapter 8 - Shoot ’em Up
This certainly wasn’t the easiest chapter for me to write. I had very ambitious goals, maybe too ambitious for 27 pages. I did manage to sneak in quite a lot though, here’s a partial list:
- how to refactor existing code to make it work better with the new features
- how to pool bullets and enemies together for easier access and better performance
- how to not use too many subclasses, instead relying on type switches
- how to use cocos2d’s node hierarchy as a simple component system for writing reusable game logic components
- how to implement basic movement, shooting and a healthbar as components
- how to detect collisions between bullets and enemies
The not so easy part was striking the right balance. Not going too technical. Not doing too much at once. Not dividing things into too many tiny pieces. But most of all I frequently encountered various bugs in the code, or just unexpected behavior of cocos2d which forced me to spend more time debugging and sometimes backtracking changes than I was prepared for.
After a long and hard work week, paired with physical exhaustion and an late-summer allergy burst, my concentration didn’t allow me to work at 100% capacity. In the end I did manage but it took longer than I had planned, I’m over a day late to submit this chapter. The next one will be easier though, and it has to be as I’m preparing for a short trip near the end of next week. I certainly am looking forward to a couple days off now.
