Game Development Reference
In-Depth Information
[self accelerateTarget:_playerNode];
}
[self scrollToTarget:_playerNode];
}
Here, it is important to accelerate the player before scrolling because scrolling needs the
player's updated position. If you did it the other way, it would still work in general, but
the scrolling would lag one frame behind the player's actual position. This would have the
view follow the player with a minimal but possibly noticeable delay, as if it were dragging
behind the player's position.
Also notice that both methods take the _playerNode as an input parameter, rather than
just relying on the _playerNode ivar being accessible within the method. The exercise
here is to make methods as flexible as possible at no extra cost. Consider that you may
want to accelerate a second player node the same way. You'd just call acceler-
ateTarget: twice with different nodes. Or what if your player has exited the level but
the camera should still continue to scroll to a predefined location in the level? You'd
change the parameter sent to the scrollToTarget: method from the _playerNode
to a node that is at or moving to the desired destination position.
Accelerating the Player
Now add the code in Listing 4-4 just below the update: method. The acceler-
ateTarget: method will move the player sprite by changing the velocity of its
physicsBody component.
Listing 4-4 . Moving a target node by changing its velocity
-(void) accelerateTarget:(CCNode*)target
{
// Temporary variables
_playerMaxVelocity = 350.0;
_playerNudgeRightVelocity = 30.0;
_playerNudgeUpVelocity = 80.0;
CCPhysicsBody* physicsBody = target.physicsBody;
if (physicsBody.velocity.x < 0.0)
{
physicsBody.velocity = CGPointMake(0.0,
physicsBody.velocity.y);
Search WWH ::




Custom Search