The important bit first: the price of the Line-Drawing Starterkit is back at $179!
The simple reason: customers voted with their wallet, it sold zero units at the $299 price point over the last two weeks while people kept asking me for rebates and price drops. I clearly misjudged the value proposition of the Starterkit and how much potential customers would be willing to spend.
About Thinking, Learning and Knowing
I’m going to be upfront about the sales numbers because I want to be instructive and convey the lesson’s I learned. I also find these numbers posts very intriguing myself. One of the things I love about working under my own terms is that I can choose how transparent you want to be. I feel there’s more to gain from transparency, being open and upfront, and sharing what you know then there is to lose.
I’ve actually been told a few times that you can’t sell to cocos2d developers. Which I find astonishing. “I don’t think there are sufficient willing customers” was the one sentence I received in an email which I find most telling. Thinking is not knowing. Thinking is: not knowing! Trying and not succeeding is ok, but thinking and not even trying is not. The former you might regret financially but seldom will you regret having done it. The latter is just being complacent and accepting the status quo, or simply a reluctance of pursuing unconventional business ideas.
I can only say: I’ve learned a lot from running this website over the past 4 months. Certainly more valuable lessons and knowledge than from most of the books I own, and the above selection is just a fraction of my library. They are the books I hold most dear and are most relevant to my work right now, including Stephen Hawking’s Universe in a Nutshell as the perfect separator between left-brain (hard skill) and right-brain (soft skill) books. It puts everything in the proper perspective. I certainly didn’t expect to learn some of the lessons nor was it easy to deal with the very unexpected ones, but I did nevertheless. The good part about the hard lessons is that they make me think even harder to learn what I need to know to understand. I also have a bunch more unconventional ideas now. And I grok Invictus.
The Numbers
The Line-Drawing Game Starterkit has been on sale (40% off back then) from July 10th to August 1st, that’s 23 days. From July 10th until the public announcement on July 20th the sales were limited to my Newsletter subscribers, close to 670 people were given the password to access the sales page at the time.
When I formed the idea of selling a Starterkit, I punched some numbers about website traffic, pricing, conversion rates, looking at other products, thinking of what certain indicators could mean, why people are having success and why others don’t. Being a pessimist I came to about 3 sales per month if the price is around $200. That would have been nice, and would have allowed me a return of investment in less than 6 months. And when I was optimistic I thought I could be making up to 5-10 sales per month, perhaps by being featured prominently. I definitely had enough positive indicators to go ahead and try making and selling the Starterkit and being sufficiently convinced that it’ll have a positive impact, financially and otherwise.
The reality is that I sold 30 copies at $179 each within 23 days! Way, way more than my expectations. See the screenshot of the payment report to the left for the monetary details. Note that the first section with 3 sales were test sales by myself, so that amount should be deducted from the total. Also, 30 times $179 does not equal the sum on the bill because surcharge fees depending on the payment method have already been deducted. Net sales is the amount after Plimus took their share, which is close to 5% if I remember correctly.
I estimated my return of investment (break even) at about $4,000. So overall it’s not bad. Not bad at all given that I made all those sales in 23 days instead of months.
The downside to this story is that after setting the price high at $299 I did not make a single sale in the past 2 weeks! This price point seems past a certain pain threshold that developers are feeling comfortable spending. Customers voted with their wallets and I basically killed my own business by modifying just one (crucial) aspect of it. I was my own worst enemy by making a wrong judgement call.
And of course I’ll try to fix it: from this day on forward the Starterkit’s regular price will be back at $179! It has proven to sell at this price point and I’m hoping to see sales pick up again. Despite this no-sales period of over 2 weeks the Starterkit earned me $120 per day on average, or an hourly rate of $15 assuming a regular 8-hour work day.
The Future
If it turns out that continued sales from the Starterkit allow me to live off it, I’m going to run this website full-time in the near future. That means more free stuff, more intriguing blog posts and every once in a while a new commercial product that targets very specific unfulfilled needs of cocos2d game developers. You might consider the cocos2d book to be one of these commercial products, and I intend to improve it after press by listening to reader’s feedback and filling any holes with free Tutorials and FAQ entries on this website. It will be a book that continues to get written.
More Lessons to learn
If you want to learn some business & marketing lessons in general I recommend reading The Long Tail to understand how niche markets work and Influence: The Psychology of Persuasion for a lesson in marketing which I find important to understand both from the seller’s and the customer’s point of view. The Long Tail was instrumental for me to actually become comfortable with the thought of selling a product to a niche audience and why that idea might just work. But also instrumental because I just keep shaking my head when I read the naive comments of some people. That’s also where how to deal with critics comes in handy.
Over 9,000 visits in the past month with 40% new visits. 40% of that traffic is driven by google, close to 30% is direct traffic (which I believe includes Twitter) while cocos2d-iphone.org sends less than 10% of the total traffic. My own and recently neglected blog (last post May 23rd) gaminghorror.net still sending about 5%.
I am having a hard time making anything out of it actually, I have been running only one other notable website before and the focus and traffic stats were wildly different. If anyone would like to share and compare numbers I’d be happy to do so. Especially I’m interested if the ratio google vs direct traffic vs cocos2d-iphone.org is comparable to your numbers, or possibly totally different. I also don’t know what numbers can be considered good, ok or bad numbers, especially in context of cocos2d related websites.
The short little peak on July 10th was when I sent out the Newsletter announcing the closed sales period of the Starterkit, the plateau on July 19th was coming from the public announcement of the Starterkit. It’s notable that both resulted in the same number of visits but the Newsletter spike was very short-lived since most people are reading their emails within 24 hours. A funny self-made statistic: I’m able to convert approximately 0,0034% of website visitors to Starterkit customers. How is that for a conversion rate?
I did notice two things, which both surprised myself. One is how cocos2d-iphone.org accounts for less than 10% of the total traffic. The only time I saw a real spike in traffic from cocos2d-iphone.org was with the blog post announcing the Learn cocos2d website. That’s when the website was all fresh and new, and everyone went there at once to check it out. Interestingly, that wasn’t a spike followed by a severe drop-off by several hundred %, instead it created just over twice as many visits as the website gets on average anyway. The other thing I’m stunned to see is how the total number of visits curve over the whole time is astoundingly flat, especially for a website which is less than 3 months old:
Double-Rainbow all the way! But what does it mean?
I have no idea, mostly because I have nothing to compare it to. Maybe you have some thoughts or website statistics you’d like to share?
Here are the full learn-cocos2d Google Analytics results from the last 30 days as PDF:
Analytics_www.learn-cocos2d.com_20100625-20100725_(DashboardReport)
I hope you’ll find that interesting. I know, it’s data alright … boooooring. 😀
While helping others solve their cocos2d project issues over the past year it became obvious that many projects have at least one major problem in one of these areas:
- memory management
- resource management
- code structure
Examples
Memory management issues normally range from allocating too much memory, either by loading too many textures up front which are only going to be needed later, or by memory leaks such as scenes not deallocating when switching scenes. Resource management problems range from not adding the right resources to the right target, often resulting in increased App size because resources are added to the bundle but never used by the App. It could also mean loading identical resource files except that they have different filenames (copies?), using up additional memory. Or not tightly packing sprites into Texture Atlases but instead using one Texture Atlas per game object - while this is understandable from a standpoint of logical seperation it does waste opportunities for optimization.
Finally, code structure or lack thereof regularly leads to “everything in one class” code design which is most likely an evolutionary process rather than intentional. It’s not uncommon to see classes with thousands of lines of code, sometimes even going past 10,000 lines of code in one class. Other things are using too many CCLayers without them adding a clear benefit, for example just to group all nodes at a specific z order together or to group them by functionality, eg one layer for enemies, one for players, one for background, one for UI, one for score, one for particle effects, and so on - without any of these layers being used for what they’re really good at: modifying multiple nodes at once, like moving, scaling, rotating or z-reordering them. And of course there’s the copy & paste hell, large blocks of code reproduced in various places only to modify some parameters instead of creating a method which takes the modifiable parameters as arguments. Even professionals I worked with got so used to doing that it became hard just to overcome the resistance of letting go of old habits. But they learned.
Summary
Nothing of this code design and structuring strikes me as odd or surprising. I’ve written code like this myself. I also believe if it’s good enough and works, then why the hell not? It’s a matter of experience and it’s only with experience that you clearly see how to improve things. This boils down to the regular learning curve where only training and tutoring and just simply making mistakes and learning from them helps in the long run. That’s how we learn things.
On the other hand, the things like Memory and Resource Management can also be learned but they have a different nature. They can be statistically assessed, they could be calculated and verified automatically. This makes me wonder if there isn’t some kind of automation and information tools that would help developers achieve better results in terms of memory usage and resource management? In the meantime it’s all about raising awareness …
Raising Memory Awareness
Most importantly I think we need to raise more awareness to these issues to cocos2d developers. One step towards that would be for cocos2d to display a “available memory counter” alongside the FPS counter. I used to patch CCDirector to simply display memory instead of FPS since that was always more important to me. Fellow cocos2d developer Joseph sent me his version to display both - I simply didn’t think of the obvious. So if you’d like to see FPS and available memory next to each other I think you can handle the changes to CCDirector outlined here:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
// CCDirector.h, add below @interface: +(double) getAvailableBytes; +(double) getAvailableKiloBytes; +(double) getAvailableMegaBytes; // CCDirector.m, add as appropriate: #include <sys/sysctl.h> #import <mach/mach.h> #import <mach/mach_host.h> [...] +(double) getAvailableBytes { vm_statistics_data_t vmStats; mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT; kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount); if (kernReturn != KERN_SUCCESS) { return NSNotFound; } return (vm_page_size * vmStats.free_count); } +(double) getAvailableKiloBytes { return [CCDirector getAvailableBytes] / 1024.0; } +(double) getAvailableMegaBytes { return [CCDirector getAvailableKiloBytes] / 1024.0; } [...] -(void) showFPS { frames++; accumDt += dt; if ( accumDt > CC_DIRECTOR_FPS_INTERVAL) { frameRate = frames/accumDt; frames = 0; accumDt = 0; // the only change in showFPS is this line: NSString *str = [[NSString alloc] initWithFormat:@"%.1f %.1f", frameRate, [CCDirector getAvailableMegaBytes]]; [FPSLabel setString:str]; [str release]; } } |
Raising awareness to leaking Scenes
In addition I highly, strongly and with utmost reinforcement (without pulling out a gun) recommend to cocos2d developers to frequently check your scene’s dealloc methods. Preferably add a breakpoint there, or at the very least add the logging line: CCLOG(@”dealloc: %@”, self). If you want a more visible but less intrusive method you could do something like flashing the screen or playing a sound whenever the last scene is deallocated, so that you get so used to it that when you’re not seeing or hearing it anymore it immediately raises your attention.
If at any time during the development of your project the dealloc method of a scene isn’t called when you change scenes, you’re leaking memory. Leaking the whole scene is a memory leak of the worst kind. You want to catch that early while you can still retrace your steps that might have caused the problem. Once you get to using hundreds of assets and thousands of lines of code and then realize the scene isn’t deallocated, you’ll be in for a fun ride trying to figure out where that’s coming from. In that case, removing nodes by uncommenting them until you can close in on the culprit is probably the best strategy, next to using Instruments (which I haven’t found too helpful in those cases).
I ran into such a problem once because I was passing the CCScene object to subclasses so that they have access to the scene’s methods. The subclass retained the scene and was itself derived from CCNode and added to the CCScene as child. The problem with that: during cleanup of the scene it correctly removed all child nodes but some of the child nodes still retained the scene. Because of that their dealloc method was never called, and in turn the scene was never deallocated.
I’m pleased to announce that the Line-Drawing Game Starterkit is finally available for sale! It’s a source code project for anyone interested in developing a line-drawing game. The gameplay is modelled after the famous Flight Control game. The Starterkit works with the latest cocos2d v0.99.4 version and will at the very least receive compatibility upgrades for future cocos2d versions.
Hop on over to the product page to check out the feature list, the API documentation and a source code sample. You can also download the Starterkit App for iPhone from iTunes. The iPad Edition is still in approval.
Note: for the reminder of July 2010 you can get the Starterkit at an introductory price for only $179!
Positioning of the Starterkit
I’m sorry that you’ve had to wait one and a half months compared to the initially planned release date of June 1st. I double and triple checked every decision I made and you can see some of the results on the Starterkit product page.
I’ve also decided to increase the regular price from the initially intended $199 to $299 effective from August 1st, 2010. One of the reasons being that I initially planned to have multiple licenses including Indie and Commercial ones. I thought long and hard about positioning the Starterkit and eventually decided to sell only Site Licenses. For the individual developer it costs a bit more but for small and commercial teams it’s great news, and small teams and established, dedicated developers is who I am targeting. Those who really appreciate the value of commercial source code saving days and weeks of research and development, and all the trouble, sweat and pain associated with it. And I’m here to help if you have any questions regarding the Starterkit’s source code.
I don’t have plans to make another Starterkit and in all likelihood it will remain the only commercial cocos2d-related product for the remainder of this year.
Book Chapter about Line-Drawing Games
For those who are disappointed about the new price, either grab the Starterkit before August 1st or wait until December for the Learn iPhone and iPad Cocos2D Game Development book I’m writing. It will contain a chapter covering some of the basic aspects of a line-drawing game but without the finer details and complex interactions conveyed in the Starterkit. It’ll be Chapter 12 so in about 8 weeks (Mid-September) I’ll mention it in my weekly book chapter posts.
Closed Sales Period, Summary of
And here’s for transparency: exactly 10 days ago I informed the 668 subscribers of my Newsletter of the closed sales period. The password-protected Starterkit product page received just over 200 unique visitors. During the last 10 days I made 9 sales amounting to about $1,530 with Plimus’ 5% fee already deducted but obviously before tax. All sales were made within the first 4 days after I sent the Newsletter and for the last 6 days sales were absolutely zero. Although I’ve been in contact with several interested parties who didn’t want to or simply couldn’t buy it right now for various reasons. If you’re one of them: you’ll get it for $179 no matter when you make the purchase, just contact me beforehand.
Right now I’m curious to see how sales will be now that the Starterkit is publicly available.
Starterkit Promotion
I’d appreciate if you would tweet and re-tweet this post and mention the Starterkit to all fellow cocos2d-sians! If you would even go so far as writing a serious and honest review on your blog, please get in touch with me.
Just don’t test the waters by mentioning the Starterkit in the cocos2d community forum.
Stance Lance
I wish Ricardo had taken the time to be considerate and then talked to me instead of running off making an assumptive, excessive, and for the most part irrelevant (off-topic) stance post which only served to cause a big commotion among his community while allowing his forum rule “Treat people with respect.” to become a farce.
In Conclusion
In hindsight I’m glad that the whole thing got me thinking in so many new directions. Most importantly it got me in contact with a lot of developers who consciously don’t post on the cocos2d forum. To get those encouraging words and positive feedback and gaining interesting insights from other developer’s perspectives - especially those who tag along silently - really helped me understand the cocos2d development community better. Thank you, you know who you are!
The whole shebang also served as a great motivational factor to pour my everything into the cocos2d book, which came at just the right time to let off steam in just the right way. I’m writing it to be the cocos2d documentation it deserves and the one I always wished it had. I can’t even begin to describe how satisfying it feels to write this book. So much in fact that it hurts to stop writing every time I reach the 27 pages each chapter is expected to have. 
I keep running into posts where users ask how fast cocos2d is, or why their particular code is slow.
I compiled a procedures checklist that you should go through before reporting performance issues.
I also tried to explain why the question of how fast cocos2d is has no real-world relevance.
Then i added a link to All-Seeing Interactive’s cocos2d Performance Tips as this is such a great post! It covers a lot of topics:
- Profiling with Instruments
- Testing on different devices
- Textures and Texture Atlases
- Speeding up loading times
- Reducing memory usage
- Flipping textures
- Pixel formats
- PVRTC (Texture Compression)
- CCSpriteSheet
- Pre-render programatically generated textures
- Avoid using atomic accessors
- Read the best practices documentation
As always i hope you find these additions help- and useful.
The Resources section contains FAQs and Tutorials for cocos2d for iPhone as well as Xcode, Objective-C, iPhone SDK and everything else iPhone game developers need to know.
Note: the resource pages are no longer updated but remain here for reference.
If you need more help please consider buying my Learn Cocos2D book. The other resources (Xcode project, free source code) have been migrated into the Kobold2D project.
