A fast, easy to use, free, and community supported 2D game engine
indy2005
Member
Hi,
I have read many tutorials, looked through the samples and am stuck on one very basic point....How is the main game loop implemented. I have seen variations of onEnter, and also update methods, and schedule methods.
Where is the main logic performed in the game loop. In the good old days you would have a loop in main() checking for some end state, and in here you would update the motion, AI, collisions etc in this loop.
How does this basic concept work in Cocos2D....
THanks!!
i
I think the general practice - and certainly the way I do it - is to schedule a selector from your game layer's init method, ie...
- (id) init
{
[super init];
[self schedule:@selector(gameLoop:) interval: 1/60.0f];
// ... etc ...
return self;
}
- (void) gameLoop: (ccTime) dT
{
// Do game logic here
}I don't think the old-fashioned method of while(!gameOver) would work with Cocos2D because you'd be preventing the Director from running all of its other functions. If you want your game logic to be run absolutely as often as possible, you can use the FastDirector and schedule your selector without an interval, which will cause it to be called as often as possible.
Note that dT is the time that has passed since your gameLoop function was last called, in seconds. Thus, if you have any time-based logic, you can use dT to make it work.
Hope that helps.
lingrenM is right...start thinking in more event-driven terms rather then explicitly defining your game loops.
As far as frequency, you will have to play with one that works with your simulation. Simple simulations can even be scaled to 20Hz and maintain stability. It's almost counter-intuitive (maybe not to some) but the higher you set that frequency then the higher the call overhead and the lower your frame rate will be as you will be solving a lot more.
An aside: has anyone successfully threaded Box2d and Cocos drawing?
indy2005
Member
Hi,
Thanks...so when would you use onEnter? From my flash days this was run every frame?
And how does ccTouchesMoved get called automatically? Any layer which has touch enabled = yes, becomes a delegate for the touch events?
-(void) onEnter
{
[super onEnter];
self.isTouchEnabled = YES;
CGSize s = [[Director sharedDirector] winSize];
// create the streak object and add it to the scene
streak = [MotionStreak streakWithFade:3 minSeg:3 image:@"streak.png" width:64 length:32 color:ccc4(255,255,255,255)];
[self addChild:streak];
streak.position = ccp(s.width/2, s.height/2);
}
-(BOOL)ccTouchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
UITouch *touch = [touches anyObject];
CGPoint touchLocation = [touch locationInView: [touch view]];
touchLocation = [[Director sharedDirector] convertCoordinate: touchLocation];
[streak setPosition:touchLocation];
return YES;
}
onEnter is called only once per node, when the node enters the scene - basically whenever it's added to the running scene or any child thereof. There's also onEnterTransitionDidFinish, which is called when your transition into the scene ends, if you're using one.
I should've mentioned it in my earlier post, but as I'm sure you can see you may want to schedule your selectors in one of those two methods. I tended to do it in init for my game because it didn't really matter for my purposes, but if you schedule your selector in init it will actually start running before your layer/node is visible, which could be a problem for you.
You're basically correct about ccTouchesMoved and the other touch handler methods. In order to receive touch events, a layer has to register with the touch dispatcher. If you set the layer to be touch enabled, this is done automatically in the onEnter method. From Layer.h:
/** If isTouchEnabled, this method is called onEnter. Override it to change the
way Layer receives touch events.
( Default: [[TouchDispatcher sharedDispatcher] addStandardDelegate:self priority:0] )
Example:
-(void) registerWithTouchDispatcher
{
[[TouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:INT_MIN+1 swallowsTouches:YES];
}
@since v0.8.0
*/
-(void) registerWithTouchDispatcher;
indy2005
Member
Thanks,
Thats very clear.
Its a but odd moving to an event driven model. You have OS events coming in at any time (touch), selectors firing 30 times a second, and actions potentially running over time - with delays....how it all gets co-ordinated, or what's the best general architecture for all of this is going to be tough (but fun) to find out.
Now that would be a good document....!
Looks like there is a great community here.
i
Blue Ether
Member
Well, It's not necessarily all that different from programming for mouse and keyboard input. Furthermore, its possible to code it in such a way that the touch and accelerometer events just update some tracking variables and have your loop evaluate changes in those variables for proceeding with game logic. Which model is easier and/or more efficient (not usually one and the same thing) depends a lot on what's going on in your game. There's no single right answer to this question.
indy2005
Member
Thanks,
Sounds a good approach to learn from. So your layer is the main conductor of the stage (so to speak). Could I ask, in terms of animating - are you just checking state and then setting off an animation and leaving that to its own devices until state changes again- or are you ever advancing animation manually each frame, for whatever reason.
Thanks
i
I don't have many animations in my game - basically just two different ones - but I actually do a mix of both, because for one of the animations I need to make sure the frames are synced for a number of different sprites which may start animating at different times. For the other animation I just trigger it when a particular instance variable of the sprite changes, and turn it off when that variable changes back.
You must log in to post.
