Let’s summarize the chapter to this point with some examples that show how the various ideas can be implemented using NETLOGO. Both the teacher and the student are encouraged to work through the tutorial in addition to this short introduction, as this section provides only a cursory overview, but will offer clearer descriptions of some of the more technical and implementation-centric terms used. The main ideas for this chapter are directly taken from Tutorial #3: Procedures, which is freely available with the NETLOGO software for download.
NETLOGO uses patches and turtles. Patches and turtles both have variables that store information about their current state, but while patches remain at a fixed position in the grid, turtles can move around. You can best imagine the patches to be the cells of a chessboard, where each cell can have a set of attributes describing it in detail. The turtles are the figures that move around on the chessboard, also being described by a set of attributes. Conceptually, the patches can be best interpreted as representing the situated environment, and the turtles build the agent population, although technically each patch is an agent itself as well. In addition, NETLOGO defines links connecting two turtles, supporting the idea of communication. The last agent type in NETLOGO is the observer. That is the overall master agent supporting all activities that turtles, patches, and links cannot do by themselves.
NETLOGO allows users to define the variables and procedures for patches, turtles, links, and the observer. A variable captures the value of a characteristic attribute. A procedure summarizes several commands for an agent into one command line. To activate a procedure, the NETLOGO command "ask" is used. The use of "ask" implies that this is not a simple procedure command, but that each agent decides if and how he answers what he is asked to do. One of the easiest NETLOGO commands used with "ask" is "set." This command is used to set the variable of the addressed agent to the defined value. The following command sets all patch colors to the value green:
We can also ask a single specified agent, for example, to switch the color of the patch at the position (2, 4) to red:
Let’s use the example of grass, sheep, and wolves to look into the implementation possibilities of our conceptual ideas captured in this chapter.7 The complete NETLOGO program is printed in the appendix to this chapter. The idea is the following: Sheep eat grass. If they eat enough grass, they can multiply. If they do not eat enough grass, they die. Wolves eat sheep. If they eat enough sheep, they can multiply. If they do not eat enough sheep, they die. Once the grass is eaten, it grows back, but that takes some time.
The grassland in which sheep and wolves live is represented in NETLOGO by patches that are either green (grass that can be eaten) or brown (grass that has been eaten and is currently growing back). As the grass grows back slowly, an attribute is needed that captures how far the grass has grown back already. Each time step, the grass grows back a little bit more until the patch is green again.
The example that comes in NETLOGO is pretty basic: Sheep and wolves need energy every time step. If the energy level falls down to zero, they die. If they eat, their energy level rises by a pre-defined amount. Here are some code segments that show these steps.
Both species can reproduce with a given likelihood as long as they still have energy. If they reproduce, they breed a new instance of their species and share their energy with the new breed.
Wolves reproduce the same way. If a random number is below the likelihood of reproduction (which is a user-defined parameter), a new turtle hatches and moves to one of the neighbored cells, taking half of the energy of the parent.
The general actions per time steps in the NETLOGO example are to move one step into a random direction, decreasing the energy. Sheep eat the grass in the target cell, if available, which raises their energy level by the user-defined value. The countdown attribute of the grass patch is set back to the maximum grow-back time, which is user defined. Wolves eat sheep in the target cell, if available, which raises their energy level by the user-defined value. Both species reproduce as described above. At last, the patch countdown-values are decreased and patches with countdown values reaching zero are set back to green. The following screenshot (Figure below) shows the example with all user-defined parameters.
Wolves, Sheep, and Grass.
So far, we have agents (wolves and sheep) that interact with each other and their situated environment, but several of our discussed components are still missing. Our agents are pretty deaf, dumb, and blind. The first improvement is to add perception. Wolves and sheep should be able to see what is in the neighboring cells. Based on this, the decision where to go can be made:
- If a wolf sees a sheep in the neighbored cell, he moves into it to hunt the sheep.
- If a sheep sees grass in the neighbored cell, it moves into it to eat it.
- If a sheep sees a wolf, it may move away from him.
NETLOGO provides several functions that help to improve establishing a more realistic perception for our agents, such as measuring the distance. This allows defining a maximal radius that a wolf or a sheep can see. By adding more features to the patches, such as coverage by trees and bushes or elevation, allows for the creation of valleys, wooded terrain, and other features that support more realistic perception.
Next, we want to deal with memory and experience. One possibility is to implement a parameter that sheep that have witnessed how another sheep was hunted down in their neighborhood are more afraid of wolves and react faster when they see a predator approaching. Also, they may remember certain features of the environment, such as narrow valleys, which do not allow for a rapid escape. Another option is to add experience counters for wolves and sheep. Every successful hunt makes a wolf a little bit better; every observed encounter makes a sheep more careful and cautious. If a hunt is modeled as a random event, similar to reproduction, the likelihood of a successful hunt is increased with the experience of the hunter and decreased with the experience of the sheep. The experience level can also decrease with time, modeling that short-term memories influence hunter as well as victim more strongly than long-term memories. The experience level can also influence the detection probability: an experienced sheep will detect more wolves, and experienced wolves can hide better when approaching their victims (although I have to admit that this may be more realistic for antelopes and lions).
Once the initial set-up is completed, communication and the social aspects of the community of agents need to be integrated. Sheep only die without a sound in movies like The Silence of the Lambs. When they are hunted down in the wilderness, they communicate their fear, and alarm others. If one sheep gets killed, the others will run away from the scene.
On the other hand, wolves hunt in packs, and they communicate well to orchestrate their moves. Nothing speaks against modeling such pack behaviors and communications between wolves.
Many other improvements are possible. A sheep that needs to eat or otherwise die may behave more riskily. Running may burn more energy than normal moving. Complex hunting behaviors with one part of the pack waiting at the end of narrow terrain for sheep that are driven towards them by the second part of the pack can be modeled, and so forth.
By now, you should have a good idea how to model the main concepts of perception, sense making, communication, decision-making, action, and adaptation. This example as well as many of those freely available through NETLOGO will help to broaden your understanding. As with all disciplines, practice makes perfect. Experiment with some of the models before attempting to write your own.
7 Uri Wilensky and Kenneth Reisman: "Thinking like a Wolf, a Sheep or a Firefly: Learning Biology through Constructing and Testing Computational Theories – an Embodied Modeling Approach," Cognition & Instruction 24(2):171-209, 2006