© Copyright JASSS

  JASSS logo ----

Joaquim Carvalho (2000)

Using AgentSheets to teach simulation to undergraduate students

Journal of Artificial Societies and Social Simulation vol. 3, no. 3,

To cite articles published in the Journal of Artificial Societies and Social Simulation, please reference the above information and include paragraph numbers if necessary

Received: 17-Jun-00      Published: 30-Jun-00

* Abstract

The AgentSheets simulation software has been used for the last two years in a course for undergraduate students. The ease of use and extreme care put into the interface makes this tool a classroom success, allowing students to have hands-on experience of model construction without the overhead of learning complicated frameworks or programming languages. The limitations of the tool, in particular those that make difficult the construction of more complex models, are reviewed.

Simulation, Teaching, User interfaces to agent based models

For the last couple of years I have used AgentSheets in a methodological course for undergraduate History students (18-20 years old), at the University of Coimbra, Portugal. I have also used the program to demonstrate simulation concepts in conferences and to illustrate a paper on Adaptive Complex Systems and Historical Analysis by providing a hypothetical example of a social emergent phenomenon. My experience being mainly pedagogical, I will concentrate on aspects related to teaching, where this software really excels. However the AgentSheets cannot be underestimated as a tool for quickly producing agent based simulations to demonstrate theoretical points or reproduce empirical situations.

Figure 1
Figure 1. A simulation running. Agents represented by coloured squares move around trying to find the "grass" areas where they will feed and reproduce. The agents have a small genetic code that allows for adaptation of moving patterns and the emergence of co-operative behaviour among agents of different colours.

* Teaching context

Mine is a year long course that covers several methodological and theoretical aspects, beginning with generalities like information theory and ending in relation database models, with a basic course on computer programming in between. My aim is to give a broad view of several computer related theories, concepts and methodologies that can help historians with their scientific work. Each topic is dealt with in an unavoidably general fashion, but practical experience is provided whenever possible, to avoid a "magical" perception of computer based methodologies. Students take the course with basic levels of computer literacy that goes normally go as far as being able to code an HTML page, but they have no familiarity with programming languages.

Agent Sheets allowed me to introduce students to hands-on experience in one of the most abstract topics of the course: how the concepts of information, adaptation, complexity and emergence are changing the way we think about the evolution of human societies. Students not only see how regularity and complexity emerge from the interaction of simple entities, but actually build those entities and change them. In my tight plan the use of AgentSheets takes about 16 hours - a month's worth of classes, during which students build simple simulations and analyse and change a pre-built more complex model.

* General impressions

The software is a classroom success. We have 8 Macintoshes and 8 PCs in the lab. The authoring mode of AgentSheets only runs on the Mac but interactive simulations can be exported as Java Applets to the PCs. Two or three students share a computer.

In less than half an hour students have agents moving on the screen and have grasped the basic interface principles. There is usually, in those first sessions, a climate of excitement (and noise, I must confess) in the class as students see they creatures moving around, producing sounds or speaking phrases. Questions of the type "how do I make my agent do this or that?" multiply, proving that the tool is generating ideas and expanding possibilities in pupils' minds.

As anyone teaching with computer tools knows, some of the time you spend transmitting an important concept is spent in teaching how the tool that demonstrates the concept works, and not the concept itself. Lowering the "tool overhead" is essential to capture student's attention - and in that regard AS is a teacher's dream. Extreme care was put into the ease of use, visual and aural feedback and unbelievably simple and useful debugging tools.

* How AgentSheets works

Worksheets and Agents

Simulations take place in a two dimensional grid called a worksheet. The size of each cell on the worksheet , in pixels, is determined when a new simulation is created. Agents will "live" on that grid and each agent is the size of the grid's cells (you cannot have agents side by side in a cell, but you can have some agents on top of others). The maximum number of cells on the grid is limited by some maximum value that I could not exactly determine, but it allows some fairly large simulations that extend beyond a 15" screen limit). One uses bigger cell/agent sizes when detailed images of agents and backgrounds are necessary. Smaller sizes are useful when the agent image is simple but seeing many agents at the same time is important.

