Learn Cocos2D Game Development: eBook is final!

On November 16, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

Just today I was informed that the eBook version of Learn iPhone and iPad Cocos2D Game Development is now available in its final form!

UPDATE: the source code download (also on the book’s page, left side, under Book Resources) now includes all of the source code.

The print edition will follow sometime soon, hopefully within the next ~3 weeks.

On a related note, Ray Wenderlich joined forces with Rod Strougo to help finish Rod’s Cocos2D book, due to an oddly scheduled release date whose publisher apparently feels impossible to postpone. By that I mean to say: Rod’s wife is having a baby. Congratulations to that, and the book! :)

Tagged with:  

Line-Drawing Starterkit: 50% OFF extended!

On November 15, 2010, in Announcements, Marketing, by Steffen Itterheim

Wow! You have to got to be fricking kidding me! It’s not even 24 hours after the 50% off announcement and the codes are almost used up (only 2 left)! 😮

Due to this unexpected success I decided to extend the coupon code offer for an additional 20 uses.

50% OFF – NOW: $89,50

With the following coupon code, you’ll get the Line-Drawing Game Starterkit 50% off – it only costs $89,50 with the coupon code! Just enter this code when making the purchase in the “Coupon Code” box:

LINEDRAWINGKIT4YOU

Secure Online Payments and Credit Card Processing by Plimus

Visit the Line-Drawing Starterkit product page.

IMPORTANT: this coupon code is now limited to 40 uses, and 22 have been used up at the time of this writing. It’ll work only for the next 22 customers and if recent sales are any indication, they may be used up in about 30 hours or less!

Tagged with:  

I was thinking, Ansca Mobile is giving out so many coupon codes – why not do the same? :)

Actually, I have another reason for that. Just a few days ago I received emails from 3 different developers who stated their case and asked me to sell the kit to them for a much lower price, or give it away for free. On one hand, I feel with them. On the other hand, if all it needs is to ask me to give it away for free, and people got wind of that, I could just release it to the public domain to prevent myself from being flooded with emails. 😀

So I’ve sent those three a coupon code each, and give everyone else a chance to get in on the 50% off deal as well. Note that this coupon code is limited to 20 uses, so it’ll work only for the next 20 customers!

50% OFF – NOW: $89,50

With the following coupon code, you’ll get the Line-Drawing Game Starterkit 50% off – it only costs $89,50 with the coupon code! Just enter this code when making the purchase in the “Coupon Code” box:

LINEDRAWINGKIT4YOU

Secure Online Payments and Credit Card Processing by Plimus

Visit the Line-Drawing Starterkit product page.

IMPORTANT: this coupon code is limited to 20 uses, it’ll work only for the next 20 customers!

Starterkit update for Cocos2D v0.99.5

I intend to update the Starterkit to support Cocos2D v0.99.5 once that’s stable. With the recent release of a release candidate (RC) I’m being hopeful that the stable version will be ready soon. With the update the Starterkit will also support HD/Retina displays.

Tagged with:  

The Art of Assertion (as it pertains to Xcode)

On November 9, 2010, in Programming, Xcode, by Steffen Itterheim

Recently, I’ve changed all my project’s source code files from .m to .mm file extensions. This is telling the compiler to compile the files as Objective-C++/C++ code instead of the default Objective-C/C. I needed to do so because I’m using Box2D, and as a habit I intend to use .mm from now on for every source file I create.

However, beware the subtle differences. Previously, if an NSAssert was triggered, it halted the program execution. But in .mm files it simply prints the assertion message to the console while the App continues execution. This leads to overlooked assertions, or continuously dumping assertion messages to the console. Clearly not what I wanted. Changing the file extension from .mm back to .m fixed the problem, but that’s not an option I have for all files.

I looked around and found a blog article by Vincent Gable mentioning that NSAssert is considered harmful. That caught my attention, because it described the same problem that I experienced (NSAssert not halting execution) while basing the argument on Voodoo (“Sometimes it does, sometimes it does not …”) respectively no argument at all, it’s just telling you “NSAssert is unreliable, therefore dangerous”.

It’s as if he wants me to prove him wrong. :)

In Vincent’s defense, the wrong he’s done unto NSAssert he makes up for by having written a great logging method which I’m going to add to gocos because it’s so handy.

