目前，我有一个游戏，其中一个对象确定要去的点。然后它计算到该点的路径并构造一个长CCMoveTo动画以达到该点。使用此方法，动画看起来非常流畅和连续。
我现在正试图利用定期调用的CCMoveTo方法将此CCMoveTo多个update分解为多个- (void) update: (ccTime) dt
{
if(![self isWalking]){
CGPoint nextNode = [_path objectAtIndex:(_currentPathIndex%[_path count])];
_currentPathIndex++;
NSMutableArray *actions = [[NSMutableArray alloc] init];
[actions addObject:[CCCallBlockO actionWithBlock:^void(id obj) {
[(Monkey *) obj setIsWalking:NO];
} object:self]];
[self moveTo: nextNode withCallbacks: actions];
}
}
。我想这样做是因为在对象经过的路径的每个节点处，可能会分散注意力，我希望我的对象能够对其进行操作。所以这就是我在做的事情：
isWalking注意：当对象完全到达目标节点时，我将NO设置为runAction作为回调。这将让它计算下一个要去的节点并构造该动画。如果没有这个，对象会在正在进行的CCMoveTo操作中尝试CCMoveTo。 这种方法的问题在于运动看起来不再平滑和连续。每个{{1}}动画
有人对如何解决这个问题有任何线索吗？
答案 0 :(得分：1)
这是cocos2d的CCAction系统和CCScheduler的副作用。
总会有一帧延迟，因为当一个动作停止时，它不会在当前帧中做任何工作：它在前一帧中进行了最后一次位置更新，而在当前帧中它不再是作为一个运行动作存在。
如果您现在在计划方法中运行另一个移动操作，则该操作将不会在下一帧开始更新，因为它将安排自己接收更新。由于在枚举期间无法修改数组，因此在cocos2d的CCScheduler执行更新时安排的更新将不会运行到下一帧。
我的建议是始终避免将CCMove *操作用于游戏目的，而是手动更新游戏对象的位置。这很容易做到，如果你需要一个代码示例，请查看CCMoveTo类。
解决方法是延长CCMoveTo的距离，并在完成之前不久替换该操作。虽然这将是一个黑客攻击，实际上可能比手动位置更新更难实现。
PS：这是我在KoboldTouch的行动模型中提到的问题。它实现了自己的动作系统，具有更轻量级和可重用的动作。