Agents are created in a window called "gallery". To create an Agent you must give it a name, draw some image that will represent the agent in the worksheet (a "depiction" in AS terminology), and create the instructions that will give the agent a "Behaviour". You will create agents not only for the main roles in the simulation but also for more or less passive environment elements like grass, water, roads, walls, etc... Some of those second order agents might have no behaviour themselves, but just sit there so other agents react to their presence. Once the agents are created in the gallery you place them in the worksheet as if you were using a drawing program with rubber stamp icons. An Agent can be placed in the worksheet while the simulation is running and can also be moved around with the mouse

Agents can have more than one depiction associated with them and the one that is used at a given moment is programmatically controlled. This featured can be used to animate the agents as the simulation runs or to show visually different internal states of the same agents. Some clever built-in image transformations, like flipping, and bending, are provided to create new depictions from existing ones, speeding the creation of colourful and visibly active agents. The current depiction of an agent can also be tested inside the agent program and induce differential behaviour. Finally there are provisions to map internal numerical attributes of agents to the colour of their depiction, which is extremely useful when showing levels of attributes.

Figure 2
Figure 2. Creating a behaviour: Triggers, conditions and actions combine into rules. A breeding rule is being constructed that tests for the energy level of an agent and creates a new one if more than 300 units are available.

Programming Agents: the general model

Creating the "Behaviour" of an agent is of course the central and most important part of the program. AS takes the visual programming paradigm to a great extent, abolishing completely any text based algorithm coding. Everything is accomplished by dragging language elements from toolboxes and dropping at appropriate places in the agent's behaviour window. Colours, dynamic outlines and a very clever use of friction and alert sounds make AS programming fun, fast and intellectually rewarding (agents normally do what you thought you told them to do because you use visual representation of actions). Of great relevance in a classroom is the fact that AS is almost completely immune to those exasperating typing and spelling errors that turn teaching of much simpler things like HTML into a slow and frustrating process. It is hard to do justice in words to a mechanism that is based in the idea of avoiding words as much as possible - you have to try it - , so I will move on to the more substantial aspects of the computing paradigm behind AS and try to clarify its capabilities and limitations.

AgentSheets uses a computation model with three main components: triggers, methods and rules. Triggers are events received by the agents and to which the agent must respond. The behaviour of an agent is a set of methods that handles the events. Methods are sets of rules, which in turn relate conditions or perceptions to actions. This is a simple model, easy to explain and clearly translated visually in AgentSheets.

Triggers and events

The events responsible for triggering the agent actions can be classified into three classes, internal, tool related and message related.

Internal events are generated by the simulation environment: a sort of "tick" event (the "When running" trigger) is received by each agent in succession as the simulation runs. It is by responding to this event that the agent executes its main tasks. The other internal trigger is called "When creating a new agent" and is received by the agent just after it is created - it is useful to set up the agent initial state.

Tool related triggers allow the user to interact with agents by clicking on them with one of the tools that are available on the left of the worksheet window. This is important for interactive simulations where users provide input by clicking on specific agents. By selecting different tools with combinations of modifier keys it is possible to create agents that react to many different user actions.

Finally there is a generic message-type trigger that fires when an agent receives an arbitrary message. Messages can be sent from an agent to another neighbouring agent, can be broadcast to all agents of a given type or can be send internally within an agent, in which case they correspond to an internal method call. The term "message" might be misleading here. It is more an event notification than a message because you cannot send information along with a message between agents - this is a limitation that causes considerable difficulties, as we will see later.

Methods and rules

To respond to any of the available triggers an Agent must have corresponding methods. Methods are ordered sets of rules tied to a trigger. In a typical agent you will always find a "When running" method that is executed once for each simulation cycle. But it is unlikely to achieve a non-trivial behaviour with a single method. The main "When running" method normally fires message events that trigger other methods in the same agent. Due to the lack of control flow mechanisms in AgentSheets much of the behavioural logic must be represented by this mechanism (I will come back to this in the section on limitations).

Methods are represented as a tray containing smaller trays: the rules. The construction of rules involves dragging conditions and actions from the tools windows to the appropriate half of the rule "tray" and them setting the parameters as needed.

