=Paper=
{{Paper
|id=None
|storemode=property
|title=BaSi: Multi-Agent Based Simulation for Medieval Battles
|pdfUrl=https://ceur-ws.org/Vol-741/ID11_MolesiniDentiOmicini.pdf
|volume=Vol-741
|dblpUrl=https://dblp.org/rec/conf/woa/MolesiniDO11
}}
==BaSi: Multi-Agent Based Simulation for Medieval Battles==
https://ceur-ws.org/Vol-741/ID11_MolesiniDentiOmicini.pdf
BaSi:
Multi-Agent Based Simulation for Medieval Battles
Ambra Molesini∗ , Enrico Denti∗ and Andrea Omicini†
∗ A LMA M ATER S TUDIORUM – Università di Bologna
Viale Risorgimento 2, 40136 Bologna, Italy
Email: {ambra.molesini, enrico.denti}@unibo.it
† A LMA M ATER S TUDIORUM – Università di Bologna a Cesena
Via Venezia 52, 47521 Cesena, Italy
Email: andrea.omicini@unibo.it
Abstract—When dealing with non-trivial social systems, Multi- tions emerging between individual behaviour and structural
Agent Based Simulation (MABS) makes it possible to model and system properties help formulating/validating theories about
simulate social aspects without neglecting articulated motivations, ethological, sociological, psychological systems.
decisions and behaviours by individuals. In this paper, we
experiment with the simulation of a peculiar sort of social system In this paper, we experiment with MABS by taking Me-
– namely, Medieval Battles – by using general-purpose agent dieval Battles as our reference case study. Among the main
methodologies and technologies – namely, SODA and TuCSoN reasons for our choice:
– in order to better understand and emphasise the benefits of
• it is a non-numeric domain involving both quantitative
MABS in the simulation of social systems.
and qualitative aspects;
I. I NTRODUCTION • the domain features multiple roles and requires a clear
mapping of their relationships;
Simulation aims at modelling and reproducing some natural, • the scenario inherently emphasises individual war-
ethological, social or conceptual phenomena [1]. The process rior/agent autonomy, while calling for a clear definition
of designing a simulation usually starts by identifying the of social strategies and tactics;
features of interest of the system to be modelled, taking into • there is a widespread focus on interaction issues;
account the desired abstraction level; then, a suitable system • environment has a prominent role—a particularly inter-
representation is defined, the model is built accordingly, and esting issue in MABS;
the simulation is finally run based on some carefully-selected • the scenario promotes emergent behaviours;
input data or application scenarios. • it is a good testbed from the methodological viewpoint—a
While traditional simulation techniques often model the relevant aspect indeed, given the amount of related work
system dynamics based on systems of equations, this can in the field of agent methodologies for simulation;
hardly be made with complex systems, like for instance • it is a good testbed from the infrastructural viewpoint, as
ecosystems and human communities, where many autonomous it calls for a powerful and expressive agent coordination
individuals interact continuously. In particular, traditional nu- platform to actually implement and run the system.
merical simulations do not consider actions explicitly, nor
Accordingly, in the remainder of this paper we first (Section II)
do they model explicitly interactions among individuals: so,
provide some background about medieval battles in general,
individuals’ actions are not perceived as such, but only in terms
and briefly overview the agent methodology (SODA) and
of impact (the effects) they have on the environment. This
infrastructure (TuCSoN) adopted; then (Section III) we focus
prevents the relation between an action and the decisions that
on the battle simulation system, discussing the whole develop-
determined it (most likely, based on the current environment
ment process from the requirement analysis to the design, up to
state) to be suitably expressed. Moreover, numeric simulations
the working prototype. Finally, some related work is presented
are not meant to capture qualitative aspects such as the relation
(Section IV), and conclusions are drawn (Section V).
between a stimulus and the consequent behavior, which are
often more relevant issues in several complex systems than II. BACKGROUND
the quantitative aspect per se.
Multi-Agent Based Simulation (MABS henceforth) promote A. Medieval battles
a different approach to simulation, where interactive entities During the Roman empire, the army was structured accord-
live, behave and interact in an agent society that represents ing to a rigid, hierarchical organisation, rooted on infantry:
the system to be modelled, making it possible to capture discipline, order and organisation provided strong attack and
both quantitative and qualitative aspects altogether. In this defense force (e.g. the world famous testudo). In the sub-
context, emerging behaviours can be observed as the result sequent centuries, however, structure and discipline became
of individual interactions and choices. The consequent rela- gradually less relevant, in favor of individual qualities of
Mapping
soldiers – barbaric armies, indeed, were more like mobs than References
Tables
Analysis Transitions
Tables
Tables Design
structured armies. Battles occurred between groups of soldiers,
Requirements Architectural Detailed
with little or no coordination among them, often without a Analysis
Analysis
Design Design
clear command chain. This aspect became extreme during Requirements Tables Responsibilities Tables
Entities Tables Agent/Society Design Tables
crusades, which exalted individual heroism. Soldiers were Domain Tables Dependencies Tables
Interaction Tables Environment Design Tables
Relations Tables Topologies Tables
typically armed with swords, halberds, lances, pikes, arches, Constraints Tables
Topological Tables
Interaction Design Tables
Topological Design Tables
and crossbows.
The coming of cavalry, from the 5th century, changed the
Fig. 1. An overview of the SODA process
scenario, confining infantry to a complementary role (bowmen
and similar “specialised” troops), with the only exception
of the siege to a town or castle, where infantry remained artifact, etc.); and iii) the abstractions for interaction and
obviously essential. Knights were typically equipped with organisational rules (relation, dependency, interaction, rule,
sword, armor, shield, and lance: such a heavy equipment and etc.). As depicted in Fig. 1, the SODA process is organised
its maintenance called for both robust horses and auxiliary in two phases, structured in two sub-phases: the Analysis
personnel – a squire, pageboys and servants, all riding on phase, which includes the Requirements Analysis and the
horseback, too – and was all at the knight’s expense. This Analysis steps, and the Design phase, including the Architec-
made knights quickly become sorts of “human tanks”, virtually tural Design and the Detailed Design steps. Each sub-phase
impossible to face in an open battlefield: the typical formation models (designs) the system exploiting a subset of SODA
consisted of a single knight line, with squires at their back – or, abstractions: in particular, each subset always includes at least
alternatively, at their side. Other times, squires were grouped one abstraction for each of the above categories – that is, at
in small squads, forming a sort of “light cavalry”. However, least one abstraction for the system active part, one for the
specialised troops – pikemen – constituted a real danger for reactive part, and another for interaction and organisational
knights: wisely used, they could lead to the total destruction of rules.
the cavalry. In such cases, bowmen troops were used instead
of cavalry, saving knights for a later time. C. The TuCSoN agent-oriented infrastructure
Tactics were quite simple: troops layout were mostly stan- TuCSoN (Tuple Centres Spread Over Networks) [7], [8]
dard, only seldom adapted to the conformation of the ground is an infrastructure for the coordination of distributed au-
or other factors, so victory or defeat typically depended on tonomous agents via tuple centres [9]. Agents access tuple
the size of the army and, to some extent, individual qualities – centres associatively, by writing, reading, and consuming
which often turned the battle into a de-structured set of one-to- tuples via the TuCSoN coordination primitives. A TuCSoN
one duels. As for cavalry, a typical tactic consisted of attacking tuple centre is a coordination abstraction perceived by agents
the enemy and then (falsely) retreating, trying to attract it in as a standard tuple space [10], whose behaviour in response to
pursuit – to counterattack shortly afterwards, exploiting the events can be defined so as to embed the laws of coordination
consequent disorder. via the ReSpecT language [5].
Summing up, due to the lack of discipline, structure and While TuCSoN features other abstractions and properties
order, even simple tactics could make the difference in me- that are not of interest here (like the Agent Coordination
dieval battles and often be enough to compensate even quite Context [11]), what is relevant here is the strict relationship
a large numeric disadvantage. On the other side, however, between the methodology and the software infrastructure used
the lack of coordination in the command chain, coupled with to design and implement the MABS system [12]: in particular,
personal visibility goals of individual warriors, could easily SODA and TuCSoN share both the conceptual meta-model
vanify the tactic abilities of a commander. So, the final result (A&A [13]) and the focus on the interaction issues.
of a battle was more an emergent behaviour coming out from
a collection of individual choices and performance, rather than III. BaSi: BATTLE S IMULATION
the expected result of a clearly-planned strategy. In this section we first define the intended scenario (Sub-
section III-A), then proceed from the preliminary problem
B. The SODA agent-oriented methodology analysis (Subsection III-B) – independent of the SODA design
SODA (Societies in Open and Distributed Agent spaces) process – to the problem analysis (Subsection III-C) and the
[2], [3] is an agent-oriented methodology for the analysis and system design (Subsection III-D) – both executed following
design of agent-based systems, which adopts the Agents & the SODA process –, up to develop the BaSi prototype
Artifacts (A&A) meta-model [4], [5] and introduces layering (Subsection III-F).
as the main tool for scaling with the system complexity, Due to space constraints, only a minimal but meaningful
applied throughout the analysis and design process [6]. subset of SODA tables and a few screenshots are reported, and
The SODA abstractions (explained below) are logically only the analysis and design of the simulation sub-system are
divided into three categories: i) the abstractions for mod- discussed: the user-interface sub-system is left aside, except
elling/designing the system active part (task, role, agent, etc.); for a short description on how the two sub-systems can be
ii) the abstractions for the reactive part (function, resource, integrated.
A. Scenario to decide its disposition in the battlefield and its actions
Our goal is to realise a simulation system that enables users during the fight;
• agent societies can well capture the social aspects of the
to i) define two armies, ii) modify the default properties of the
different kinds of soldiers, iii) start the battle simulation, iv) army, such as its social goals (e.g. enemy destruction) and
observe the battle progress and result. Of course, soldiers have the social rules that govern its organisation: in particular,
to manifest autonomous behaviour, and the simulation has to agent societies can map also the cases where the army
evolve with no user intervention. The simulation ends when organisation changes during the battle, thanks to agent’s
one of the two army is defeated—i.e., all of its soldiers are adaptability;
• the multiagent system (MAS henceforth) environment can
dead.
Defining an army means to specify at least a) the quantity of capture both the topological aspect of the battlefield and
soldiers, per type – i.e. the number of knights, bowmen and the presence of the abandoned objects, which covers the
pikemen, respectively; b) the army commander; and c) the last key aspect of the simulation sub-system.
army organisation. With respect to this issue, three different As a preliminary step of the design process of the simulation
organisations are possible: sub-system, a soldier model, intended as a collection of his
• Informal: the army does not feature a rigourous or-
relevant properties, has to be defined. For our purposes, we
ganisation: the spatial disposition of soldiers depends assume henceforth the following soldiers’ characterisation:
on individual decisions, and there is only one general • Type: the soldier type (knight, bowman or pikeman)
commander in chief. • Army: the belonging army
• Two-levels: the army is structured in parties that are • Speed: the maximum soldier speed in the battlefield
typically composed by a uniform kind of soldiers – e.g. • Vigour: the maximum tolerable damage (before dying)
knight party, bowmen party and pikemen party. Each • Attack strength: the maximum damage inflicted to an
party is driven by a party head that refers to the army enemy
commander. • Defence strength: the maximum decrease of the damage
• Three-levels: the army adopts an even more structured caused by an enemy
organisation, where parties are split in maniples. Each • View scope: the maximum distance at which the soldier
maniple has its own head, who refers to the party head can see
(who, in turn, refer to the army commander). • Attack scope: the maximum distance at which the soldier
Finally, during the battle, soldiers can also pick up abandoned can attack
objects, such as equipment from died soldiers (both enemy • Killing: the number of enemies killed when attacking
and friends) like weapons, food, horses, armours, etc. • Loading: the maximum load that the soldier can carry
• Equipment: the list of the soldier’s objects (weapons,
B. Preliminary analysis food, money, etc.)
Preliminary requirements analysis suggests that the problem Each equipment object corresponds to a bonus/malus incre-
is decomposed in two main sub-problems: i) managing the ment in some soldiers’ properties: for instance, the presence
actual simulation (army creation, battle management, etc.); of a horse increases the soldier’s speed and view scope,
ii) managing the user-system interaction (capturing the user which is instead decreased by a heavy armour; food increases
commands and graphically rendering the battle). These sub- the soldier’s vigour; etc. Of course, each property (including
problems can be assigned to two sub-systems – the simulation bonus/malus coefficients) has a default value, that can be
and the user-interface sub-systems, respectively – to be de- modified by the user before starting the simulation.
signed independently from each other, while taking into proper
account the information flow between them. C. Analysis
Quite expectedly, all the core aspects of this paper are Analysis in SODA consists of two sub-phases: Require-
in the first sub-system: in fact, the user-interface sub-system ments Analysis and Analysis.
(despite its potential graphical complexity) is simply con- Requirements Analysis. Following the choices discussed in
cerned with getting initial parameters from the user and Subsection III-B, here we focus on the simulation sub-system,
providing graphical results, and therefore does not require as the user-interface sub-system can be considered a part of
autonomous/intelligent entities; its design can then follow a the system environment, wrapped by a suitable artifact: so, its
standard object-oriented process, and will not be discussed presence appears only in terms of its interactions with the other
here. SODA entities in the design process. Its observable behaviour
The simulation sub-system, instead, is well suited for an will then constitute one of the requirements of its own (object-
agent-oriented approach, as the agent abstractions seem partic- oriented) design process, which is not discussed here.
ularly adequate to capture the key aspects of medieval battles: The simulation system requirements at the core layer are
• agents’ autonomous and intelligent behaviour can easily reported in Fig. 2. This is intentionally a high-level view, aimed
model the soldiers: in turn, this makes it easy to model at highlighting the main coarse-grained requirements: so, just
the army informal organisation, where each agent is able three items – army, simulation, and monitoring – are listed.
Such requirements will then be refined later in the process, graphically rendered: soldier’s position and energy, position
exploiting SODA layering – i.e., its ability to support different of abandoned objects, etc.).
levels of detail.
Several relations exist among such requirements: for in- Function Description
stance, there is clearly an order relation between “Army State Area providing the state of a specific
Definition” and “Simulation”, as between “Simulation” and battlefield area
“Monitoring”. Detecting such relations at this stage is impor- Update Soldier State updating soldier state
tant, as they will impose constraints and interactions in the Battlefield State providing battlefield state
following steps. Update Battlefield State updating battlefield state
Rendering showing the battlefield state changes
Requirement Description Command obtaining user command
Army Definition definition of the armies in terms of Ext Update Soldierd obtaining user modifications
soldiers and their parameters to soldier parameters
Simulation management of the simulation
Fig. 4. Function table.
Monitoring monitoring the battle progress and
identification of the army winner Topological aspects are also extremely relevant in our
Fig. 2. Requirement table. scenario, since soldiers can engage a fight only if they are close
Analysis. In this phase, the above requirements are mapped enough to each other, and the battle strategy itself depends on
onto tasks, and are further analysed to identify the environmen- (and is strictly related to) the topology of the enemy army.
tal functions and the topological structure of the environment; So, in this application the role of the environment topology is
dependencies among tasks and functions are also individuated. twofold: on the one hand, it determines the “physical” structure
Tasks identified in this phase are usually more fine-grained of the battlefield, in terms of the “zone” that can be perceived
than requirements: yet, they are still at a relatively high by each soldier; on the other, it determines the constraints over
abstraction level, to be in-zoomed later in the process. Fig. 3 the soldiers’ actions and perceptions in terms of the soldiers’
reports the mapping between the requirements and the tasks “scopes”. Such scopes can be composed by multiple zones,
they generate in our case. depending on each soldier’s characteristics and equipment: for
instance, a knight can perceive larger areas thanks to his higher
Requirement Task position, while bowmen’s attacks can go farther, etc.
Army Definition define knight, define bowman,
define pickman, define party
D. Design
define maniple, define head, Design in SODA consists of two sub-phases, too: Architec-
attack, defence, collaboration
tural Design and Detailed Design.
Simulation start, stop,
pause
Architectural Design. In this phase, the system is designed
Monitoring show status, check soldier,
in terms of roles, resources, actions, operations, interactions,
check progress rules and spaces. These entities derive form the abstractions
outlined in the previous step: roles are responsible for the
Fig. 3. Reference Requirement-Task table.
achievement of tasks by executing actions, resources provide
Environmental functions can be classified here basically in the functions by implementing the corresponding operations,
two categories: i) functions belonging to the internal MAS spaces derive from the topology and map one-to-one the
environment (battlefield management, soldiers’ property man- physical structure of the battlefield. Mappings between tasks
agement, etc. – Fig. 4 top), and ii) functions provided by the and roles, and between functions and resources, instead, are
user-interface sub-system (Fig. 4 bottom). not usually one-to-one, as a role/resource is able to com-
Dependencies among tasks and functions exist, and must plete/accomplish several different tasks/functions: for instance,
be carefully investigated as they determine the interaction the resource “Battlefield” could provide both the “Battlefield
spaces of each entity, the rules that govern interactions, and the State” and “Update Battlefield State” functions in Fig. 4.
related social aspects (like army organisation management). The key aspect of the system – interaction – is captured
In our case, for instance, soldiers’ movements strictly depend by the SODA abstract entities interactions (derived from
on the orders issued by the army’s (or party’s, or maniple’s) dependencies), and rules (derived from both dependencies and
commander; moreover, even the fights could be modelled as topologies): again, such mappings are expressed by suitable
a dependency involving soldiers of the enemy armies. Further tables. Fig. 5 shows an excerpt of the full Rule table, reporting
dependencies are generated by the functions of the user- some representative rules for each “macro area”: the first block
interface sub-system, and represent the information exchanged concerns the battle rules (Attack Rule and Win Rule), the
between the simulation and the user: some occur in the second is about the internal management of an army (PickUp
user → simulation direction (update the soldier’s parameters, Rule and Army Head Rule), the third concerns the order
starting/stopping the simulation, etc.), others in the oppo- relations highlighted in the Requirements Analysis phase (Start
site one (everything representing the battlefield state to be Rule and Monitoring Battlefield Rule).
Rule Description mapped onto speakTo entities, agent-artifact interactions onto
Attack Rule The attack action is possible only if the use entities, artifact-agent interactions onto manifest entities,
enemy is in the scope of the attacker
and artifact-artifact interactions onto linkedTo entities.
Win Rule An Army wins the battle only
if the number the enemy army Rules, too, are mapped taking into account the different
soldiers reaches zero nature and purpose of each rule. In particular, rules aimed at
PickUp Rule A soldier can pick up an controlling the interaction of a single agent within the MAS
abandoned object if this last is near to are mapped onto the agent’s individual artifact [14]—a kind of
the soldier artifact associated to each agent and used as a “proxy” between
Army Head Rule The army head’s command the agent and the MAS, to shape and negotiate the set of
is the more priority command
admissible agent actions in/onto the MAS; in BaSi, this is the
Start Rule The simulation starts only if case, for instance, of the “Attack Rule” and the “PickUp Rule”
the state of Interface Resource is start (Fig. 5). Instead, rules concerning social and organisational
Monitoring Battlefield The state of the BattleField Resource aspects (such as “Win Rule” and “Army Head Rule” in Fig. 5)
Rule can change only if the simulation is started
are mapped onto social artifacts [14]—a kind of artifact
Fig. 5. Rule table. specifically devoted to the management of social interactions1
which is typically used in SODA as a coordination medium,
encapsulating the laws that govern an agent society. In BaSi,
Detailed Design. In this phase, one Detailed Design has to
the two agent societies defined above (“Army Society” and
be chosen from the various potential alternatives compatible
“Simulation Society”) require two social artifacts: we call
with the Architectural Design constraints. Detailed Design
these “Army Artifact” and “Simulation Artifact”, respectively.
is expressed in terms of agents, agent societies, artifacts,
As a further design choice inspired by a conceptual economy
aggregates and workspace for the architectural entities, and
principle, we decide that these artifacts also take care of the
of concepts such as use, manifest, speakTo and linkedTo for
two above-mentioned organisational rules (“Win Rule” and
interaction types. So, moving from the Architectural Design
“Army Head Rule”), which actually concern the same sets of
to the Detailed Design means to decide a mapping for all
agents; of course, different choices would be possible, with
the architectural entities and abstractions onto actual design
pros and cons.
entities, deciding which level of detail is the most adequate
for each one. The activity of selecting the most adequate Despite all this complexity, the design presented here is
representation level for each architectural entity is called just a partial view of the actual system (Subsection III-F):
carving. in the full scenario, agents in each army could be organised
In our case, however, since a very high abstraction level according to specific military structures, which could not be
was adopted for the core layer, and no in-zoom operation reasonably managed by a single social artifact for performance
was performed, carving is quite straightforward: most of and reliability reasons—preventing bottlenecks, avoiding de-
the architectural design entities can be mapped 1-1 onto lays in the system responses, etc. So, the “Army Artifact”
corresponding Detailed Design entities. So, agents in BaSi should rather be seen as an abstract view of an aggregate of
play simply the roles individuated in the previous step, while social artifacts, each enforcing some given kind of rules.
resources are mapped onto suitable environmental artifacts—a Fig. 6 shows an excerpt of the Artifact-UsageInterface table,
kind of artifact [14] which is particularly suited for wrapping which lists all the operations provided by all artifacts in detail.
MAS external environments, or realising functions derived
by requirements. (In fact, an environmental artifact is perfect
Artifact Usage Interface
for wrapping the user-interface sub-system as a black-box,
Army receive headCommand
according to the choices made in the Requirements Analysis.) Artifact send headCommand
Spaces and space connections are also mapped 1-1 onto (social) add soldier, remove soldier
workspaces and workspace connections. set strategy, get strategy
get position, set position. . .
The only real carving decision concerns Agent Societies:
Simulation start simulation,
taking inspiration from Fig. 3, we opted for just two agent Artifact stop simulation,
societies — one “Army Society” grouping all the agents (social) pause simulation. . .
performing army-related tasks (first line of Fig. 3), and one Properties set property, get property
“Simulation Society” grouping all the agents performing Artifact add soldierType, add property
get soldierTypes, get armyTypes. . .
management-related tasks (second and third lines of Fig. 3).
So, “Army Society” is composed of agents representing the Fig. 6. Artifact-UsageInterface table.
army commanders, parties, maniples, knights, bowmen, and
pikemen, while “Simulation Society” includes all the other
agents responsible for the simulation management. 1 This often occurs indirectly, since social artifacts technically mediate
The mapping of interactions takes into account the different interactions between individual, environmental, and possibly other social
nature of interaction acts: so, agent-agent interactions are artifacts.
Fig. 8. An overview of the composition structure
!
–, and so are other aspects, like heads and commanders (which
Fig. 7. An overview of the user-interface sub-system are rendered as edged icons, like the knight of the Red Army
in Fig. 9 – a), soldiers’ energy level (rendered as black lines
over the icons, in percentage terms), and the soldier’s current
E. Sub-systems composition energy level (number inside the icon).
According to the general choices made in the Preliminary Before the simulation can start, the user has to specify
Analysis, the BaSi development has been split in one agent- some initial parameters – army names, armies’ organisational
oriented process for the simulation sub-system (discussed structures (to be chosen among informal, party or maniple),
above), and one more “classical” object-oriented process for and battlefield size – and can optionally change the default
the user-interface sub-system. Although a full discussion of the values of soldier properties (Fig. 9 - c). If the informal army
latter is outside the scope of the paper, its outcome is necessary organisation has been selected, only one commander can be
to integrate the two sub-systems together. As shown in Fig. 7, indicated; otherwise, party heads and maniple heads can also
the user-interface sub-system is made of seven components, be specified for each party or maniple, respectively.
each responsible for a given functionality: VisualEnv is the The simulation can be started, paused and stopped using
graphical renderer that animates and updates the graphical el- the appropriate controls (Fig. 9 - b)): at any time, the battle
ements in the battlefield, PropertiesManager enables the mod- progress can be monitored. The simulation automatically stops
ification of the simulation parameters, ArmyManager provides when an army wins — that is, all of its soldiers are dead.
for army creation, BattlefieldModel stores the battlefield data, Technically, the prototype is structured according to the
SimulationFaçade takes care of the data exchange with the UML diagram in Fig. 10, and is implemented on top of
simulation sub-system, SimulationController handles the user the TuCSoN infrastructure, whose tuple centres are used to
commands to activate, pause and deactivate the simulation, build the social artifacts and support/mediate between the
and finally Logger logs all the activities of all components. information exchange. The diagram highlights the information
The consequent integration, presented in Fig. 8, is straight- exchange between the two sub-systems, and the key role
forward, since the user-interface sub-system behaviour and played by TuCSoN tuple centre for this purpose and for real-
its interactions with the simulation sub-system were both ising the social artifacts, managing the agents coordination and
carefully designed during the SODA process: qualitatively enforcing the organisational rules via the ReSpecT reactions.
speaking, the user-interface sub-system is wrapped by an ad-
IV. R ELATED W ORK
hoc User-interface Artifact, which puts that sub-system inside
the MAS. Interactions take care of the information exchange A. Simulation frameworks for social systems
among the two sub-systems: in particular, linkedTo interac- A specific area of agent-oriented computing where simula-
tions connect SimulationFaçade to the Simulation Artifact, tion finds many applications is that of social systems, where
so that the user commands coming from the GUI compo- specific simulation frameworks have been employed.
nents (SimulationController or ArmyManager) are properly Sierra et al. present an integrated development environment
forwarded to Simulation Artifact via SimulationFaçade, and for the engineering of MASs as Electronic Institutions (EI)
hance dispatched to the Simulation Society and Army Society, [15], [16]. This includes SIMDEI, a simulation tool which
as required — and vice versa. allows for the animation and analysis of the specification of the
rules and protocols in an EI. In this approach, once specified
F. Prototype an institution, it should go through a verification process to
Given the goals of our work, focuses on MAS technologies verify it. After an initial verification process focusing on
for simulation, only a minimal effort was devoted to the static, structural properties of the e-institution specification,
graphical rendering: as shown in Fig. 9, the battlefield and the next step follows that concerns the expected dynamic
soldiers are shown with simple icons – squares represent properties of the e-institution at work: this is done by means of
knights, circles represent bowmen, triangles represent pikemen simulation, with the aim of verifying the dynamic properties of
a)
b) c)
Fig. 9. Some screenshot of BaSi: a) army deployment interface, b) main interface during simulation, c) tuning parameters and property interface
the specified institution. Once agents have been implemented, In Röhl and Uhrmacher [19] a modelling and simulation
simulations of the e-institution can be ran using the SIMDEI framework (DynDEVS) based on a discrete-event formalism
simulation tool developed over Repast (Recursive Porous for supporting the development process of multi-agent sys-
Agent Simulation Toolkit). The institution designer should tems from specification to implementation is proposed. The
analyse the results of the simulation and return to initial step, framework allows for the incremental refinement of agents
if they differ from the expected ones. and experimental set-ups while providing rigorous observation
facilities. The exploited simulation framework is JAMES, a
In Pavòn et al. [17], a simulation phase based on the agent- Java-Based Agent Modelling Environment for Discrete Event
based simulation toolkit Repast is defined and introduced Systems Specification (DEVS)-based Simulation, which aims
for the INGENIAS [18] methodology for the development at exploring the integration of the agents paradigm within
of MASs. The main objective is to support modelling and a general modelling and simulation formalism for discrete-
simulation of social systems. In particular the authors modified event systems. Devs (Discrete EVent System specification) is
the INGENIAS MAS meta-model in many ways: i) envi- one of the formal approaches to discrete event modelling and
ronment model, since for social simulation, agents usually simulation stemming from general systems theory. It provides
require to consider their location in the environment and the a powerful basis for modelling test settings by being able to
evolution of time; ii) modelling constant time steps to simulate encode many other modelling formalisms like statecharts and
the cycle perception-reaction of agents along the time, since petri nets.
authors have assumed time driven simulations as a reference.
In addition, the authors have created a mapping from the new Sarjoughian et al. [20] presents a layered architectural
INGENIAS to the Repast toolkit, implemented by an IDK framework to support agent-based system development in a
module. collaborative, multidisciplinary engineering setting: the en-
Fig. 10. An overview of the prototype structure
vironment is assumed to enable agent-based modelling and of MASs which incorporates a simulation phase for the
simulation Authors consider requirements for a generic, com- prototyping of the MAS being developed and for functional
prehensive modelling and simulation architecture suitable for and nonfunctional validation. PASSIM was obtained by in-
MAS, and emphasise the need for separating modelling and tegrating – according to a process-driven method engineering
simulation activities, which is argued to have a profound approach – fragments coming from two existing agent-oriented
impact on reusability and portability. methodologies: on the one hand, the PASSI methodology [25]
carries out the analysis, design and coding phases, while the
B. Simulation in agent methodologies above-mentioned Distilled State Charts (DSC)-based simula-
Some proposals exist whose goal is to provide general tion method [21], [22] is used for supporting the simulation
AOSE methodologies incorporating a simulation phase. phase. PASSIM is supported by MASSIMO (Multi-Agent
In Fortino et al. [21], [22] an integrated approach is pre- System SIMulator framewOrk) [22], a Java-based discrete-
sented, centred on the instantiation of a software development event simulation framework for MASs which allows for the
process which specifically includes a simulation phase used validation and evaluation of: the dynamic behaviour of in-
to validate a multi-agent system before its actual deployment dividual and cooperating agents; the basic mechanisms of
and execution. The approach uses process fragments coming the distributed architectures supporting agents, namely agent
from the Gaia [23] methodology for the analysis and the platforms; the functionalities and emergent behaviours of ap-
design, the Agent UML and the Distilled StateCharts for the plications and systems based on agents. The simulation results
detailed design, the MAO Framework for the neutral- platform can be used to feed back the Simulation Model Definition.
implementation of software agents, and a Java-based discrete- easyABMS [26] is another agent-based methodology for
event simulation framework for the simulation. In particular, the modelling and simulation of complex systems, which
the simulation phase provides both qualitative and quantitative seamlessly covers from the system analysis to the system
information about correctness and efficiency, to be exploited modelling phase, up to the analysis of the simulation results.
for reformulating, modifying and/or refining some choices of Each phase of the easyABMS (iterative) model-driven process
the previous phases of the development process. An agent- refines the model produced in the previous phase. While
based system is validated and evaluated by implementing a its work-products are mainly visual (UML) diagrams, the
simulator program, whose execution provides a history of the simulation code is also automatically generated, thanks to the
timed events generated and received by the agents; the analysis advanced features of visual modelling and of (semi)automatic
of the trace file can be used to validate the correctness of the code generation provided by the Repast Simphony Toolkit.
agent interactions and behaviours. Summing up, the SODA approach turns out to be quite
The work in Cossentino et al. [24] proposes the Pro- different from the three above methodologies. In fact, SODA
cess for Agent Specification, Simulation and Implementation does not consider simulation as a specific part of the process
(PASSIM), a simulation-based process for the development design, although we are currently working on an extension for
introducing a specific simulation phase: so, the outcomes of [2] A. Omicini, “SODA: Societies and infrastructures in the analysis and
the SODA process are not currently validated by a simulation design of agent-based systems,” in Agent-Oriented Software Engineer-
ing, ser. LNCS, P. Ciancarini and M. J. Wooldridge, Eds. Springer,
phase as they are in the other cases. Moreover, unlike Repast, 2001, vol. 1957, pp. 185–193, 1st International Workshop (AOSE 2000),
the TuCSoN infrastructure is not specifically designed for sim- Limerick, Ireland, 10 Jun. 2000. Revised Papers.
ulation, either: so, our work can be seen as a first experiment [3] SODA, “Home page,” http://soda.apice.unibo.it. [Online].
Available: http://soda.apice.unibo.it
to explore how SODA and TuCSoN can support the develop- [4] A. Molesini, A. Omicini, E. Denti, and A. Ricci, “SODA:
ment of a MABS system, aimed at a better understanding of A roadmap to artefacts,” in Engineering Societies in the
the SODA limits in the simulation scenario and plan its future Agents World VI, ser. LNAI, O. Dikenelli, M.-P. Gleizes, and
A. Ricci, Eds. Springer, Jun. 2006, vol. 3963, pp. 49–62, 6th
extension. International Workshop (ESAW 2005), Kuşadası, Aydın, Turkey, 26–
28 Oct. 2005. Revised, Selected & Invited Papers. [Online]. Available:
V. C ONCLUSIONS AND F UTURE W ORK http://www.springerlink.com/link.asp?id=j68l84713542525p
[5] A. Omicini, “Formal ReSpecT in the A&A perspective,” Electronic
In this paper we present a first application prototype for the Notes in Theoretical Computer Sciences, vol. 175, no. 2, pp. 97–
117, Jun. 2007, 5th Inter. Workshop on Foundations of Coordination
simulation of medieval battles. The main objective of this work Languages and Software Architectures (FOCLASA’06), CONCUR’06,
was to investigate the suitability of MABS in the development Bonn, Germany, 31 Aug. 2006. Post-proceedings.
of an articulated scenario such as medieval battles. So, we [6] A. Molesini, A. Omicini, A. Ricci, and E. Denti, “Zooming multi-agent
systems,” in Agent-Oriented Software Engineering VI, ser. LNCS, J. P.
deliberately left apart aspects that are normally relevant for a Müller and F. Zambonelli, Eds. Springer, 2006, vol. 3950, pp. 81–93,
simulation system, such as a rigourous and efficient simulation 6th International Workshop (AOSE 2005), Utrecht, The Netherlands,
engine, the realisation of both a complex graphical interface 25–26 Jul. 2005. Revised and Invited Papers. [Online]. Available:
http://www.springerlink.com/link.asp?id=h6529n587642uh24
and a detailed animation of the graphical elements. [7] A. Omicini and F. Zambonelli, “Coordination for Internet application
Yet, the experiment turned out to be an interesting testbed development,” Autonomous Agents and Multi-Agent Systems, vol. 2,
for the SODA methodology, highlighting some benefits as no. 3, pp. 251–269, Sep. 1999.
[8] “TuCSoN home page,” http://tucson.apice.unibo.it.
well as some limitations that we plan to address in the near [9] D. Gelernter, “Generative communication in Linda,” ACM Transactions
feature. In particular, the tabular representation is clearly more on Programming Languages and Systems, vol. 7, no. 1, pp. 80–112,
suitable for an automatic tool than for a human designer, due January 1985.
[10] D. Gelernter and N. Carriero, “Coordination languages and their signif-
to the large amount of tables to be filled in at each stage: so, icance,” Communications of the ACM, vol. 35, no. 2, pp. 97–107, Feb.
tools will be developed that support designers in this task in 1992.
a consistent and complete way. Another interesting extension [11] A. Omicini, “Towards a notion of agent coordination context,” in Process
could be the definition – or the adoption – of a language for Coordination and Ubiquitous Computing, D. C. Marinescu and C. Lee,
Eds. Boca Raton, FL, USA: CRC Press, Oct. 2002, ch. 12, pp. 187–200.
specifying SODA rules and interactions in a more precise [12] A. Molesini, E. Denti, and A. Omicini, “From AO methodologies
and formal way, overcoming the implicit limitations of the to MAS infrastructures: The SODA case study,” in Engineering
natural language which is currently adopted in the tabular Societies in the Agents World VIII, ser. LNCS, A. Artikis,
G. O’Hare, K. Stathis, and G. Vouros, Eds. Springer, Sep. 2008,
representation. We also plan to evaluate whether to enrich vol. 4995, pp. 300–317, 8th International Workshop (ESAW’07),
SODA with methods for the internal design of agents and 22–24 Oct. 2007, Athens, Greece. Revised Selected Papers. [Online].
artifacts—which are now uncovered, since SODA currently Available: http://www.springerlink.com/content/yh7x3253p4j535r9/
[13] A. Omicini, A. Ricci, and M. Viroli, “Artifacts in the
does not deal with intra-agent (and more generally with A&A meta-model for multi-agent systems,” Autonomous Agents
“internal”) issues. and Multi-Agent Systems, vol. 17, no. 3, pp. 432–456, Dec.
With respect to the simulation context discussed in this 2008, special Issue on Foundations, Advanced Topics and
Industrial Perspectives of Multi-Agent Systems. [Online]. Available:
paper, further work will be devoted to improve the prototype, http://www.springerlink.com/content/l2051h377k2plk07/
improving the simulation engine and adopting a better graphi- [14] ——, “Agens Faber: Toward a theory of artefacts for MAS,” ENTCSs,
cal rendering engine. More complex and intelligent behaviours vol. 150, no. 3, pp. 21–36, 29 May 2006.
[15] C. Sierra, J. A. Rodrı́guez-Aguilar, P. Noriega, M. Esteva, and J. L.
for soldiers could also be added, as well as user functionalities Arcos, “Engineering multi-agent systems as electronic institutions,”
for defining specific military strategies for each army. European Journal for the Informatics Professional, vol. 4, 2004.
[16] J. L. Arcos, J. A. Rodrı́guez-Aguilar, and B. Rosell, “Engineering au-
tonomic electronic institutions,” in Engineering Environment-Mediated
ACKNOWLEDGEMENTS Multi-Agent Systems, ser. LNCS, D. Weyns, S. A. Brueckner, and
Y. Demazeau, Eds., vol. 5049. Springer, 2008, pp. 76–87.
Authors would like to thank Dr. Alberto Mercati for his [17] J. Pavòn, C. Sansores, and J. J. Gòmez-Sanz, “Modelling and simulation
contribution to the project and his work on the prototype of social systems with ingenias,” Int. J. Agent-Oriented Softw. Eng.,
implementation. vol. 2, no. 2, pp. 196–221, 2008.
[18] J. Pavòn, J. J. Gòmez-Sanz, and R. Fuentes, “The INGENIAS
methodology and tools,” in Agent Oriented Methodologies,
R EFERENCES B. Henderson-Sellers and P. Giorgini, Eds. Hershey, PA, USA:
Idea Group Publishing, Jun. 2005, ch. IX, pp. 236–276. [Online].
[1] A. Drogoul and J. Ferber, “Multi-agent simulation as a tool Available: http://www.idea-group.com/books/details.asp?id=4931
for modeling societies: Application to social differentiation in ant [19] M. Röhl and A. Uhrmacher, “Controlled experimentation with agents
colonies,” in Selected papers from the 4th European Workshop on on - models and implementations,” in Engineering Societies in the Agents
Modelling Autonomous Agents in a Multi-Agent World, Artificial Social World V, ser. LNCS, M. P. Gleizes, A. Omicini, and F. Zambonelli, Eds.,
Systems. London, UK: Springer-Verlag, 1994, pp. 3–23. [Online]. vol. 3451. Springer, 2005, pp. 292–304.
Available: http://portal.acm.org/citation.cfm?id=646907.710638 [20] H. Sarjoughian, B. Zeigler, and S. Hall, “A layered modeling and sim-
ulation architecture for agent-based system development,” Proceedings
of the IEEE, vol. 89, no. 2, pp. 201–213, Feb 2001.
[21] G. Fortino, A. Garro, and W. Russo, “From modeling to simulation of
multi-agent systems: An integrated approach and a case study,” in Multi-
agent System Technologies, ser. LNCS, G. Lindemann, J. Denzinger, I. J.
Timm, and R. Unland, Eds., vol. 3187. Springer, 2004, pp. 213–227.
[22] ——, “An integrated approach for the development and validation of
multi-agent systems,” Comput. Syst. Sci. Eng., vol. 20, no. 4, 2005.
[23] F. Zambonelli, N. Jennings, and M. Wooldridge, “Multiagent systems as
computational organizations: the Gaia methodology,” in Agent Oriented
Methodologies, B. Henderson-Sellers and P. Giorgini, Eds. Hershey, PA,
USA: Idea Group Publishing, Jun. 2005, ch. VI, pp. 136–171. [Online].
Available: http://www.idea-group.com/books/details.asp?id=4931
[24] M. Cossentino, G. Fortino, A. Garro, S. Mascillaro, and W. Russo,
“Passim: a simulation-based process for the development of multi-agent
systems,” International Journal of Agent-Oriented Software Engineer-
ing, vol. 2, no. 2, pp. 132–170, 2008.
[25] M. Cossentino, “From requirements to code with the PASSI
methodology,” in Agent Oriented Methodologies, B. Henderson-Sellers
and P. Giorgini, Eds. Hershey, PA, USA: Idea Group Publishing,
Jun. 2005, ch. IV, pp. 79–106. [Online]. Available: http://www.idea-
group.com/books/details.asp?id=4931
[26] A. Garro and W. Russo, “easyabms: A domain-expert
oriented methodology for agent-based modeling and simula-
tion,” Simulation Modelling Practice and Theory, vol. 18,
no. 10, pp. 1453–1467, 2010, simulation-based Design
and Evaluation of Multi-Agent Systems. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1569190X10000717
[27] B. Henderson-Sellers and P. Giorgini, Eds., Agent Oriented Methodolo-
gies. Hershey, PA, USA: Idea Group Publishing, Jun. 2005. [Online].
Available: http://www.idea-group.com/books/details.asp?id=4931