Chapter 2 – Getting Started
This chapter starts with the usual prerequisites. Download and install iPhone SDK and cocos2d. Installing cocos2d Templates. Creating the first project from a cocos2d project template.
From what I already wrote I estimate that will be about one third of the chapter. I think what would be most interesting in this chapter is to talk about general code structure of cocos2d projects. The basic elements like Scenes, Layers and Nodes. How to transition from one screen to another, to see that we’re actually doing something cool with little effort. For that I think the scheduled selectors should also be introduced to time transitions, and one screen might be a Layer which is waiting for touch input to advance to the next screen.
It might also be a good place to discuss cocos2d memory management, like static autorelease initializers, and making sure dealloc gets called when you switch scenes – otherwise you’re obviously having a memory leak.
The goal is to get the reader into a position where he feels comfortable laying out a screen structure in cocos2d. He knows how to initialize objects and how to add and remove them from the scene. The foundation of working with cocos2d if you so will.
What do you think should be in Chapter 2?
Let me know if you think I’m missing anything important. If you don’t have any suggestions then just think about what you would expect from the chapter by reading this description, that might give you some thoughts.
Also I would welcome any tips and the common pitfalls first-time cocos2d developers might trap themselves into. Expert tips are also welcome, those little nasty things or habits which could bite you later on if you don’t consider them from the beginning.
I’m looking forward to your feedback! The earlier the better. Chapter 2 will be submitted next Friday, July 9th.
What’s planned for the Chapter after this one
Just to put Chapter 2 in context, for Chapter 3 I’m planning to talk about essential cocos2d classes and processes. Sprites, Labels, Menus, Actions, etc. It’ll show you how to work with them using small code snippets. The chapter will probably have a “reference” character with various code samples, so that experienced users feel comfortable skipping ahead while beginners still find it easy and encouraging to pick up the details.
I’m writing a book for Apress:
I guess someone wanted to be very precise and thorough. 
I will blog about the book’s progress here and when it’s published I will add additional materials so readers can continue their journey here. Since this journey is just beginning – I’m submitting the first chapter aptly titled “Introduction” tomorrow – and writing a whole 400 pages book is an entirely new experience to me, I want to let you in on the journey.
Help me help you by providing feedback to the book’s content as I’m writing it!
For the coming weeks, I will announce the current book chapter title and a short description and ask you what you’d like to see in this chapter. I will make these posts every Friday starting tomorrow until the book is complete. In this post you could start by telling me what you’d expect from this book or what you’d like to see in it just given its title? I guess your answer will be “a lot” given the title’s elongated nature. :p
I hope you forgive me if content updates to this website will not be as comprehensive over the coming months, in favor of writing the book and coding sample games. Plus I’m cooking up something special on the side, but all in due time.
Oh, by the way, if you happen to know what kind of fruit that is on the cover I’d like to know. I could just ask my editor but I’d like to see if we can figure it out without the help from Apress. It doesn’t really look like a coconut to me, which would have been fitting given the subject. If you have any ideas what fruit it is, let me know! It sure looks exotic and it’s definetely not a banana nor a lemon. So what is it? The first to post the correct answer in a comment, together with a link to Wikipedia or some other website as proof, gets a copy of the book for free when it’s out (or $40 now)!
And now for something completely different …
As a side note, the Xcode project files from the Xcode Tutorial are now available for download here. I used to ask you to join my Newsletter but I don’t feel too good about hooking you up with my Newsletter using the project as a dangling carrot, so joining the Newsletter will now be a completely voluntary thing. I only send newsletters for substantial updates and important news, at most once or twice per month, so that’s the thing you want if you are already struggling with RSS overflow.
WOS Blog has a post online which really sums up well how i look at the App Store:
“Don’t believe anyone who whines that it’s hard to make money with a really good game on the App Store, viewers. They’re either lying, or imbeciles, or both.”
It’s called How not to do it and covers some basis of why certain Apps succeed while others fall by the wayside. Sometimes it’s a matter of beating someone to the market, other times to learn from other’s mistakes, but mostly to price your Apps fairly.
A while ago i read about Indie game developers who eventually thought it would be a good idea to spend 3-6 months on their next game, to sell the App by means of quality and content. While there are chances that this will work and even reward you greatly money-wise, it also increases your risks by several factors. You’re going down the same path that leads to similar problems of the AAA game developers, albeit on a much smaller scale. It’s a hit-driven business. If you did moderately well on your 1-2 month games, and then you do a 3-6 month game, your chances of making it a success get slimmer and slimmer. It does help to understand the market and marketing but even that won’t help you if the game doesn’t vibe with players.
So, would you rather have a less than 50% chance of making it (relatively) big, or a 100% chance of doing moderately well?
Of course, if you can keep running the 100% part of your business you should really consider making the bet. But if you have no money to spare you should stick with moderately well and instead keep pumping out moderately well doing games. Make 8 of those over the year and you got yourself a respectable business nonetheless.
I wonder what happened to those Indies and their “big project”? Hmmm …
I will take some time off to carefully consider my options.
On May 27th, the whole world saw the future. Because i told you so!
Line-Drawing Game Starterkit –> June 1st!
What’s that you ask?
It is the ideal starting point for your own Line-Drawing game! (like Flight Control and Harbor Master) It is a cocos2d source code project that will be available for sale. But not sight unseen, no. It will appear on the App Store for you to try out. And you get more, the full doxygen-generated source code documentation is available for browsing right now! Just so that you can assess the scope of the project.
What will it cost?
I admit i haven’t decided on that yet.
Show me your license!
Alright, alright. I’ll be fair: Free lifetime upgrades! Unlimited number of developers!
Each license is good for one published game. Additional licenses for follow-up games come at a discount. “Lite” versions do not require an extra license since they are essentially the same game. There will also be a commercial license for developers or studios who make more than $6,000 per month in revenue and can easily afford a higher price.
Why, please tell me why?
Because i can. I like technology and i like programming games. I’m also an enabler and i would love to see others build something unique based on game development technology i provide.
Anything else?
Yes. Today sees the premature end of the best new show of last year. RIP Flash Forward.
If you think your game suffers tremendeously from App Store Piracy, you’re wrong. To put it bluntly: your game has simply failed on the market!
Reports that put the App Store piracy rates at “at least 60%” and developers reporting piracy rates of 80% and even up to 95% are mathematically correct but what they often forget to tell you are actual sales numbers. In the rare cases where Indie developers also mention how many sales they have made, pirates or not, these numbers are always extremely low. For a commercial developer who reports an 80% piracy rate on one of his games it’s simply an attempt to turn terrible sales into a PR story which might give their game a little bit more attention. In fact, i expect the games who report piracy rates of over 30% to have sold no more than 5,000 copies. At $.99 this creates a revenue of $3,500 – maybe a good number for a two-man team but a catastrophe for a commercial developer. This is hardly a problem caused by piracy but a simple failure of the product on the market.
What you have to understand about Software Pirates in general: they use a lot of software. In fact, this is their hobby and favorite passtime, to try out as much software as they can get their hands on. So you will always have a minimum amount of pirated copies of each piece of software, no matter how successful this software is (or not). Of course, with higher success and more sales of the software more pirates are also likely to use it because they, too, value quality software. But given the amount of jailbroken iPhone devices prepared to run pirated software there’s a hard cap of the maximum amount of piracy you will ever see on any title. Just as much as there will be a minimum number of pirates playing every game as soon as it becomes available and regardless of how successful it is on the App Store. If your sales are close or below that minimum number of pirates, you naturally get piracy rates of over 50%. These pirates don’t cut into your revenue however. Ignore them. They never would have bought your App in the first place!
David Rosen from Wolfire reports in his Another View on Piracy article that the highest number of Jailbroken iPhones worldwide is said to be 10%, and in the USA – whose users constitute about two thirds of the iPhone/iPod market – the number of jailbroken devices is just 5%. Assuming a total installed base of 75 Million iPhones (50 Mio. as of April 2010) and iPod touches (20 Mio. as of Sept. 2009) we get at most 7.5 Mio jailbroken devices worldwide, or approximately 2.5 Mio jailbroken devices in the USA. They are not all pirates, however. PinchMedia reports that 38% of jailbroken devices have run at least one pirated App. They also state this number is low. So let’s just take half and we’ll end up with 3.75 Mio. jailbroken devices worldwide which have run at least one pirated App. Still a pretty high number – but it only tells us that they have started one pirated App but not how many or how much of a pirate these users really are. If i had to guess i would say that 10% or just about 400,000 of these users are active pirates who try out a lot of Apps on an almost daily basis. These are the pirates who make the biggest impact in terms of per-App piracy numbers. They are also the users who are least likely to upgrade their pirated copy to a legal one, if they ever do it at all. And trying to fight these pirates is anything but futile – they will never be your customers!
PinchMedia also supports my theory that most Pirates try out as much Software as they can which, of course, leaves less time to use each App intensely: “Pirated applications are used less frequently, less intensely, and for a shorter overall length of time than purchased applications.”
Let’s go back to the gist of it: developers who have a problem with App Store Piracy have, in my opinion, either a problem of perception or they’re making a simple PR statement aimed at getting them more attention, hoping to achieve better sales. The developers who suffer most from App Store Piracy are those who simply are not successful. Their real problem isn’t Piracy, it’s much more likely that they failed either at Marketing, Timing, Quality or finding their Target Audience.
Let me sum this up with a simple chart which i think explains why App Store developers report amazingly high piracy rates, when in fact they are reporting the commercial failure of their App:
Loading ...
Bad user reviews and comments can actually be a good thing
Bad reviews, or simply trash talking and bad-mouthing, can have a positive effect on your game, and yourself. Don’t be overly concerned if some idiots voice their BS and drag down your review score. If you value what you do and others see that value, the positive effect of some bad rep is simply that it encourages others to voice their opinion in favor of the product and you. The things you should not do, however, is to be overly protective and try to remove such posts. That will only serve to earn you disrespect from everyone because freedom of speech is a much higher value. If disrespected, it will earn you much more disrespect in return. If you’re in doubt whether what’s been said is offensive, keep it online until someone complains. The more absurd and unreasonable negative comments are the more happier should be, and you’ll quickly notice other users jumping in to make their case. You, on the other hand, should stay out of it. React to the positive comments, ignore the bad-mouthing and trash-talking that is only targeted to lure you out in the open.
Applied to the App Store, where you have no control over the bad reviews other than complaining about them in your blog: don’t do it. No one cares about your whining on bad reviews. They happen. If your game is really good, it will get good reviews. The bad ones will only serve to encourage others to post their opinion and they often provide good reasons not to listen to “those jerks”. The other bad reviews which are clearly not from idiots you should hold dearly. They contain valuable criticism about your product. It will help you improve. Nothing is more powerful than a dissatisfied customer or someone who was simply disappointed which you were able to turn to your side by listening and reacting to their criticism. People love to criticize, but even more so they love when someone is actually listening and making changes in their favor.
Caveat: some people will always criticize no matter what. And some will always know how to make things even better. Those are the kind of people who could sway you into feature-creep, don’t listen to them, they’ll kill your product the more you try to make it theirs. And some will be jerks for live and just randomly change their opinions on a daily basis, probably based on what they heard or read today, or whether they were drinking or not, or whether today’s weather is good or bad. Listen only to the feedback that is voiced most often, which others agree on and which is consistent.