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 Book, Chapter 8: Shoot ’em Up

On August 14, 2010, in book, cocos2d, by Steffen Itterheim

Chapter 8 – Shoot ’em Up

This chapter will finish the shoot ’em up game. There will be enemies and powerups. It raises the issue of good code design when certain things like shooting and moving are common to all objects while other things such as what to shoot and where from and to depend on who is shooting. And then to determine who is hit by whose bullets.

Of course no shoot ’em up game is complete with a boss monster that takes a couple hits to kill. So it’ll need a healthbar. At the end of the chapter this shoot’ em up should be a fully playable game, with Chapter 9 complementing it with visual effects by using the cocos2d particle system. But I’m getting ahead of myself here.

Summary of working on Chapter 7 – Scrolling With Joy

Once again I renamed the chapter a bit since it’s divided into two parts: a parallax, infinitely scrolling background and input via SneakyInput, featuring a fire button and an analog thumbstick respectively at the end changed to a 8-way digital pad.

The parallax scrolling background consists of several bands or stripes which were created on different layers each in Seashore and then saved as individual 480×320 images. They were then added to the Texture Atlas by Zwoptex. The cool thing about this is that Zwoptex preserves the original image’s size while stripping away all transparent parts. So the images take up little space in the Texture Atlas but in game you don’t have to position them individually, you’ll simply place them at the center of the screen.

To achieve the endless scrolling effect two of each image where added side-by-side to each other, with one flipped on the X axis so the images align neatly. Whenever one image has scrolled outside the screen it is moved back to the right side of the screen. At the end I also fixed the vertical flicker lines which can appear due to round-off errors when moving the sprites. And of course they all are drawn with a CCSpriteBatchNode.

The SneakyInput fire button allows continuous shooting and faster shooting when you just tap it, while the thumb stick controls the ship’s movement in both analog and digital (8-way) variants. The Ship class’ setPosition method is overridden to keep the player’s ship within screen boundaries at all times. Finally an extension class gives SneakyInput the same autorelease initializers used by cocos2d, and adds another good example of just how useful Objective-C categories can be.

cocos2d Book, Chapter 7: Side-Scrolling Shooter

On August 6, 2010, in Announcements, book, cocos2d, by Steffen Itterheim

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.

Prefer Composition over Inheritance

On June 11, 2010, in Programming, Speaking From Experience, by Steffen Itterheim

When the question came up whether to subclass CCSprite or use some model class to build your game entity hierarchy in the cocos2d forum, i stressed that one should try not to use inheritance and keep the inheritance hierarchy to as few levels as possible. I’ve worked with codebases with hundreds of thousands of lines of code, and hundreds of different types of actors in the world. Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

The answer lies in composition, often referred to as Game Components by engines like TorqueX and the PushButton Engine (a Flash game engine from the original Torque developers). This video from the PushButton lead developer Ben Garney explains it very well and also illustrates the problem with inheritance over-use in game engines. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

You can read more about PushButton’s Components system in their documentation. How they implemented Components in TorqueX and what the differences are to XNA Game Components further enhances understanding of the concept.

For further reading and arguments read the Wikipedia article on component based software engineering. As a matter of fact, the Objective-C language was invented to be able to create re-usable software components!

Scott Bilas’ GDC 2002 talk about A Data-Driven Game Object System (PDF) as used by Dungeon Siege contains more pointers on why inheritance fails for game developers and what the advantages (but also some caveats) are with component-based game engines. The talk may be old but it’s still as valid today as it was back then. In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

During GDC 2009 a similar presentation was held by Radical Entertainment’s Marcin Chady. The talk was called Theory and Practice of Game Object Component Architecture (PPT).

Mick West wrote an article Refactoring Game Entities with Components which describes the challenges and benefits of changing the Tony Hawk codebase from an inheritance model to a game component system.

A somewhat more advanced read on component use is a collaborative paper called Dynamic Game Object Component System for Mutable Behavior Characters which talks about components in context of finite state machines and NPC behaviors with a rule-based activation system.

The Game Architect blog calls it an Anatomy of Despair and sums up very good what the cons of inheritance-based class design is and how composition solves them.

Blog

On April 17, 2010, in , by Steffen Itterheim
Tagged with:  
Page 3 of 3123