One fundamental aspect of the AgentSheets paradigm is that a single rule is executed at each method evocation. The software will test the condition part of each rule in a method, starting at the first. Whenever a rule has its conditions satisfied the "actions" part of the rule is executed and no further processing is done on that method in the current processing cycle. If several rules have their conditions satisfied only the first one found is executed.

This means, in other words, that methods are like IF THEN ELSE IF constructs where rules are IF THEN statements connected by ELSE clauses. The alternative would be to consider the rules as independent IF THEN statements so that all the rules that had their conditions satisfied would be executed in a single cycle.

* Expressiveness of rules

Since I use AgentSheets to teach emergence phenomena I am more than glad that the toolkit to build rules enforces strongly the concept of bounded agent. The primitives for conditions correspond to local perceptions. You can use "See" and "Next to" to react to the agent's immediate neighbours (the eight Moore cells). There is no "long distance" vision and it is impossible to examine the contents of a cell that is not adjacent to the agent. Internal attributes can be examined and changed, like conventional variables, allowing agents to keep a rich and changing internal state- the basis for complex behaviour construction. It is also possible to examine, but not change, the attributes of neighbouring agents.

Movement is possible only in adjacent cells. There is no "jumping" to an arbitrary point on the worksheet. Agents can erase neighbouring agents and themselves. They can also create new agents in the adjacent cells.

So most of the perceptions and actions are local and affect the agent and its Moore neighbourhood. I consider this a good design choice because it forces you to think locally when modelling global phenomena. The only provisions for system wide facilities are the "Broadcast" action that can trigger a method in all agents of a given type and the existence of global attributes that all agents can examine and set.

There are quite a few user interface related actions that you can use in rules. Agents can change depiction or colour, make sounds, speak phrases through the Macintosh built-in speech sintethiser, and even play music through the MIDI interface (there is an extraordinary demo of sound landscapes in the AS distribution). All this contributes greatly to the fascination and efficacy of the program in a teaching situation.

There are also ways to make rules that execute with a given probability or periodically, given a certain time interval.

Additional conditions and actions can be added to the program through an extensions mechanism. Unfortunately to write extensions you must use AgentSheets' native language, which is LISP, and understand well the internal framework of the program.

I found the capabilities of AgentSheets, as a computing paradigm, adequate in most situations. A typical test is to try to reproduce in AgentSheets a simulation that is proposed in some textbook. The AS CD-ROM has plenty of examples. Recently it took couple of hours to reproduce the sand pile model as presented in Per Bak, How Nature Works. The Science of Self-Organised Criticality (Oxford University Press, 1997), including, animation and a link to Excel so that the power law could be visualised in a graph. I have some examples at http://www.uc.pt/ihti/joaquim/agentsheets.html.

* Limitations

Most potential users will ask themselves the question: "looks nice, but how far can you go?" Like all applications designed for ease of use, AS pays a price in lack of sophistication. Mostly I found the price quite fair. There are however some aspects of AS that you come up against frequently, and these constitute my "wish list".

The first one relates to the way rules are evaluated in methods. The fact that a single rule is executed in a method at each execution cycle, and not all the rules whose conditions are satisfied, is counter intuitive in many occasions. Most of my students' difficulties in modelling behaviours have to do with this. The typical case is when I ask the class to make an agent that moves randomly in the main four directions (North, South, East and West). Invariably they produce a "moving" method with four rules, each with a 25% probability of being executed. This is wrong because rules have an implicit ELSE between them. So rules 2, 3 and 4 only get a chance to be executed if the first one fails. The overall probability of rules 2, 3 and 4 being executed is therefore 75%. To give rule 2 the same probability of rule 1, one has to give it a probability of 33.3%. So the right answer is to have the following probabilities: 25%, 33.3%, 50% and 100%. Takes a little to figure out, don't you think? This is only a symptom of a recurring problem that has many implications. Working around it makes methods complicated and sometimes deeply nested. Maybe there could be a "continue" or "next" action, that one could append to the end of a rule, that would force the evaluation of the next rule on the method.

