Game Development Reference
In-Depth Information
Quite common are
retain cycles
, where you have at a minimum two classes,
A and B. Class instance A has a strong reference to the instance of class B,
and the instance of class B has a strong reference to the instance of class A.
Both instances will not deallocate as long as they strongly reference each
other. You can break the cycle with
__weak
references or by setting at least
one reference to
nil
at a certain point.
Basically, the question to ask when a given object doesn't allocate is: who is (still) holding
a reference to this object? That makes it somewhat easier to debug because you can con-
centrate on checking every assignment of the object to another property, ivar, or collection
(
NSArray
,
NSDictionary
, etc.) and whether that reference is still non-
ni
l at the time
you expect the node to deallocate.
Summary
You now know how to debug and fix any problem within seconds. Okay, not quite. But I
do hope this chapter served to introduce you to the various means of debugging and ana-
lyzing an application, as well as common problems and best practices when working with
SpriteBuilder and Cocos2D.
If you have any questions or suggestions about the topic, SpriteBuilder, or Cocos2D,
please stop by on the SpriteBuilder and Cocos2D forums.
You will find me most active at
stackoverflow.com
. If you include the
spritebuilder
or
Cocos2d-iPhone
tags in your question, there's a good chance I'll have an answer or
suggestion for you.
I should also note that this topic ends here. I hope you enjoyed reading it and, preferably,
learned something from it. You'll definitely learn a lot by making your own games and,
above all else, I hope you'll enjoy making them.