Why assert() is less useful than NSAssert

First of all, the assert() function has one big problem: it doesn’t allow parameters to be added to the output string, since the output string can only be a constant string, like in this example:

[cc lang=”objc”]
assert(value < maxValue && @"value too big!"); [/cc] With NSAssert you can actually embedd some values into the assertion message: [cc lang="objc"] NSAssert2(value < maxValue, @"value %i too big (max:%i)!", value, maxValue); [/cc] It is tremendeously helpful in many cases to actually see the offending or interesting values in the error message, without having to fire up the debugger. Especially when it comes to filenames, and even more so if end users might see those assertions. Not a problem on the iOS, but think of developing desktop Apps.

Why NSAssert isn’t harmful, and how to fix it

So then, why did my App not stop execution when an NSAssert triggered? I can’t really answer you that, Apple’s docs say that NSAssert will raise an NSInternalInconsistencyException. So that should stop the App from running? It does not seem to be the case when you’re using the Objective-C++ compiler, and I’m not running the code on a different thread either. Maybe someone can shed some light as to why NSAssert in C++ code doesn’t automatically stop the App from running.

The good thing is, there’s an easy way to fix that. In Xcode choose Run -> Show -> Breakpoints from the menu, to bring up the breakpoints list. In the breakpoint list you only need to add the symbol objc_exception_throw. Next time an NSAssert triggers, the App will stop immediately and bring up the debugger.

Some places (for example: here) will also tell you to add [NSException raise] to the breakpoints list. That’s not necessary, this has been replaced with objc_exception_throw since Mac OS X 10.5.

Turning off assertions

I must admit, I’m totally spoiled by Visual Studio. Why Xcode requires you to add NS_BLOCK_ASSERTIONS as a macro to your project’s build settings in order to not compile NSAssert in release builds is beyond me. If you’re using NSAssert in your code, make sure that your release and/or distribution builds define the NS_BLOCK_ASSERTIONS macro.

If you do use the assert() macro however, or if you’re using a 3rd party library that uses assert(), make sure to also define NDEBUG for release/distribution builds.

As a side note, when I update my cocos2d-project respectively replace it with gocos, it will have all these settings properly configured.

Catching uncaught exceptions

On a related matter, there’s always the issue of uncaught exceptions simply halting your App, with little chance to debug the actual cause. It happens rarely but when it does, it would be really helpful to also bring up the debugger with the current call stack and everything. You can set a global exception handler to catch uncaught exceptions by calling the NSSetUncaughtExceptionHandler in the applicationDidFinishLaunching method of your AppDelegate:

[cc lang=”objc”]
void onUncaughtException(NSException* exception)
{
NSLog(@”uncaught exception: %@”, exception.description);
}

-(void) applicationDidFinishLaunching:(UIApplication*)application
{
NSSetUncaughtExceptionHandler(&onUncaughtException);

}
[/cc]

In the onUncaughtException method you’ll simply log the exception and (very important) add a breakpoint. The NSLog message serves the purpose of being able to easily set a breakpoint inside this method. It should not be another NSAssert because that will throw another exception, which will only serve to make debugging more complicated when a simple breakpoint suffices.

Cocos2D Xcode Project on Github

On November 4, 2010, in cocos2d, tools, Xcode, by Steffen Itterheim

My Cocos2D Xcode project is now on Github. Open-source, free, properly MIT Licensed, includes the rootViewController and supports Cocos2D v0.99.5 rc0.

I’m also working on (with) a greatly enhanced version of the Xcode project. It integrates wax (Lua) and a Game Object Component System that i termed “gocos”. Also comes with a lot more useful convenience classes.

But the big idea is to actually upload (or link within github, if I can figure out if and how that works) all dependent projects into one repository, so that you can download everything at once and it works out of the box. Currently there are 3 projects referenced by cocos2d-project: gocos (let’s call it a library of convenience and gameplay code for Cocos2D), wax (Lua support) and obviously cocos2d-iphone. So everything that’s needed is going to be bundled in one big package, which voids all of the version incompatibility issues.

You can still experiment with different versions of these libraries but in that case I think you know what you’re doing and that issues are to be expected. But being a github repository, you can of course clone and commit changes.

Appetizer

