This is a manual for advanced users of the BehaviourComposer. To learn how to browse, customise, and enhance micro-behaviours and to compose them into models see the on-line tutorials and videos.
To
facilitate the composition of micro-behaviours new commands and
reporters have been added
NetLogo. These are described in the dictionary of NetLogo extensions. The Behaviour Composer processes code that uses these new commands into
ordinary NetLogo code for NetLogo execution. All the NetLogo commands
and reporters are available for use in micro-behaviours. New commands
and reporters can be added as well using NetLogo's to and to-report.
Behaviour Composer Scheduling Extensions to NetLogoEach agent in the model has a schedule that is defined by the following commands:
*
do-at-setup [
actions
] performs actions when the simulation is initialised (actions can be
any NetLogo commands)
In addition to the scheduler actions can be triggered when some condition becomes true by the following commands:
*
when
[condition]
[actions] performs
actions one time as soon as condition holds
These commands are added as needed when you click on one of the Enhancement menu items on the micro-behaviour page. NetLogo commands to support probabilistic and repeated executions
*
do-with-probability
odds [
actions
] performs actions with probability odds
The following command is useful when you want a subset of agents to perform some action. Selects n of the agents and runs actions for each agent. If n is a non-integer the remainder is used as the odds of selecting an additional agent. If there are fewer than n agents then all agents run the actions. While the actions are run the code can refer to the agent that is running do-for-n using the-other. select-n is a reporter that returns the number of agents and also treats fractions probabilistically. A typical example is from RANDOM_ENCOUNTER :
It selects the-encounter-rate of those not dead and adds the POSSIBLE-INFECTION micro-behaviour. In some cases it is possible to observe an animation of the execution of a model or the graphing of some aspects of the state of the model with a constant ratio between real elapsed time and simulation time. The units for the scheduler are optionally interpreted as seconds, and if the simulation is running faster than real time, the system slows down in order to reproduce a smooth and temporally accurate playback. If the simulation is run "un-clocked" it proceeds as normal, but there will not be a constant ratio between simulation time and real-time due to varying or excessive computational demands. Prototypes - how many instances and hide this agentThe interface to prototypes enables one to specify the initial number of instances of the prototype and whether it should be visible or not.
The area that specifies the number of instances that should be created at set up time. It can be any NetLogo expression that computes a non-negative integer value. For example, it can be a global parameter, perhaps controlled by a slider. More agents can be created later using the create agents micro-behaviour. Also copies of instances can be created using create exact copies of this agent. A value of zero is recommended for prototypes whose instances are only created dynamically during execution or those whose initialisation needs to be delayed because they depend upon completion of other set up initialisations. In the later case some other prototype needs to use create agents to complete the set up.
Another use of prototypes with zero copies is to use it as a list of micro-behaviours. Prototypes can be added to lists of micro-behaviours to add their micro-behaviours. This differs from using a micro-behaviour to collect micro-behaviours as a unit in that many can share the list without copying the micro-behaviours (and thereby necessitating multiple edits when any of the micro-behaviours needs revision.)
The Hide this agent check box is equivalent to adding the become invisible and continue to run behaviours micro-behaviour to the prototype. This supports the common situation where an agent needs to run in the background (to create new agents, maintain observation gadgets and plots, and the like) but is not an agent one wants to see in the world view of the simulation.
NetLogo Extensions for Adding Micro-BehavioursThese commands are for adding micro-behaviours to prototypes. A micro-behaviour is referenced by linking to a web page containing the micro-behaviour itself. This can be either hard-coded as a URL or editable using the list-of-micro-behaviours token .
*
add-behaviour
micro-behaviour adds
the micro-behaviour to the current prototype (the prototype running the
micro-behaviour that is executing the add-behaviour command). Another
name for this command is add-behaviour-to-me.
Micro-behaviours can also be added to NetLogo links between agents. Referring to another agentIn addition to the full richness of the ways in which NetLogo supports ways to refer to other agents there are the following extensions:
*
can-pick-one
agents if
agents is not empty reports true and
the-other will
return the agent chosen
the-other can be used in NetLogo code in the Behaviour Composer to refer to an agent defined by the most recent execution of one of the above extensions. An example of its use is in EAT-WHEN-HUNGRY . A simplified version is
When there is at least one individual whose distance to the agent running this code fragment is less than 5 units then the behaviour DIE is added to the the-other, can-pick-one sets the-other when it randomly choses one of the agents from all-individuals with [distance-to-me < 5]. Miscellaneous additions to NetLogo
Naming and Using Attributes in the Behaviour ComposerNetLogo, like many programming languages, expects agent attributes ("breed variables" in NetLogo parlance) to be declared before use. The BehaviourComposer automates this so that any attribute whose name begins with "my-" becomes a breed variable without the need for a declaration. When an attribute needs to be both read and updated then the current and next value can be kept separate by using the "my-next-" form. After all actions scheduled for time t have completed, all attributes whose name begins with "my-" are set to the current value of the "my-next-" version of the attribute. Predicates in conditionals can refer to the current state of an attribute by using the "my-" version of a variable, while code that updates a variable can use the "my-next-" version. In this way, execution order dependencies are eliminated. For example, agents with the following simultaneous update micro-behaviour will at time t+1 move to the left if that location was unoccupied at time t.
In contrast, agents with the immediate update version of this micro-behaviour will at time t+1 move to the left if that location was unoccupied at time t by agents yet to run and unoccupied at time t+1 by those agents that have already run. It differs from the simultaneous update version in that the last line is:
If each agent in a line ran the simultaneous update micro-behaviour only the leftmost agent would move at time 0, then the two leftmost agents at time 1, and so on. If they ran the immediate update micro-behaviour then the same sequence of events may happen, or they may all move left: many other possible outcomes can result from different execution orders. Immediate updates are simplest to implement and are the most common in modelling. We believe their idiosyncratic semantics (a mixture of time states) makes them less desirable, in general, than the simple semantics of simultaneous updates. The choice between the two kinds of update can be made by the micro-behaviour programmers on a case-by-case basis. Patch variables should be given names that end with "-of-patch", e.g. temperature-of-patch . The Behaviour Composer also expects global variables (such as those defined by sliders) to begin with "the-" to provide high-level error messages if they are not defined. MovementThe BehaviourComposer supports three movement attributes: my-x , my-y , and my-heading . If the corresponding NetLogo variables xcor , ycor , and heading are not updated (which many NetLogo primitives do such as forward , face , right , ...) then they are set to the values of the attributes. Note that as with all attributes, one can use my-next-x , my-next-y , and my-next-heading to distinguish between the value the attribute should have when the current cycle ends and the value it currently has.
go-forward
is similar to NetLogo's
forward
except it relies upon
my-x
,
my-y
, and
my-heading
.
turn-right
and
turn-left
are like NetLogo's
right
and
leftbut
they affect my-heading. The advantage of using go-forward
and turn-right is that they work together with any other code that
deals with
my-x
,
my-y
, and
my-heading
such that they don't depend upon the order of events.
Three-dimensional modelsIf a model includes the micro-behaviour Set the initial dimensions of the 3D world where the model runs then the Behaviour Composer generates a 'nlogo3d' file that can be run by the 3D version of NetLogo. Note that there is no applet support for 3D so the models cannot be run in the browser. Any of the 3D NetLogo primitives may be used as well as my-z and my-next-z.
To define a micro-behaviour from scratch click on the 'Create a new micro-behaviour' button in the Composer area. It will provide four areas where you can add information:
After saving you can make further edits by clicking on the 'Edit page' button. Note that some changes to text areas or lists of behaviours may break micro-behaviours that are depending upon this page. Also note that you are editing a page that different micro-behaviours may be relying upon.
If you want to host the micro-behaviour on another site, open the micro-behaviour as a tab and click on the 'Get links' to obtain the HTML of the page.
Adding an externally hosted micro-behaviour to the Behaviour Composer
|
Guides >