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
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