Question

Currently, I have a game where an object determines a point to go to. It then calculates a path to that point and constructs one long CCMoveTo animation to get to that point. With this method, the animation seems very smooth and continuous.

I am now trying to break this one long CCMoveTo to multiple CCMoveTo leveraging the update method that gets called periodically. I want to do this because at each node of the path that the objects passes through, there might be a distraction and I want my object to be able to act on that. So this is what I am doing:

- (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];
    }
}

Note: that I set isWalking to NO as a callback when the object has completely reached the destination node. This will let it calculate the next node to go to and construct that animation. Without this, the object would try to runAction in the middle of an ongoing CCMoveTo action. The problem with this method is that the movement does not seem smooth and continuous anymore. There seems to be a lag at the end of each CCMoveTo animation

Anybody has any clue on how to fix this?

Answer 1

That’s a side effect of cocos2d’s CCAction system respectively the CCScheduler.

There will always be a 1-frame delay because when an action stops, it won’t do any work in the current frame: it made the last position update in the previous frame, and in the current frame it does no longer exist as a running action.

If you now run another move action in a scheduled method, that action won’t begin updating until the next frame because it will schedule itself to receive updates. And updates that are scheduled while cocos2d’s CCScheduler performs updates will not be run until the next frame, due to the fact that you can’t modify an array during enumeration.

My advise is always to avoid using CCMove* actions for gameplay purposes, and instead manually update position of game objects. It’s easy enough to do, and if you need a code example, look inside the CCMoveTo class.

A workaround would be to extend the distance of the CCMoveTo and replace the action shortly before it completes. Though that’ll be a hack and may actually be harder to implement correctly than manual position updates.

PS: That’s an issue I have addressed in the action model of KoboldTouch. It implements its own action system, with more lightweight and reusable actions.