The other general problem has to do with lack of facilities to produce graphs that show how certain global variables change as the simulation is being run. It is possible to see the numerical value of global variables changing in a small window, but in most cases the numbers change too fast to be understood. This is a problem because many simulations deal precisely with the evolution of global systemic quantities as a result of the aggregation of many small actions. The only solution is to export, with an extension, the data to a spreadsheet and graph it there after the simulation is run. Since this is a Macintosh only application the ideal solution would be to make it AppleScript friendly. AppleScript is Apple's technology for inter-application communication and allows a program to exchange data and services with other programs. AgentSheets to Excel links could be easily done like this, in a live fashion, and thus integrate tools that students are already familiar with. I understand that integration with other applications is being pursued at the Java level, but currently there seems to be no documentation on how to do it. In a related note, it would be nice to do screen dumps programmatically since they play an essential role in documenting simulations and sometimes we need regular "photographs" to be taken unattended during long runs.

My last remarks have to do with more specialised situations where I felt that the lack of a few simple mechanisms was either preventing interesting models to be build or making them unnecessarily complex.

No information changing in messages is a major problem. An agent cannot send some information to another agent, for instance a quantity, or the value of an internal attribute. It can send a message but with no dynamic value attached (it is like calling a procedure with no arguments). Tied with the impossibility of an agent to change an attribute of another agent an asymmetry is created: agents can examine information on other agents but cannot send to, nor change information on, other agents. This complicates simulations where communication between agents is essential. This same problem makes genetic type programming in AS unnecessarily complicated, since there is no simple way for the parent to pass its genetic information to their offspring (while it is easy for an agent to create a new agent). It is possible, but complicated. My workaround involves sending a message and making the target agent to "look back" to the sender and extract information by examining its attributes - it works but generates complicated methods for simple information changing. The introduction of global properties in the last version of AS may allow for different workaround techniques but they are still clumsy substitutes for lack of proper messaging.

Another problem that I often encounter is handling the way agents pile up in worksheets. It is perfectly possible to have several agents on top of one another in the same cell but if I understand correctly only the topmost agent is used for perceptions, message sending and attribute inspection by other agents. A "see" condition in an agent only sees the top-most agent, which may be logical in some situations but not in others. The same applies to attribute examination. It took me some time to understand that if I had a background of agents propagating a value by diffusion (for instance, "earth" agents diffusing humidity from water sources) and moving agents on top of them (for instance, "cows"), the value to be diffused was always taken from the topmost agent, where it was sometimes absent, and not from the agent were it was located (in other words, "earth" agents were trying to take the humidity value of the cows and found nothing, instead of taking the value from the earth agent underneath the cow). If you have a simulation with diffusion at the ground level and a lot of moving agents above, you have to make the moving agents diffuse the same values as the ground agents for the model to work, but the solution is never perfect. Maybe the actions and conditions affected by this could be qualified in some way (agent type, for instance) or the software could be clever enough to pick attributes where they are present.

Finally I found that lack of a way to identify agents within the same type prevented behaviour where interactions between specific individuals, or a "memory" of individual relations was necessary. If an agent could inspect and store internally the id of another agent and later send a message specific for that agent, many complex things could be done that are very difficult now.

* Conclusions

I realise that my complaints list seems a bit extended but it does not contradict my previous statements of appreciation. On the contrary, as one gets addicted to AS, its simplicity and the time it saves, one also gets very frustrated at the idea of having to do "normal" programming because of what could be considered "small" design oversight. Obviously it is easy to propose changes to choices that can be the result of well-researched trade-offs between ease of use and flexibility. AgentSheets is an invaluable teaching tool for introducing students to agent-based simulations, even at the most elementary school level (my two sons, 7 and 12 years old are great AS fans). It also provided me on several occasions with invaluable support for prototyping ideas or reproducing simulations made by others. It may lack the facilities to generate complex and self-documenting experiments. But before wishing that AS was more like a traditional simulation package I would a hundred times rather wish that traditional simulation packages were more like AS.


ButtonReturn to Contents of this issue

© Copyright Journal of Artificial Societies and Social Simulation, 1998