Here’s what I’ve done with Lua. I’m currently using it only as a better plist replacement for settings. It’s better than plist because you can comment on each item, you can sort them easily, you can run functions and algorithms to generate values or load additional data, and in general it’s a lot easier to work with than the plist editor. Here’s a reduced config.lua that is loaded at runtime into a hierarchy of NSDictionary objects:

[cc lang=”lua”]
local config =
{
AccelerometerControls =
{
UpdatesPerSecond = 60, — 60 Hz
Responsiveness = 0.997,
SensitivityX = -2,
SensitivityY = 2,
MaxVelocity = 100,
},
}

return config
[/cc]

And this line of code loads these values and assigns them to the correspondingly named properties of the target class:

[cc lang=”objc”]
[Config loadPropertiesFromKeyPath:@”AccelerometerControls” target:self];
[/cc]

That’s all you need to do to transfer the values from config.lua into a class instance. Huge timesaver! The only drawback is that it currently can’t differentiate between float, int and bool (due to NSNumber), so it currently only supports float properties.

Tagged with:  

TexturePacker goes GUI!

On October 31, 2010, in Marketing, tools, by Steffen Itterheim

The previously command-line-only TexturePacker tool now has a nice GUI. It’s called the “Pro” version and for a reason. So far, I’ve been using Zwoptex for creating Texture Atlases, but I’ll certainly give TexturePacker Pro a try.

At first glance, what I liked was that it told me when the Texture Atlas was “full”, eg. not all sprites could fit into that Texture Atlas. And the always present list of image filenames on the right side is a welcome feature. Although Zwoptex does have this list as well, it’s almost rendered useless because it’s a seperate view option.

Zwoptex’ price has changed since I checked last time, it’s now at only $14.95. TexturePacker Pro costs $17.95, it’s command line version $9.95 and the upgrade from command line to Pro is $7,95, so you’re saving a whopping $0.05! :)

A couple words on pricing

I find both tools are underselling themselves. Zwoptex was initially at $24.95 and even that price seemed “cheap” to me, given how much trouble it saved me and how much faster and more memory efficient it made my projects. I would say that a price range of $30 to $50 would be more than fair for those tools. I can imagine that the TexturePacker command line version at $9.95 and now the Pro version probably forced Zwoptex to adjust its price.

Problem is: this isn’t a market where people choose their tool based on a $3 price difference. Also, it decreases margins for upgrade prices, with TexturePacker upgrade already below $10. Those low-end prices incur a proportionally large amount of transaction fees, paid to the eCommerce vendor, making them less viable. Since this is also not a mass market, but a niche, it would be wiser if both upgraded their prices back to reasonable regions, around or above $30.

Likewise, Particle Designer is also absolutely undervalued at $7.99. Those low prices undercut the value in tools, and make tool development less and less attractive than it already is. And if anything, cocos2d and the other engines need one thing above all else: tools. And good ones!

Be it Ricardos mysterious “world editor” or the Physics + Tilemap IDE (website) or the other game editing tools currently being worked on – if any one of them is being released as a commercial product but sold for less than $30, I’m going to be very mad at you! If it’s less than $60 I’ll still be mad at you, not very, but still mad.

Rant

Seriously, this isn’t the App Store! It’s developers you’re selling to, and they do value useful tools. Just because cocos2d is free doesn’t mean that all tools surrounding it need to be cheap (or free for that matter). Take Sprite Manager 2 for example. It sells for $75 (per seat!) and isn’t all that different from Zwoptex or TexturePacker Pro. If it were a standalone app it would probably pale in comparison! You might argue that SM2 is for Unity, and their developers are less price sensitive – I don’t think so, and some are even more price sensitive because they just made that huge investment in the first place.

In general you could say that those developers who invest several hundred $$ into a game engine (and toolset) are simply more serious about game development. You do have those enthusiasts working with cocos2d as well, but they’re probably outnumbered by a lot of hobbyists and “I’ll give it a try” kind of people who simply join because of the fun involved, and because the only investment in cocos2d is time and they got plenty of that. The question is: do you want to be kind to the hobbyists, or do you want to build a sustainable business? Plus, Zwoptex and Texturer Packer are also being used by Corona developers.

