MASON: A Multi-Agent Simulation Environment
Sean Luke, Claudio Cioffi-Revilla, Liviu Panait,
Keith Sullivan, and Gabriel Balan
Department of Computer Science and Center for Social Complexity
George Mason University
4400 University Drive, Fairfax VA 22030
http://cs.gmu.edu/∼eclab/projects/mason/
Abstract
We introduce MASON, a fast, easily extensible, discrete-event multi-agent simulation
toolkit in Java. MASON was designed to serve as the basis for a wide range of multi-
agent simulation tasks ranging from swarm robotics to machine learning to social
complexity environments. MASON carefully delineates between model and visual-
ization, allowing models to be dynamically detached from or attached to visualizers,
and to change platforms mid-run. We describe the MASON system, its motivation,
and its basic architectural design. We then compare MASON to related multi-agent li-
braries in the public domain, and discuss six applications of the system we have built
over the past year to suggest its breadth of utility.
1 Introduction
MASON is a single-process discrete-event simulation core and visualization library writ-
ten in Java, designed to be flexible enough to be used for a wide range of simple sim-
ulations, but with a special emphasis on swarm multi-agent simulations of many (up
to millions) of agents. We developed the MASON simulation toolkit to meet the needs
of computationally demanding “swarm”-style multi-agent systems (MAS) research. The
system is open-source and free, and is a joint effort of George Mason University’s Com-
puter Science Department and the George Mason University Center for Social Complex-
ity. MASON may be downloaded at http://cs.gmu.edu/∼eclab/projects/mason/
Multi-agent systems are receiving increasing research attention as affordable com-
puter brawn makes simulation of these environments more feasible. One source of in-
terest has come from social and biological models, notably ones in economics, land use,
politics, and population dynamics (for example, [1, 6, 10]). Another source stems from the
swarm robotics community, particularly as homeland security and defense interests have
bolstered investigations of large numbers of “U∗Vs” (Unmanned Aerial Vehicles, Un-
manned Underwater Vehicles, etc.) for collaborative target observation, reconnaissance,
mapping, etc. [3, 7, 18, 19]. Swarm multi-agent simulation is also a common technology
in the game and movie industries.
MASON was built from first principles to serve the needs of these research areas.
Our design philosophy was to build a fast, orthogonal, minimal model library to which
an experienced Java programmer could easily add features, rather than one with many
domain-specific, intertwined features which are difficult to remove or modify. To this
minimal model we have added those visualization and GUI facilities we have found use-
ful for various simulation tasks.
We began work on MASON because we needed a simulation toolkit which made it rel-
atively easy for us to create a very wide range of multi-agent and other simulation mod-
els, and to run many such models efficiently in parallel on back-end cluster machines.
Domains to which we intended to apply the simulator ran the gamut from robotics and
machine learning to multi-agent models of social systems (political science, historical de-
velopment, land use, economics, etc.). Our previous research in these areas had either
relied on a heavily modified robotics simulator (notably TeamBots [2]), a compiled so-
cial complexity toolkit such as SWARM [15], Ascape [20], or RePast [5], or an interpreted
rapid-development library such as StarLogo [22], NetLogo [24], or Breve [11].
We needed to run many (>100,000) simulation runs to optimize model parameters or
perform machine learning in a multi-agent problem domain. In such cases we had to
“cook” the simulations on multiple back-end servers (in Linux, Solaris, and MacOS X),
while occasionally viewing the results on a front-end MacOS X or Windows workstation.
This required speed, the ability to migrate a simulation run from platform to platform,
and (for our purposes) guaranteed platform-independence. Further, we needed to be able
to customize the simulator to different multi-agent simulation problems and applications.
The aforementioned systems did not meet these needs well, either because they tied the
model to the GUI too closely, could not guarantee platform-independent results, or being
written in an interpreted language, were slow. Additionally several such systems, and
in particular the robotics simulators, were by-and-large geared to a particular problem
domain. Rather than remove special-purpose code from an existing system (potentially
introducing bugs), we instead hoped to build on top of a more general-purpose simulator.
Given these research needs, MASON’s design goals were as follows:
• A small, fast, easily understood, and easily modified core.
• Separate, extensible visualization in 2D and 3D.
• Production of identical results independent of platform.
• Checkpointing any model to disk such that it can be resumed on any platform with
or without visualization.
• Efficient support for up to a million agents without visualization.
• Efficient support for as many agents as possible under visualization (limited by
memory).
2
• Easy embedding into larger existing libraries, including having multiple instantia-
tions of the system co-existing in memory.
There were three design goals we explicitly did not make for MASON. First, we did
not intend to include parallelization of a single simulation across multiple networked
processors. Such an architecture is radically different than a single-process architecture.
Second, we intended the MASON core to be simple and small, and so did not provide
built-in features special to social agents or robotics simulators. We felt such things were
more appropriately offered as optional domain-specific modules in the future. Third,
although we tried to be reasonably memory-efficient, this was not a priority.
We recognize that speed, model detachment, checkpointing and portability, and
strong visualization are all common in the simulation community at large. However
in the “swarm” style simulation community, MASON’s combination of architecture and
these features is essentially unique. In this paper we will discuss the architectural design
of the system, and then detail six applications of MASON presently under way.
2 Architecture
MASON is written in Java in order to take advantage of its portability, strict math and
type definitions (to guarantee duplicable results), and object serialization (to checkpoint
out simulations). Java has an undeserved reputation for slowness; and our past experi-
ence in developing the ECJ evolutionary computation toolkit [13] suggests that carefully-
written Java code can be surprisingly fast.
The toolkit is written in three layers: the utility layer, the model layer, and the visu-
alization layer. The utility layer consists of classes which may be used for any purpose.
These include a random number generator; data structures more efficient than those pro-
vided in the Java distribution; various GUI widgets; and movie and snapshot-generating
facilities. Next comes the model layer, a small collection of classes consisting of a discrete-
event schedule, schedule utilities, and a variety of fields which hold objects and associate
them with locations. This code alone is sufficient to write basic simulations running on
the command line.
The visualization layer permits GUI-based visualization and manipulation of the
model. Figure 1 shows a simplified diagram relating basic objects in the model and visu-
alization layers. For most elements in the model layer, down to individual fine-grained
objects in the model, there is an equivalent “proxy” element in the visualization layer
responsible for manipulating the model object, portraying it on-screen, and inspecting
its contents. A bright line separates the model layer from the visualization layer, which
allows us to treat the model as a self-contained entity. We may at any time separate the
model from the visualization, checkpoint the model to disk, move it to a different plat-
form and let it continue to run, or attach an entirely different visualization collection.
Figure 2 shows this procedure.
3
SimState
Mersenne
Twister [RNG]
Schedule
(Field)
1
0..*
Steppable
[“Agent”]
0..*
1
Schedules
(Any Object or
Value)
1..*
0..*
Associates with
a Location
Console
GUIState
Display2D
Display3D
(2D Field
Portrayal)
(3D Field
Portrayal)
(2D Simple
Portrayal)
(3D Simple
Portrayal)
(Inspector)
0..*
1..*
0..*
1..*
1..*
1..*
1..*
1..*
Displays
and
Edits the
Attributes
of
Controls
Visualizes
Visualizes
Field
Portrayal
Simple
Portrayal
1
0..*
1
0..*
Produces
Model
Layer! !!!! !!!!!
Visualization
Layer
Figure 1: Highly simplified UML diagram of the basic classes in the Model and Visualiza-
tion layers. Items in (parentheses) indicate sets from which numerous class are available.
4
Model Running
on Back-End
Platform
Disk
Checkpointed
Visualization Tools
Model Running
under Visualization
on User's Platform
Recovered
Checkpointed
Recovered
Figure 2: Checkpointing and recovering a MASON model to be run standalone or under
different kinds of visualization.
2.1 The Model Layer
MASON’s model layer has no dependencies on the visualization layer and can be sepa-
rated from it. A MASON model is entirely contained within a single instance of a user-
defined subclass of MASON’s model class (SimState). This instance contains a discrete-
event Schedule, a MersenneTwister random number generator, and zero or more fields.
Agents and the Schedule MASON employs a specific usage of the term agent: a com-
putational entity which may be scheduled to perform some action, and which can manip-
ulate the environment. Note that we do not explicitly state that the agent is physically in
the environment, though it may be; in this case we would refer to the agent as an embod-
ied agent. Agents are brains which may or not be embodied. MASON does not schedule
events to send to an agent; rather it schedules the agent itself to be stepped (pulsed or
called) at some time in the future. Hence MASON’s agents implement the Steppable in-
terface, as is shown in Figure 1. Scheduling an agent multiple times for different functions
is easily done with an anonymous wrapper class.
MASON can schedule Steppable objects to occur at any real-valued time in the future.
Further, the Schedule may be divided into multiple orderings which further subdivide
a given timestep: agents scheduled at a given time but in an earlier ordering will be
stepped prior to agents scheduled at the same time but in a later ordering. MASON
also provides various Steppable wrappers which can group agents together, iterate them,
perform them in parallel on separate threads, etc. Agents may be scheduled to run in their
own thread asynchronous with the schedule. This thread may run until completion, loop
indefinitely, or run until the Schedule reaches some later timestep.
Fields MASON’s fields relate arbitrary objects or values with locations in some notional
space. Some of these fields are little more than wrappers for simple 2D or 3D arrays. Oth-
ers provide sparse relationships. An object may exist in multiple fields at one time and,
in some fields, the same object may appear multiple times. The use of fields is entirely
optional, and the user may add additional fields of his own devising. MASON provides
fields for:
5
