Now, this is just absurd.
Lima Sky, developers of App Store hit Doodle Jump, are trying to remove all Apps with “Doodle” in the title from the App Store. On the basis of a trademark claim. With the help of Apple.
They do own the trademark for “Doodle Jump”. They currently do not own the trademark for “Doodle”. That would be like the developers of “Angry Birds” (trademarked) trying to remove all Apps with “Angry” in the title. Or “Birds”. Poor ornithology apps.
Yup, it’s nothing but absurd. Or shall I say: EDGEy?
Update: TouchArcade also published an article on the matter.
Update: A summary of “facts”
Update: Lima Sky responds, they are legally forced to enforce their trademark otherwise risk losing it.
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.
Chapter 5 - Getting bigger and better
The gist of this chapter will be to discuss the simple game project from the previous chapter. I threw everything into one class, clearly not what you want to do for bigger games. But getting from one-class to real code design is a big step which some hesitate to take. I’ll make that easier and discuss common issues and their solutions, such as what to seperate, what to subclass from and how you can have all the seperated objects communicate with each other and exchange information in various ways.
A big topic will of course be how to take advantage of cocos2d’s scene hierarchy and which pitfalls it may have when moving from a single-layer game to one which has multiple layers and even multiple scenes.
As for the chapter title I’m not so sure if that’ll be it. Maybe along the way while I’m writing I’ll change it. Suggestions welcome!
The chapter will be submitted on Friday, July 30th.
What’s your take on good cocos2d code structure?
Did you ever struggle with cocos2d design concepts? Or the cocos2d scene hierarchy? Or how to layout a scene and divide your game into logical parts? Tell me about it.
I know theses questions are somewhat generic to ask. It’s about the things that don’t feel right but there doesn’t seem to be a better, more obvious way. I think we all know some of those, if you do, be sure to tell me! Leave a comment or write me an email.
Summary of working on Chapter 4 - First simple game
The game I chose to make is called Doodle Drop and features dropping spiders and an accelerometer controlled alien trying to avoid the spiders. All in all it got divided into 8 concrete steps. Lots and lots of code comments, too.
It starts simple enough, adding resources to Xcode and adding sprites. It gets more gameplay-esque when the accelerometer-driven player controls got tweaked to provide acceleration and deceleration of the player object. In contrast, the spiders movements are driven only by actions.
I introduce you to two undocumented features of cocos2d, namely CCArray which is since v0.99.4 used to store all children of a node. The other are the CGPointExtension class which has all the functions normally provided by a physics engine, however not every game should link a physics engine just because one needs those math functions. That’s why CGPointExtension comes in handy.
With the ccpDistance method the collision checks are done. Simple radial collisions, and in debug mode the collision radii are drawn too.
In between the CCLabel for the score got replaced with a CCBitmapFontAtlas, because it killed the framerate. I shortly mentioned Hiero and how to use it in principle but for all the details there was no room. But while I was at it I created the Hiero Tutorial.
At the end of the project I added some polish which isn’t described in the book (too many details) but really adds to the game’s look and feel. The spiders drop, hang in there, then charge before dropping down, all done using actions. I’ve also added the thread they’re hanging from using ccDrawLine. And then there’s a game over label which shows even more action use.
One of the principles I followed is to stay away from fixed coordinates as much as possible. So the project, once finished, did run just fine on an iPad. Although the experience is a different one, there’s more spiders dropping and they drop faster but there’s also more safe space to maneuver to.
Oh and, the game art is all mine. Yes, I know … but Man-Spiders do have just six legs! 
This one should be obvious: making games is hard.
What’s not so obvious: making simple games is still hard.
Ever heard someone proclaim “Oh, i could make that in a day!” after having glanced at yet another simple game that’s all the rave on the App Store? I bet you did. Truth is: they’re almost always wrong. Even if it’s someone who has years of experience programming games.
You know Jamie from Mythbusters is saying in their disclaimer shots: “It may not look like it, but we’re professionals”. Well, the Mythbusters are professionals. Who is to say you can’t fool around like a child and still be professional? It’s much like your regular game development team. Anyway, did you ever notice how surprised they often are about their results? Or how much work it would be to get their myths tested? Same goes for game developers.
A game programmer who is sure he can do that game in a day just by looking at it is a lot like your typical Mythbuster, or Mythbuster viewer, who thinks they know the outcome before the test - and then they’re in for a surprise. Sure sometimes they’ll be largely correct. Yes you can shoot a ball at 60 mph in the opposite direction of a car going 60 mph and the ball will just drop down straight to the ground. That is just simple physics. Even i knew that. I also know how to make games. And i can vividly imagine how many more tests and excrutiating amounts of work went into confirming that myth. The same amount of excrutiating work and detailed adjustment go into making any game as well. But they don’t show that on your screen, do they?
Game programmers who can actually make a complete game in a day are a myth. Once you’ve done a couple games you know that. And once you hear someone proclaim they can do it in a day, please take them by their word and put them to the test!
Let’s take Doodle Jump as an example. It’s been a target for ridicule from quite some game programmers who just couldn’t stand that something as simple (and stupid as they say) can be so successful. Could you do it in a day? Could you even do it in a week? Let’s put it to the test!
How?
Simple, we’ll just make a feature list and you can answer the question yourself: how long will it take to complete this? Please post in a comment how long you think it would take to complete all this, assuming you had all the graphics and sounds.
- Menu
- Challenge by Email
- Highscores Screen: Local, Facebook Friends and Global (Webserver connection)
- Options Screen, various options
- Connect & Submit Score to Facebook (Facebook API)
- Connect & Submit Score to Twitter (Twitter API)
- Change your name
- Pause Screen
- Game
- Player jumping
- Accelerometer controls
- Wrap Player when leaving either screen side
- Player shooting on tap
- Scrolling Game Objects as Player goes up
- Scroll in Menu on game over
- 7 different Platform Types, one that can be moved by touching it
- 6 Enemies and 1 or 2 Boss Monsters
- UFOs and Black Holes
- 6 Powerups: Springs, Jetpack, etc.
- Display Friend Scores on the side
- Score display
- Stuff that people often forget to think of
- randomly generate platforms in a meaningful way with progressing difficulty and no unfair situations
- cheats and easter eggs (not mandatory but Doodle Jump has a lot!)
- several themes with all new graphics
Did i forget anything? Probably. Usually when you make feature lists like this you get 80%, maybe 90% of all features of you’re really thorough. There’s always something you’ll forget when you look at a game’s features, and there’s even more you’ll forget when you plan the game. Unless you plan for “When it’s done.” - which more often than not means: never. Or Duke Nukem Forever. Same thing really.
