The buildActions method is intended to be the place in which one creates Swarm schedules, but that does not make the simulation carry out the scheduled actions. In order to put the object's schedule into the "grander scheme of things" in Swarm, it is necessary to activate it. Through the activation mechanism, the Swarm library integrates the many diverse actions of the different objects that exist in the simulation. It is done through a hierarchical series of activateIn methods. The main.m tells the top level swarm to activate itself (after it has been told to create its objects and schedules, of course). Then the top level swarm activates any schedules it might have created and (here's where the hierarchy comes into play) it tells the next lower level to activate itself. That next level activates its schedules and tells the level below to activate itself. This is how the activities of many different levels are synchronized.
Virtually any Swarm program will offer a sufficient example of the progression of activateIn methods from top to bottom. The main.m in Heatbugs has this:
[theTopLevelSwarm activateIn: nil]; |
The top level swarm is told to activate itself in nil, which is a way of telling the top level that it is in fact at the top of the hierarchy. It is not told to activate itself within the zone of any other swarm, in other words. When the time comes, the lower levels are told to activate themselves in the zone of the swarm that is one step above it (as we shall see).
Assuming we are doing a graphical model, the activateIn: method of the top level is found in HeatbugObserverSwarm.m. In the HeatbugObserverSwarm.m's activateIn: method, we find commands that both activate schedules within the observer swarm and also activate schedules in the next lower level of the simulation:
- activateIn: swarmContext
{
[super activateIn: swarmContext];
[heatbugModelSwarm activateIn: self];
[displaySchedule activateIn: self];
return [self getActivity];
}
|
It is important to recognize that the activateIn methods of each class within the hierarchy fulfill a vital role in synchronizing the schedules of the levels. These are typically written so that, first, the activateIn method of the superclass is executed. Then the schedules of the current class are told to activate themselves in the current context, and then the activateIn method of the next lower level Swarm is told to activate itself.
The activateIn: method returns an object of class Activity, which is a sufficiently important concept that it is treated on its own in the next section.