Game Development Reference
In-Depth Information
No, it's not about scheduleUpdate ; that's just to throw you off guard. The problem
lies in the fact that the -(id) init method is the default initializer, which is eventu-
ally called by any other specialized initializer like initWithFile . Can you imagine
now what's wrong with the code?
Well, initWithFile will eventually call the default initializer, -(id) init .
Then, because this class's implementation overrides it, it will call [super
initWithFile: ..] again. Repeat ad infinitum .
The solution is very simple. As shown in Listing 6-3 , just give the initializer method a
different name—something other than -(id) init .
Listing 6-3. Fixing the Infinite Loop Caused by the Code in Listing 6-2
-(id) initWithShipImage
if ((self = [super initWithFile:@"ship.png"]))
[self scheduleUpdate];
return self;
Bullets Without a SpriteBatch
The Sprites01 project creates a new CCSprite for each Bulet . Notice how in List-
ing 6-4 the ship sprite is adding the bullets to its parent node. It doesn't add them to it-
self—otherwise, all the flying bullets would be positioned relative to the ship and mim-
ic the ship's movement.
Listing 6-4. The Ship Shootingthe Bullets
-(void) update:(ccTime)delta
// Keep creating new bullets
Bullet* bullet = [Bullet bulletWithShip:self];
Search Nedrilad ::

Custom Search