Game Development Reference
In-Depth Information
[enemiesOfType addObject:enemy];
}
}
}
The interesting part here is that the NSMutableArray* enemies itself contains
NSMutableArray* objects, one per enemy type. It's what's called a two-dimension-
al array—an array of arrays.
The initial capacity of each enemiesOfType NSMutableArray also determines
how many enemies of that type can be on the screen at once. In this way, you can keep
the maximum number of enemies on the screen under control. Each en-
emiesOfType NSMutableArray is then added to enemies NSMutableAr-
ray using addObject , just like any other object. If you want, you can create deep
hierarchies in this way. As a matter of fact, the cocos2d node hierarchy is built on
CCNode classes containing a children instance variable of an array that can contain
more CCNode classes, and so on. I mentioned earlier that cocos2d uses the CCArray
class internally. It's an optimized replacement class for NSMutableArray , but as
with all optimizations there are some drawbacks and compatibility issues. With
NSMutableArray you're always on the safe side.
Based on the initial capacity set for enemiesOfType , the desired number of enemies
is created, added to the CCSpriteBatchNode , and also added to the corresponding
enemiesOfType NSMutableArray . While the enemies could also be accessed
through the CCSpriteBatchNode , keeping references to the enemy entities in sep-
arate arrays makes it easier to process them during later activities such as spawning, as
shown in Listing 8-12 .
Listing 8-12. Spawning Enemies
-(void) spawnEnemyOfType:(EnemyTypes)enemyType
{
NSMutableArray* enemiesOfType = [enemies objectAtIndex:enemyType];
for (Enemy* enemy in enemiesOfType)
{
// find the first free enemy and respawn it
if (enemy.visible == NO)
{
 
 
Search Nedrilad ::




Custom Search