The core of the Swarm system is the set of features that enhance the design process of simulation projects. The scheduling apparatus is one of the truly important elements of the Swarm system because it offers a way to integrate the actions (and responses) many different agents in many different levels of a simulation.
The actions that go on in a simulation are orchestrated by a objects that respond to the Schedule protocol. Schedules are generally built in the buildActions method of an object. A Schedule is something like a calendar in which one might put a red letter X when an important event is supposed to occur. The user then defines what the important events are and integrates them into the Schedule. Then the Schedule must be activated within the larger Swarm hierarchy of the object.
Here is an example of some code that makes a simple Schedule. This sort of Schedule might appear in the ModelSwarm level of the bug tutorial, for example.
- buildActions
{
modelSchedule=[Schedule createBegin: self];
[modelSchedule setRepeatInterval: 1];
modelSchedule = [modelSchedule createEnd];
[modelSchedule at: 0 createActionTo: aBug message: M(step)];
return self;
} |
The first three lines in the method create the Schedule named modelSchedule. It might as well be aBugsLife or any other name the user chooses. Between the createBegin and createEnd methods, the only detail that this Schedule sets is the repeat interval, which is one. That means that all of the actions assigned to the modelSchedule will be executed at each time step.
Once the code has created a Schedule object and set the repeat interval, then that object can be told to insert actions into its Schedule. These actions cause the modelSchedule to build commands that make the desired actions happen. No two simultions are exactly the same, of course, and so there are no hard-and-fast rules. Generally, however, the modelSchedule is usually told to do either of two methods, at:createActionTo:message or at:createActionForEach:message. The first is used when the action of a single object must be Scheduled, while the second is used to Schedule activities for whole lists.
In this simple example, the modelSchedule has only a single action, which instructs the one bug in the simulation, whose name is aBug, to carry out its method called step. It might be that there is a whole list of bugs, bugList, and each bug has to be instructed to carry out its step action. In such a case, the command would be:
[modelSchedule at: 0 createActionForEach: bugList message: M(step)];
|
Some additional scheduling topics are discussed, but first the abstract question of selectors and the M operator must be addressed.