Stu Gisborne is the developer of Orbs Away, a match-3 game using hexagon tiles.
Stu wrote a quick introduction to using Hexagon tiles with Cocos2D and how he built the match-3 game with it.
PS: sorry that this post was delayed by 12 hours, things tend to get crazy shortly before Xmas. And then there’s all this snow. No, I don’t have a better excuse. 
December 1st, 2010.
It’s the time of year again where we all get in the mood for gifting and loving and caring and, oh well, that kind of crap. On the bright side, it does mark the beginning of 25 exciting days, each packed and gift-wrapped with a brand new link of interest for Cocos2D developers. Now that’s the spirit!
Attraxxion Postmortem
And the first link comes from John Talarico, co-founder of Runaway Creations, Inc. He posted a two-part Postmortem about their first Cocos2D based game Attraxxion (App Store: full version / free lite version) following the regular What Went Right and What Went Wrong convention of postmortems.
Attraxxion is a physics puzzle game that involves gravity, shooting masses at the proper angle towards the sun so that eventually a solar system forms and is able to harbor alien life. The game has been in development for 7 months by a team who didn’t have any previous Mac development experience but they have extensive experience developing software in general.
Attraxxion Postmortem, Part 1
Attraxxion Postmortem, Part 2
Add your link to the Cocos2D Linkvent Calendar
Do you have something to share with the Cocos2D community? I haven’t received enough submissions to fill all the days until Xmas, although I do have enough links to post one each day, I’d rather post a link to your website or blog post.
You may have heard about the Appvent Calendar by Blacksmith Games, creators of Floop and Plushed. From that idea emerged the popular Free App A Day website.
I thought, maybe I can take this idea and transform it into something slightly different: the Cocos2D Linkvent Calendar 2010. The idea being that I publish a blog post every day in December 2010 - you know, the month that ends after 24 days in that culminating event that will crash the App Store and end humanity’s existence. Or so I’ve heard. Each blog post will link to your website, blog post, tutorial, product, open source project or whatever else that might be of interest specifically to Cocos2D for iPhone developers, as long as it is “your thing”.
As my blog is closing in on 5,000 visits a week and my Twitter account is followed by over 1,400 hummingbirds and more and more of my book readers will come here and check out the site, I think that would be a nice gift to anyone who is interested in receiving some traffic from me. What you do to deserve a link is up to you. This is your chance to make your blog better known, or even kickstart it. The better and more relevant the content is to Cocos2D developers, the better your chances are that some of this traffic will stick, in form of return visits.
What you can do
Just to give you a few ideas:
- write a postmortem of your game, and your game will surely get a few extra sales as well
- open source your previous game’s source code, and in turn announce your new project
- lower the price of your commercial product on that day
- receive more attention for your technical essay about some aspect(s) of Cocos2D
- write an awesome tutorial, for example about integrating UIKit controls in a Cocos2D project
The only thing that’s important is that the article, website, product, game, etc. is somehow relevant and of interest to Cocos2D developers. So if you “only” have a game made with Cocos2D, you should spice that up by, for example, talking about your development experience or explaining how you solved some tricky aspects of the game’s source code, including examples.
Accepting Offers Now!
I’m accepting offers now and until all 24 slots are filled, while holding a few reserve slots just in case. Please send all link requests by email to linkvent (at) learn-cocos2d.com - you don’t want to spoil the fun by posting it as a comment!
Also, you can reserve a slot by letting me know what you have in mind and are going to do, without actually having to have something to link to right now. You should be able to prepare and publish your content by early to mid December though.
I probably can’t answer all request, but if I do include yours then you’ll get a notice when I’ll publish it. Keep in mind that I will publish posts on midnight Central European Time (CET) (UTC+1), so you may have to factor in time zone differences.
Note: this is all about helping individual developers and products receive the attention they deserve while giving Cocos2D developers some useful information to digest. For that reason, I won’t link to posts on forums, wikis or other aggregating sites, to Apps on iTunes or to a code repository with just some files in it. There ought to be something to read, a little guidance if you will, and it should come from you, and it should be connected to you by putting that up on your blog or website. You can then of course link from your post to wherever you like.
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?!?! 😮
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.
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 …
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.
