Participatory Modeling and Simulation with the GAMA platform

: In recent years, agent-based simulation has become an important tool to study complex systems. However, the models produced are rarely used for decision-making support because stakeholders are often not involved in the modeling and simulation processes. Indeed, while several tools dedicated to participatory modeling and simulation exist, these are limited to the design of simple KISS models, thus reducing their po-tential impact. In this article, we present the new participatory tools integrated within the GAMA modeling and simulation platform. These tools, which take advantage of the GAMA platform with respect to the definition of rich KIDS models, allow the modelers to build models graphically and develop distributed serious games easily. Several application examples illustrate their use and potential.


Introduction
. Nowadays, agent-based modeling has not only become increasingly significant for the study of complex systems, but has also opened up promising perspectives for the inclusion of rich and complex models in the socioenvironmental decision-making processes (design of public policies, investment planning, community adaptation to climate change, etc.). This is especially true in the case of researchers from fields other than computer science (geography, environmental sciences, social sciences, health, etc.). The adoption of such models, which was partly fueled by the emergence of modeling platforms that ease the work of the modelers, like NetLogo (Tisue & Wilensky ), GAMA (Taillandier et al. . Finally, the MAGeo platform (Langlois et al. ) allows us to merely define a model through a dedicated graphic interface. It proposes to formalize agent behavior as an aggregation of basic behaviors with a simple grammar. This grammar is perfectly adapted to the definition of KISS models, but does not allow development of KIDS models. In addition, the number of inbuilt operators is very low in comparison to the ones proposed by the GAMA platform.
. To sum up, there is still a lack of tools, which could be used by a large audience and which would enable graphical definition of KIDS models at the same time.

Graphical modeling language .
An important issue for developing graphical modeling tools is the choice of a graphical language. The most used for modeling purposes is UML. In the context of agent-based modeling, some works have shown the significance of using such graphical language for communication (Bersini ). However, some authors have pointed out that the use of UML as an agent-oriented modeling language is inappropriate (Beydoun et al. ). .
Other graphical languages based on UML and dedicated to multi-agent systems have been proposed: the most famous ones are AUML (Bauer et al. ) and AML (Cervenka et al. ). These languages make it possible to introduce some specific features linked to the agent paradigm. However, their scope goes beyond agentbased simulation and covers all multi-agent aspects, which can make these languages di icult to apprehend for non-computer scientists and not adapted to the context of modeling complex systems. .
The last modeling language that needs to be mentioned is the one proposed by the MAGeo platform. This language is based on the AOC (Actor -Organization -Behavior) meta-model (Daudé et al. ). This graphical language is close to UML and respects most of the properties of OOP (Object Oriented Programming). In addition, it allows one to natively define multi-level models. However, this language imposes a lot of constraints due to the limitations of the MAGeo platform. In addition, no distinction is made between what an agent can do and what it is going to do (capabilities versus behaviors).

.
Our goal for the GAMA platform was thus to propose a modeling language, which is simple enough to manipulate (with a small number of concepts), which allows one to develop KIDS models, and which is as close as possible to implementation in order to avoid a gap between the conceptual model and the implemented one.
In order to achieve this objective, we identified several properties that our modeling language had to respect: • Properties of OOP

• Di erentiation between capabilities and behaviors
• Native handling of multi-level modeling • Possibility of defining elements related to simulation visualization Graphical modeling with GAMA Overview .
The purpose of our graphical modeling tool is to address the need for participatory tools that would help define KIDS models. It allows GAMA users to graphically define their models and eventually translate them into the GAML language. In addition, this tool enables translation of a GAML model into a graphical one. This feature aims at facilitating the discussion (and communication) pertaining to a model. The tool is based on the Graphiti plugin of Eclipse (Graphiti ) and is integrated in a dedicated GAMA plug-in that can be directly downloaded and installed through GAMA. .
The modeling process with this tool consists first in defining a conceptual model represented by an entityrelationship diagram, then filling in all the defined entities through dialog boxes.
Definition of the conceptual model .
We chose to base the definition of the conceptual model on the GAMA meta-model. Although many agentoriented meta-models were proposed in the literature (see (Beydoun et al. ) for a presentation of the most famous ones), most of them are not directly used for simulation purposes and are very di icult for noncomputer scientists to grasp. Another advantage of using the GAMA meta-model is that it allows us to limit the gap between the conceptual model and the implemented model.
. their variables, actions, reflexes and aspects. An Action is a capability that the agents of the population have, i.e. something that the agents can do. A Reflex is a behavior, i.e., something that the agents of the population are going to do (if some conditions are respected). An Aspect represents a possible display of the agents. Note that a species can specify several actions, reflexes and aspects. In addition, a species specifies the spatial topology and scheduling of the agent population. A containment relationship between species helps to describe the hierarchical levels of an agency. Finally, a specialization relationship between species helps to define links of inheritance between them.
. An ExperimentSpecies represents a context of execution of a model. It is a particular species of agents that contains a set of species (the one defined in the model) and a set of displays. .
More details about the GAMA meta-model can be found in (Vo et al. ). The use of this meta-model makes it possible to respect the four properties defined in Section .

.
Figure presents the modeling graphical framework of the tool. The right palette allows the modelers to select the type of elements to add to the diagram. This framework proposes all the classic features of graphical editors (undo, drag and drop, etc).
. Table presents all the elements that can be added to the conceptual diagram.
. When a graphical model is created, a first species of agents is automatically created: the world species. The world species corresponds to the first level of agency that describes the global spatial topology of the model, its basic scheduling, its parameters and global behaviors. It is the host for the populations of agents described by the species defined by the modeler.
. Thus, development of the conceptual model consists in defining all the species (with their chosen topology: continuous, grid) living in the world, their capabilities (actions), their behaviors (reflexes, tasks, states or BDI elements) and possible displays (aspects). Note that the inheritance relation can be used between species. In addition, definition of the conceptual model consists in determining the possible contexts of execution of the simulation (experiments) and the corresponding outputs (displays) for each of these. Every time the diagram is modified by the user, it is validated: if there is no error in the diagram, its components appear with green borders, and buttons corresponding to each defined experiment appear in the top of the editor (for example, see the my_GUI_xp button in Figure ). By clicking on one of the experiment buttons, the user can load it (and run the corresponding simulation(s)). When there are errors in the diagram, the problematic components appear with red borders. .
As an example, Figure presents the conceptual model of a simple predator-prey model. In this model, four species of agents live in the world: • vegetation_cell: species with a grid topology that will be used as a spatial environment for the other agents. This species has only one behavior (reflex): grows.
• animal: species with a continuous topology that will be used as the generic species to define the predators and preys. This species has behaviors (reflex): eats, moves, reproduces and dies. It also has one action called eating and one aspect called circle.
• prey: species with a continuous topology that inherits from the animal species. This species overrides the eating action.

Source Description
A species Species: A species of agents with a continuous topology.

A species
Grid: A species of agents with a grid topology -World: the first level of agency. It contains all other species of agents.

A species
Action: A capability that the agents have.

A species
Reflex: A behavior (sequence of statements) that will be activated at each simulation step (according to a given condition).

A species Equation:
a di erential equations system that can be used to describe the evolution of some of the agent attributes A species Aspect: A possible display for the agents.
The world GUI Experiment: load only one simulation with the graphical user interface The world Batch Experiment: load a set of simulations without the graphical user interface A GUI Experiment Display: frame allowing to display outputs (map, charts...) A species with a BDI architecture Plan: sequence of statements that will be executed in order to fulfill a particular intention. More details about the GAMA BDI architecture and the plan statement can be found in several works (Taillandier et   • predator: species with a continuous topology that inherits from the animal species. This species overrides the eating action. .
In addition, we define one GUI experiment called main_xp that has a display called map and a display called charts.

Definition of the parameters and processes
. Once the conceptual model is defined, the next step consists in describing the properties of each defined entity.
. When the user clicks on an entity, a new dialog box allowing parameterization appears. It is through these dialog boxes that the modeler will be able to transform his/her conceptual model into a simulation. Sometimes, the parameterization will just consist in making a choice between di erent options, but sometimes it will consist in writing GAML instructions. .
The most important entity to parameterize is the species. The species dialog box helps to define some of the properties of the species with a minimal amount of code (see Figure ). In particular, it allows the modeler to define the variables (attributes) of the species. For each variable, the modeler has to define its name and its type (among many types such as integer, float number, string, list, matrix, map, point, geometry, graph, path...). In addition, the modeler can define optional facets for each variable such as its initial value, a minimum, a maximum, an expression that will be used to re-compute the variable at each simulation step or a function that defines how the variable will be computed each time it is requested. The modeler can also give skills to the species. A skill is a predefined set of variables and actions coded in Java. For instance, the moving skill provides the species with the variables speed, heading and destination and the actions move,goto,wander and follow. The modeler can also choose the architecture of the species. By default, all agents in GAMA have a reflex control architecture (behaviors activated according to a certain condition), but it is possible to add another architecture to the agent: a BDI architecture, a state-machine architecture or a task-based architecture. The modelers can also define the scheduler of the species and its frequency of activation. Lastly, the modeler can define an init block that represents the constructor of the species, i.e. it defines what will happen when agents of this species are created.
. The dialog boxes for the world species and the grid definition are very similar. For the grids, the dialog box only allows the user to additionally define the number of cells in the rows and in the columns, and the type of neighborhood: Moore, van Neumann or Hexagonal. For the world species, the dialog box allows the modeler to additionally determine whether the environment is torus or not. .
Concerning the parameterization of reflexes, the dialog box makes it possible to choose the condition of the reflex activation and its e ect. The activation condition and the e ect are described using the GAML language. The action dialog box is very similar to the reflex one except that no condition can be defined, but the modeler can add arguments and a return value. .
For the aspect definition, the dialog box enables the definition of the layers composing the aspect (and their order). These layers are defined through a dialog box, in which the modeler can choose the shape to display (a simple shape such as a circle, a square, a rectangle..., an icon, a text or a complex geometry such as a polyline or a polygon), its color, and some specific properties (rotation, filled/empty shape...) or directly through the GAML language.
. The experiment definition dialog box makes it possible to define the parameters that the user will be able to modify through the simulation interface. .
Concerning the display definition, the dialog box allows the modeler to define the layers composing the display (and their order), to choose a color for the background and the refreshing rate. The layers are defined through a dialog box, in which the modeler can choose the elements to display (a list of agents, a chart, an image, a text...), the level of transparency of the layer, its size and its position.
. Finally, concerning the equation, state, task and BDI-related elements, the modelers will have the possibility of filling some specific fields (facets of these statements) and describing their e ects in GAML code.

Conclusion .
To sum up, the graphical modeling tool of GAMA enables graphical definition of a complete and functional GAMA model with a minimal quantity of GAML code.
. This tool o ers many advantages for a participatory modeling context. The choice made in this tool to use a graphical meta-model that covers the more important concepts of the GAML language, allows modelers to graphically define a whole model. As a consequence, there is no cognitive e ort to switch between the graphical modeling language and the implementation language. On the other hand, the model created graphically can be directly executed in GAMA: this upholds one of the main advantages of the modeling and simulation platforms, i.e. the possibility of executing the model being implemented very quickly and switching between the model and the simulation, thus contributing to the understanding of the model. In addition, the graphical modeling language enables a description of the core components of the model and also helps to determine how to simulate it: it allows the modeler to define the experiments, i.e. the parameters that can be modified during the experiment and the various displays or visualizations of the simulation. This last aspect is o en missing from participative modeling and simulation tools. .
The tool is already used in several projects and lectures, which makes the discussions around a model easier or allows for a collective construction of a new model from scratch.

Participatory simulation
Context . Nowadays, more and more modeling projects integrate participatory simulation, o en with the help of a serious game. Participatory simulations invite human participants to interact with a simulated environment. Such simulations can be used to convey messages e iciently (Klabbers ), to serve as communication media between participants or to engage the public in a decision-making process (Noyman et al. ). A classic example is Fish Banks (Meadows et al. ), which allows participants to play the role of a fishing company manager and to interact with a computer simulation of renewable fish stocks. .
The main di iculty in participative simulation is gaining the confidence of stakeholders. It implies: (i) the development of an empirical model showing realistic dynamics and (ii) reproduction, in the serious game, of the workspace that the stakeholders are used to (e.g., available policies, budget, governmental restriction, social events). The Graphical User Interface has thus to be designed according to the player role. .
To facilitate the design and implementation of such serious games, some generic agent-based platforms propose dedicated tools. .
One of the most commonly used platforms for serious games is NetLogo. This platform allows users to directly interact with di erent agents of a simulation through agent inspectors and the observer. In addition, it allows addition of some components (sliders, field area, button) to the interface allowing a user to interact with the simulation. Moreover, it allows creation of a dialog to ask the user to fill in a specific variable value. Finally, with its Hubnet extension (Blikstein et al. ), NetLogo allows several instances of the same models communicating with each other through a local network. This last feature is particularly interesting when implementing distributed serious games. However, NetLogo is more adapted to the development of simple KISS models rather than complex KIDS models. In addition, the presence of a unique display of the environment and the general simulation panel are important drawbacks for the implementation of serious games. .
. Another platform that proposes tools for participatory simulations is Cormas. This platform o ers many features to develop and manage such simulations (Becu et al. ). In particular, like NetLogo, Cormas allows participants to directly interact with the various agents (or group of agents) though the agent inspector. Using Cormas, one can also directly manipulate one or several agents (for instance, execute some of their actions) through a dedicated interface. Cormas can distribute the control of a simulation through a network on several computers (Becu et al. b). More precisely, it gives the control on the same simulation (running on a server) to di erent clients who can have di erent views on the same simulation and interact with it. In addition, unlike NetLogo, Cormas allows the modeler to define several displays. Finally, Cormas gives the possibility of going back in time: by just clicking on the backward button, the user can backtrack to the previous step or replay a simulation. While Cormas is particularly well-adapted for use in participatory contexts, developing models, which require using the Smalltlak language and the VisualWorks framework (Brauer ), can be complex for non-computer scientists. In addition, like NetLogo, the platform is not adapted to the development of complex KIDS models (no real integration of GIS data, simple representation of the environments, etc.).

.
To sum up, NetLogo and Cormas propose many tools that can be used in a participatory simulation context, but they are both limited with respect to the development of KIDS models, which explains why most participatory simulations are still based on simple KISS or KILT models.
. As a consequence of these limitations, several projects have chosen to use GAMA to develop ambitious interactive models.
. A first example is Sprite (Adam et al. ; Taillandier & Adam ), which allows the participant to play the role of the mayor and manage Oleron Island for a certain number of years, with the mission of finding an appropriate balance between popularity, economy, attractiveness, safety and ecology. Sprite proposes a precise representation of the island through GIS data and integrates an advanced submersion model. Integration of GIS data would have been very di icult to achieve with Cormas, whereas the multiples views of the territory o ered by the model would not have been possible with NetLogo.

.
Another example is Littosim (Becu et al. ), which also illustrates the management of the risk of submersion. In Littosim, participants play the role of the land-planning manager of a coastal municipality prone to marine submersion risk. It integrates several sub-models such as water rise and socio-economic evolution models. One of the features of Littosim is its use of distributed controls (each player playing with a dedicated interface from a computer tablet) and of a projector to propose a global shared display showing the impact of flooding. Like for Sprite, the heavy use of GIS data would be been very di icult to achieve with Cormas or NetLogo, whereas the distributed control over several simulations is much more robust in the face of network disconnections than in NetLogo. This prevents running the risk of having to restart the entire game in case of a single disconnection. .
A last example that concerns urban design is CityScope (Grignard et al. ; Alonso et al. ). In this model, which simulates the daily life of the inhabitants of a city, in particular their mobility, used as a tangible interface to let stakeholders interact with the simulation (Figure ). With this interface, stakeholders can modify the city plan and get a direct feedback of the impact of these modifications on the simulation. Two displays are used to show these impacts: a first one projected on the LEGO bricks that provides information about the buildings and inhabitant mobility, and a second one projected on a screen that presents di erent sub-displays related to urban performance. The model illustrates several features of GAMA in addition to GIS data management: connection of a GAMA simulation with another so ware (the one used to analyze the LEGO city model in this case), definition of several rich displays composed of sub-displays and management of the projection of a display on a specific physical surface (wall, table, etc...).

.
These three examples illustrate the new features that we developed for the GAMA platform linked to the three main components of the development of rich participatory simulations: visualization, user interaction and simulation interconnection.

Visualization with GAMA .
Visualization is one of the main components of agent-based simulations, in particular in the context of participatory simulations (Dorin & Geard ). For many modelers, visualization is not only their first point of entry when building a model, but also an increasingly prevalent way of designing, verifying and validating models. The back and forth between writing and visualizing a model is an integral part of the daily life of modelers.

.
This visualization is part of an integrated modeling approach that gives the possibility of intuitively verifying agent states and refining individual behaviors of the agents and the expected collective or emerging structures (Grignard et al. ). This practice is a key point of participatory simulation approaches, where the visualization of the model serves as a mediation between actors and as a support for their decision-making. In order to speak to a large and heterogeneous audience and define graphical interface to a specific role, it is necessary to propose di erent views of the same simulation. .
GAMA enables modelers to easily di erentiate a model from its visualization by o ering the possibility of defining di erent displays composed of several layers per simulation. The user, depending on his/her role and  his/her level of expertise, will then visualize the simulation in a specific way and interact with its representation without altering the initial model. Figure  To go further, Figure shows a simulation of tra ic through points of view: the first display shows the individual vehicle agents moving on the network and generating tra ic (jams) and a second display drawing the tra ic jams themselves) . In an experiment, the user can define as many displays as he/she wants. Each display is composed of di erent layers. For each layer, the modeler can configure visibility, transparency, position and size of the layer.

.
As noted by Allan ( ) and Railsback et al. ( ), the use of D is still uncommon in the world of agentbased simulation, whereas using the third dimension can significantly increase the immersive property of a simulation. GAMA o ers advanced visualization features pertaining to D visualization with textures, complex lights, and custom dynamic cameras through simple GAML statements. For example, the CityScope model uses these D features for some sub-displays. .
Finally, as presented in the previous section, GAMA o ers tools to manage the projection of a display on a specific physical surface (wall, table, etc...) to avoid any resulting image deformation, which is a big advantage not only when engaging the community but also when communicating the results of a model as in some projects (Becu et al. ). Figure  participants to interact with a simulation. While some of these features such as the possibility of modifying the value of the agent's variables through the agent inspector are directly available for all simulations, some others can be specified by the modeler using the GAML language. The next sections describe all these features.

Event layer
.
In contrast to platforms such as NetLogo, GAMA permits the definition of as many displays as necessary. In addition, a modeler can specify in a display a specific layer called the event layer allowing an action to be triggered when an event occurs. The possible events considered are: mouse up, mouse down, mouse move, mouse enter, mouse exit, or a character key (keyboard event). .
Once the event is triggered, the action linked to this event is requested and can modify the state of the world. The modeler can directly access the location of the mouse in a display (in terms of coordinates in the world) through a dedicated keyword. From this location, and thanks to GAMA's spatial operators, the modeler can obtain the list of agents in the neighborhood or overlapping the mouse location.
. For example, the Sprite and Littosim models use this type of events to detect the players' actions on the display. An older example that uses a former version of event layer is presented in Chu et al. ( ): in this model concerning the coordination of a rescue team (ambulances, cops, firefighters) a er an earthquake, the user can modify, at runtime, the target of the di erent members of the rescue team by just clicking on them and the desired target, and observe the result.

User command .
In addition event layers, the modeler can define actions that can be directly activated through the GUI interface during a simulation: a user command. .
A user command can be defined in a GUI experiment or in a species of agents. .
If the user command is defined in a GUI experiment, the implemented action appears as a button on the top of the parameter view (Figure ) .
. If the user command is defined inside a species scope (either a global or a regular one), the user can access the action during execution in two ways: • When the agent is inspected, the user commands appear as buttons above the agents' attributes (Figure ).
• When the agent is selected by a right-click in a display, these commands appear in the pop-up menu (Figure ).
. For example, one of the instances of the CityScope model uses user commands to enable stakeholders to directly modify the type of mobility allowed on a road (e.g. pedestrian, bike, car).

Figure :
Interface with a user command called cmd_inside_experiment defined in the experiment Figure : Interface with a user command called cmd_inside_species defined in the my_species species -inspector view. Figure : Interface with a user command called cmd_inside_species defined in the my_species species -rightclick on the display.

User input
.
Like in NetLogo, GAMA allows the modeler to define a dialog to ask the user to give a value to one or several variables through a specific operator. This operator displays a dialog asking the user to define the values of the corresponding variables. The modeler can also add a text as an argument by the operator, which will be displayed as a title for the dialog pop-up ( Figure ). The dialog is modal and will interrupt the execution of the simulation until the user has either dismissed or accepted it. It can be used, for instance, for the purpose of initialization to force the user to input new values instead of relying on the initial parameter values. It can also be used for participative models where each user runs a client model and inputs values to the server model.

.
The Sprite model uses this feature to ask for information from the player (first of all, the player's name).

Control architecture .
Another way to define user interactions is to use the user control architecture that allows users to take control over an agent during the course of the simulation through a user-controlled panel.
. This control architecture is a specialization of the Finite State Machine Architecture (FSM) where agent behaviors can be defined by using a new construct called user panel. This user panel translates, in the interface, into a semi-modal view that waits for the user to choose action buttons, change attributes of the controlled agent, etc. .
As user panel is a specialization of state, the modeler has the possibility of describing several panels and choosing the one to open depending on a few conditions, using the same syntax as the one used for finite state machines. This ensures great flexibility in the design of the user interface, as it can be adapted to various stages of the simulation.

Simulation interconnection .
As illustrated by the work presented in Becu et al. ( ) and Grignard et al. ( ), GAMA enables a simulation to communicate with other programs through di erent protocols (TCP, UDP, MQTT).This feature allows, for example, a GAMA simulation to communicate with another GAMA simulation or with various terminals such as smartphones, tablets and sensors to export displays or to collect data. The basic idea is that any agent in the model can get the capability (through a dedicated GAML skill) to connect to a particular server and to send messages to any other agent in any other simulation that is connected to this server. Sent data is automatically and internally serialized before being sent as content of messages; this allows an agent to send data of any kind through the network. Figure : Interface with an input command that asks the user to fix the number of agents to be created. .
From a technical point of view, extensive tests have been made using an ActiveMQ message broker (MQTT protocol) with to GAMA simulations connected on it. One of the main advantages of using such an architecture is that it the negative e ects of unstable Wifi connections. In addition, it can accept connections from any type of devices such as mobile devices (based on Android or IOS) or captors. For instance, this architecture allows the modeler to connect GAMA simulations running on di erent computers with an android interface deployed on a mobile phone controlling the game.
. For example, the Littosim project (presented in Becu et al. ) uses the following type of architecture (Figure ): . Each client is controlled by a player, data is sent to the server model.
. Elevation and land cover rugosity data is updated and sent to the flooding model (external program).
. Flood simulation results are sent back to the server model and each player can evaluate damages in his/her territory.

Conclusion
. In this article, we presented the new features we developed for the GAMA platform dedicated to participatory modeling and simulation. As shown, these features enable GAMA to simplify the work of modelers in a par-ticipatory context. Several real application cases have already shown the usability of these features to create complex serious games.
. GAMA is continuously evolving and new features are constantly being added to the platform. One of the new features that is currently under development concerns the possibility of saving the di erent steps of a simulation to give the possibility of backtracking to previous steps or replay simulations. While this feature is already available in some platforms such as Cormas, its usability for KIDS models composed of thousands of agents with complex variables ( D geometries, graph...) is a real challenge.
. Furthermore, in the future, we plan to couple GAMA with a game engine such as Unity to be able to propose high-quality D displays and rich real-time interactions with a D environment. The challenge will then be to retain the simplicity of GAMA modeling, even with complex D environments.