Game Development Reference
In-Depth Information
// in Node A
[self scheduleUpdate];
// in Node B
[self scheduleUpdateWithPriority:1];
// in Node C
[self scheduleUpdateWithPriority:-1];
This may take a moment to sink in. All nodes are still calling the same -(void) up-
date:(ccTime)delta method for themselves. However, scheduling the update
methods with a priority causes the one in Node C to be run first. Then the one in Node
A is called because, by default, scheduleUpdate uses a priority of 0. Node B's up-
date method is called last because it has the highest number. The update methods are
called in the order from lowest-priority number to highest.
You might wonder where that's useful. To be honest, they're rarely needed, but in those
cases it's quite useful to be able to prioritize updates, such as when applying forces to
physics objects before or after the physics simulation itself is updated or ensuring that
the game-over condition is checked only after all game objects have run their update
methods. And sometimes, usually late in the project, you may discover an odd bug that
turns out to be a timing issue, and it forces you to run the player's update method after
all other objects have updated themselves.
Until you need to solve a particular problem by using prioritized updates, you can
safely ignore them. Also, keep in mind that each prioritized update method call adds a
little overhead because the methods need to be called in a specific order. A quite com-
mon implementation for prioritized updates is to have a central object driving the game
update of other objects by forwarding the update methods to the objects in the desired
order. That way you can also see clearly in the code which object gets called when:
-(void) update:(ccTime)delta
{
[inputHandler update:delta];
[player update:delta];
[enemies update:delta];
[physics update:delta];
[networkData update:delta];
Search Nedrilad ::




Custom Search