Now you may also be arguing that a cheaper price allows more developers to enjoy the tools and we’re a friendly bunch and not a commercial, greedy corporation. Sure. But those prices do devalue everyone’s tools, so if anyone wanted to build a tool that takes maybe not just 1-2 months to build (initially), but maybe 4-6 months or more before it’s going to be useful, those price points are not very encouraging to start such a project. That doesn’t mean it won’t happen, but I do know that those people who could pull this off, are generally terrible at doing business. And easily influenced by comparable prices, punching a few numbers, and then getting on with their next train of thought which probably involves solving an obscure programming problem.

And the kind of tool that needs this time investment is the one I’ve been looking forward to since I first started working with cocos2d in May 2009. Back at the time I was convinced that by the end of 2009 cocos2d would be having a game editor or at least something to build the GUI and screens with. I wished for a fully-fledged, professional game level editor, with a physics editor, sprite animation builder, asset management, and whatever else you can dream of.

Now, if that ever happened, it shouldn’t cost less than $100. If you can provide killer features like Box2D integration or scripting game logic, ask twice as much. And offer Lite and Pro versions with a variety of feature sets to make the most out of what developers need and what they are willing to pay extra for niche, but very useful features if you need them.

Tagged with:  

Cocos2D Alpha Book: “unprecedented success”

On October 28, 2010, in book, cocos2d, by Steffen Itterheim

I got an email from Apress. They say the Learn Cocos2D Alpha Book “enjoys an unprecedented success”. Other phrases in that email include “staggering number” (which I can’t disclose) and “great positive feedback”.

Wow, just wow! :)

What’s more, it looks like the book will be released early. Currently, it is scheduled for release on November 30th, 2010. This is still a rough date though, and street date may be off by a couple days.

Tagged with:  

Marketing for Indies: an excessively long Link List

On October 22, 2010, in Marketing, Mobile Business, by Steffen Itterheim

I’ve been asked to write something about Marketing & PR a lot of times and repeatedly. It seems to be a topic that’s often sought after and mostly misunderstood.

Sometimes, it’s deceivingly complex, as in “How to get my App featured by Apple on the App Store?”. Who the f*ck knows? If you do, be sure to tell everyone about it!

But when you dig deeper, you learn more about the whole “process” and things become a little clearer. I hear you can get lucky if you know the right people at Apple’s PR or App Store department. At least that’s what I was told personally by someone who does PR and knows someone at Apple personally. Ok, not an option for most of us. I also hear that Apple scans certain websites when looking for App Store features, and for games the #1 site to get reviewed by which in turn might lead to an Apple feature is touchArcade. What else, right?

But getting a review on touchArcade is a different matter altogether. From game industry experience, I can tell one thing that almost guarantees to get your game reviewed/featured: it should be looking awesome! And not just the game, you need a trailer that packs a punch or two, one that’s hilarious or one that’s simply exciting and really wets your appetite. Not easy to do, but well worth the money if you can outsource it to someone who knows how to do it well. And if your game doesn’t have the looks, or can’t have them, it must be uniquely interesting. Combine the two, and you got yourself a winner. That ought to be easy, right?

Well, yes and no. If you know what you’re doing, it can be easy. And it certainly feels easy in such a case. After all, all the work to set yourself up for success has already been done. But if you don’t happen to be working with world-class artists, programmers, designers – what do you do? You can pour everything you have in being creatively unique. To my mind, that’s one of the reasons why the Indie space has become so successful. It’s not just that being unique and innovative is what the developers want their games to be, it’s actually helping them a lot to get coverage in the first place – it’s even a necessity, and a way to success!

The excessively long Marketing Link List

But back on topic, I actually just wanted to share a link list with you. It’s called:

The Big List Of Indie Marketing And Business Tips

Here’s the index … as you can see, it contains a lot more than just links about marketing alone:

  1. Marketing
  2. Press Release Sites
  3. Business
  4. Piracy
  5. Interviews
  6. Game Revenue And Sales
  7. Advertising
  8. E-Mail Marketing
  9. Jobs
  10. Indie Funding
  11. Merchandise
  12. E-Commerce Payment Processors

And one link you should not miss: a free eBook about Videogame Marketing & PR!

Tagged with:  
Page 30 of 37« First...1020...2829303132...Last »