cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   Jeston
   Member

   Greetings Community,

   I am looking for some advice on some cocos2d related concepts, and keep in mind my prior styles were an outcome of C#/C++. My questions are namely in architecting communication between layers and code infrastructure but I will just list my questions in hopes of advice

   1. Normally, I call an objects function with an instance variable. ie: The Menu class would have a reference to the main game class, and would call something like StartGame when the Start button is pushed. In cocos I have a GameScene which contains 2 layers: Menu and Game as the menu is just a floating menu over the game as opposed to a separate scene.

   It seems the standard is to make calls through a NSNotificationCenter; but is this un-needed overhead to have listeners in what is an effective way of making calls in other classes? or is it frowned upon to pass instance pointers around?

   2. I have a simple text file which lists all my precached 'master' sprites and animation files. Upon reading this file I dynamically create sprites during the game's LoadGame sequence. When loading animations this causes a loop of reading the path and creating an Animation using the addFrameWithFileName. I am afraid that under the hood this may use up my texture space as projects grow larger in asset size. My guess is that this comes to a debate on using AtlasSpriteManager with a sprite sheet as opposed to having animations whose frames are in separate files.

   In Essence, is this a bad style to have for all animations.

   Animation *croakAnimation = [[Animation alloc] initWithName:@"croak" delay:0.1];

   NSString *path;
   for( int i = 1; i<37; i++ )
   {
   path = [NSString stringWithFormat:@"frog-croak-inflate%04d.png", i];
   [croakAnimation addFrameWithFilename:path];
   }

   id croak = [Animate actionWithAnimation: croakAnimation];

   3. Is there a more appropriate way to do a deep copy of a sprite ? For now, I have just created a spriteFromSprite call which creates a new Sprite based on the other's texture.

   4. Should I register a tick once on the root GameScene and delegate the message to children or is it better that each object in the scene register the tick with the Director?

   5. Any pointers on dealing with Landscape to Potrait switches during a transition? Going from SceneA to SceneB, I want SceneA to fade out, switch modes, and see Scene B fade in. I guess I could re-write the FadeTransitions to make this call but I feel transitions should not have code calling anything from the Director.

   That is all I suppose, at least for the simplest of first timer games I am making. I appreciate any comments in advance.

   Posted 2 years ago #
2. 

   Codemattic
   Moderator

   you make a good point in #3. Future versions of Cocos2d will be serializeable, but maybe CocosNode, Sprites, etc... should follow the NSCopying protocol too? Is that something developers would use?

   Posted 2 years ago #
3. 

   Clain
   Member

   @jeston :

   1) Your menu knows its parent (the scene) and can call any method on it. The scene knows both the game and menu layers, so you can use the scene as a proxy. Or you can pass pointers around as you said. Or use a singleton that keeps track of some relevant class instances. Or go the NSNotificationCenter way. Whatever works best or seems simplest to you. I usually use parent nodes as proxies and/or singleton. You could try using several of these techniques and find out by yourself which one you prefer.

   2) It is a bad style if your png files for the animations don't have power-of-two dimensions (like 32x64, 128x128, 512x256, etc) because you'll waste memory. If so, it's a good idea to use AtlasSprites.

   3) As Codemattic pointed out, a more appropriate way would be to copy the sprite. And to do that, the Sprite class should conform to the NSCopying protocol, which is not currently the case (0.8.2). I've never had to copy a Sprite so far, but if there's no overhead in having sprites conform to this protocol, then I guess it wouldn't hurt to add it to the framework.

   4) See answer 1 (what works best for you). It's been discussed several times in this forum. I'd rather use (actually, I use) a scheduled selector for every cocos node that needs it. I think this way the code is clearer and easier to understand/debug than putting everything inside a single scheduled method on the main scene.

   5) Never needed to do that before so don't know about it.

   Posted 2 years ago #
4. 

   vahala2009
   Member

   #4： One main tick make the code hard to mantain espacially for complext project and u have to caculate time span for each different tick process logic. Have a deep code review at Scheduler.m and .h file, u will konw there are just one NSTimer for all the tick update.

   Conclusion: use tick free even for a signle cocosnode as u will, but keep the total tick count under 20 , Devided them by category.

   Posted 2 years ago #
5. 

   slipster216
   Moderator

   #1:

   The advantage to using NSNotification is that of loose binding. It's unnecessary overhead to use in the case you describe, and an instance pointer is much simpler to work with. Also, there's nothing stopping some other class from sending out a notification with the same name as yours, causing strange behavior.

   NSNotification allows you to send a generic event to be received by any object which cares about such events. In the case you describe, it's highly likely that the menu buttons will all call a series of functions on a single object, thus NSNotification doesn't buy you much; just use a pointer instead.

   Generally speaking, I use NSNotifications when I expect that the event will likely trigger many things to happen across many objects, which are not centrally owned by a single object. Imagine that we have three different types of enemies in the game and we want to call some function on them when something happens in the game. We might do something like this:

   int count = [myArray count];
   for (int i = 0; i < count; ++i)
     [[myArray objectAtIndex:i] doSomething];

   The first problem with this is that all of these objects will either need to derive from the same base class with a doSomething function in them, or will have to conform to a @protocol that defined that function. Another problem is that we have to keep these objects around in an array or 3 or more to find them all, and this class must know and track all of these objects at all times.

   With NSNotification, each class can decide if it cares about this message, does not need to inherit a common base class or implement a @protocol, and nothing else needs to know about that object. As you add new objects, you can simply subscribe to the events you care about and the class which fires the events doesn't need to know about those objects. This becomes very useful in team-coding dynamics, as one person can define a series of game events and others can create objects which respond to them without modifying the class which sends out the event messages to know about those objects. It can also make refactoring your code much easier when your design changes, because you don't have to change which instance pointers are passed around and tracked.

   Another technique I use is to define externs for singleton objects in my code, such as:

   extern GameScene* TheGame;

   This way access to common singleton objects are available from anywhere in my code. I can do things like:

   TheGame->BeginGameOver();

   Without having to pass in instance pointers and cache them.

   #2:

   If your app is simple enough and memory/speed is less of a concern then it's just fine. However, if you want to keep things more optimized look into sprite sheets using one of the available atlas systems. I personally prefer zwopple's system over the cocos one right now; but your needs may be different than mine, and in 0.9 cocos's system should have the best of both worlds anyway.

   #3:

   Yeah, NSCopying would make sense. Strangely I've never had to do it either up until this point.

   #4:

   I generally have each node do it's own scheduling, but in Splat I had a powerup that slowed time, so I used a central scheduler for the game and modified the delta time when passing to children so I could slow down time. I suppose I could have changed the director to support time scaling, but I try to keep cocos clean of hacks unless they're likely to make it back into the trunk.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.