Flag Wars

---

• Introduction
  • • Source of inspiration
• The game
  • FlagWars as a game
    • General rules
    • Battle rules
  • FlagWars as a socio-technical system
• Analysis
  • Glossary
  • Core features of the game
    • Core concepts (Domain model)
      • The environment
      • Players
        • Virtual-player behaviour
    • Core mechanisms
      • Search
      • Battle
    • Interaction dimension
  • A first architecture of the system
  • AMUSE Platform and Abstraction Gap
    • A brief recap of the AMUSE Platform
    • Feasibility under AMUSE
• Design
  • Architecture of the system
  • The field
  • The player
  • The virtual player
  • Human player interface
    • Workflow of the app
    • The match
• Implementation notes and the prototype
  • • A FlagWars match screenshots
    • Future work
• Relevance for the Autonomous Systems course
  • On the autonomy of entities: the virtual player
• How to run the prototype

Introduction

This document represents the report of a project developed for the Autonomous Systems course with the aim of modeling and designing the core features of a game in order to exploit the concepts presented throghout the course.The game, called "FlagWars", is an online multiplayer game, variation of the well known multiplayer game "Capture the flag", with in addition the possibility of battles between teams during the research of the flag, and a socio-technical system, in which human players can join the match and play with both human and virtual player with no relevant difference.\ The development of this game is relevant in the scope of the Autonomous Systems Course not only because it gives us the opportunity to focus on concepts like autonomous entities, self-organisation, deliberation processes, the environment and the relationship of other entities with it, the interaction and the arising of emergent phenomena, but also because it lets us face the general issue of autonomy from the computational point of view.\ The design of virtual players as autonomous software entities is surely one of the most relevant part about the connections between the development of this game and the Autonomous System Course, but the links are not limited only to it, and so other and more specific details will be given explicitly in the following sections.

Source of inspiration

As mentioned, the game takes inspiration from well-known instances of the "capture-the-flag" game typology (like the famous multiplayer modality of Halo or Call of Duty) but gives it a new flavour with the possibility of strategic team battle during the conquest of the flag: one team can eliminate an enemy only if some of its components are in determined spatial configuration with respect to the enemy.\ So "FlagWars" takes also inspiration from the traditional strategy games, as the players have to dispose in some configurations in order to take an advantage in the conquest of the flag.\ Obviously, the title has been widely influenced by the famous "Star Wars" saga: every match can be imagined as a part of the long battle between Jedi and Sith in order to prevail.

The game

In this section the game and its requirements are presented and formalized, in order to gave a solid base for the analysis and design steps.\

FlagWars as a game

As every "capture the flag" game, the main purpose of the players is taking the flag to the base of the team they belong: in "FlagWars" the players don't know where the flag is in the map, so they have to to find it, and while doing it they can run into an enemy and start a battle to prevail and eliminate him from the match, in order to take an advantage over the other team.\ Below there is a more formal and specific description of FlagWars rules divided in rules of general interests and the ones related to the battles.

General rules

There are few but relevant general rules for this game, that point out the aim of the players and the way to win the match.

• There are two opponent teams, each composed by 10 players, inside an environment;
• there is an only flag that is collocated in the environment, and so obviously can be kept by at most only one player at a given time;
• the location of the flag is initially unknown;
• the aim of this game is to find the flag, capture it and then bring it to the base before the other team in order to win the match;
• when two or more components of distinct teams meet themselves, there is a battle;
• when there is a battle the components involved are blocked, unable to move until the end of conflict;
• the players die if lose the battle and therefore will disappear from the environment;
• the players are thus free to move in the environment except when they take part in a battle;
• two or more players can not be at same place at the same time;
• the players don't have a global vision of the environment, but a local perception by means of their sensory capacities;
• there's another chance to win, if all players of a team are eliminated the opponent team wins the game.

Battle rules

The battles are governed by a very little set of rules, based on the relative location of the players involved in the fight.

• A battle starts when one player meets another player of the opposing team;
• the spatial configuration that the players take is essential to win the battle;
• whenever a player is in combat with three adjacent players of the enemy team, he loses and is eliminated;

The following configurations represent examples of the victory of the "X" team and thus the elimination of the player "O":

1. 
2. 

All the possible configurations reduce to the ones presented above, by only rotating the figures.

FlagWars as a socio-technical system

FlagWars is meant to be a socio-technical game in which a human player interacts both with other human users and virtual users, like virtual autonomous players, without any difference: so a human user can replace a virtual player at any time, and vice-versa if a human user decides to leave the match.\ So a human player does not necessarily know if he is playing with humans or not.\ The social component, like for example challenging friends or play with them, is a very relevant component of this kind of games, so an optional requirement for this system can be the management of user informations and his "friendship" relationship with other players, giving the player a better user experience.\

Analysis

The analysis phase has a central role in the transposition of the game in a computational system, because it highlights the key charachteristics of the relevant entities and so it guides the mapping with computational and programming language related entities.

Glossary

Term	Definition
Player	Autonomous entity that takes part of game: it can be both human and virtual.
Team	A set of players that share the same goal; there are only two teams in this game.
Environment	The place at which the players are located during the game.
Flag	Artifact that is placed in a specific location, not known to players, of the environment at the beginning of the game; its retrieval is important to win the match.
Move/Action	A player can make an action after the perception of the environment, by means of this action he moves himself in another location.
Battle	Situation of the game that occurs when two or more players of different teams meet themselves.
Base	Portion of the environment that belongs to one team; each team has got one base.

Core features of the game

In this section the essential features of the game are extracted from the requirements in order to identify the core of the game, around which the design of the computational system can be built.\ The analysis of these features also gives us a first mapping between game related concepts and software / computational entities and features.

Core concepts (Domain model)

From a structural point of view, this game is essentially composed by two kind of entities:

• some players
• an environment

These two entities, the player and the environment, represent the domain model, and thus a first structural view of the system that we will analyse and will design.

The environment

The environment is one of the most important concepts for this game, as it is its "world", the only space in wich the players can move and that they can sense: essentialy it is a set of locations in which the players can be, one at a time.\ At a given time, some of the environment locations assume more importance than the others as they contains relevant elements for the game:

• the ones in which there are the basis for the teams, fixed at the beginning of the game and that can not change during the match;
• the one in which the flag is, decided at the beginning of the game and that can change throughout the course of the match as the players take the flag and try to bring it to their basis; it is important to note that the initial locations of the flag is unknown for the players, who have to find it by means of a "scent", a sort of trace left by the flag near its location;
• the ones in which a player resides: these locations are very important not only because a player can capture the flag only if he is in its same location, but also because the battle outcome is decided with respect to the relative positions of the contenders.

Therefore the environment for this game is an entity that stores all the relevant and essential information about the locations and gives the player the possibility to retrieve (perceive)them, letting them move and governing the match.\ So the environment can be seen as the field of a FlagWars match: it provides the essential feature of the situatedness to the system, as it is the place where the actions (of the players) are taken and have meaning.\ Furthermore it introduces also the reactivity feature, as it lets the entities reacts to some changes occured in it.

Players

The player is the other relevant concept for this game and, as we already have said, can be of two types: human or virtual.\ In general the essential features of a player for this game can be synthesized in:

• has a goal, as he wants his team to win the match (by bringing the flag to his basis or by eliminating all the enemies); a peculiarity of this game is that the players are grouped in teams, so a player's goal can be considered not only individual, but social as it concerns the victory or the defeat of the entire team;
• a player can sense the environment around him, retrieving information about its charachteristics as, for example sensing enemies or team mates around him: in this game a player has limitated sensory abilities, so he can not perceive all the environment but only a limited portion of it, specifically the one in his neighbourhood;
• a player can move in the environment;
• a player is capable to be involved in fights with enemies.

If these features can be enough for the design of a human player in the system, as these will be traduced in an user interface that lets the humans "drive" the player through apposite commands during the match, and the human takes the decision about what the player has to do, other charachteristics are needed for the design of a virtual player capable of entertaining the humans and give them the same "flavour" of challenging another human.\ A well-designed virtual player for FlagWars has to exhibit the following features in order to be considered acceptable to challenge a human during a match and giving him an entertaining and stimulating game experience:

• has to be non-deterministic, as its behaviour has not to be easily anticipated, so it has to deal with a certain level of randomness
• has to reason about the information that it can retrieve from the environment in order to make its move: in this way the virtual player can adopt behaviours in order to follow a certain goal (in this case, the victory of its team);
• has to cooperate with its team mates to achieve victory.

Virtual-player behaviour

Since we have already said that this game is a socio-technical system is necessary give a description of the virtual player's behaviour. For this purpose we make use of the activity diagram model.\ In brief, in the Unified Modeling Language (UML), activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the UML 2 the semantics of the activity diagrams are based on the Petri Nets' semantics. This diagram represents a description of a virtual-player's behaviour at an high level of abstraction.\The introduction of the probability is necessary in order to obtain stochastic behaviours of the virtual player. In this way we can obtain a non predictive behaviour of the single virtual player and more in general of the entire progress of game.\ At this point, with this considerations we can think at this game like a complex stochastic system, that is as a non-deterministic system.

Core mechanisms

A match essentially consists of the mutual interactions of these two kind of entities (players and environment). The game essentially proceed with a move of one player in the environment, but the core mechanisms are represented by the search and the battle.

Search

One of the key aspect of this game is represented by the search of the flag, that is initially located in an unknown location and is searchable by means of its scent left in the environment. This scent acts like an environment marker that partially drives the behaviour of the single player and of the entire team, or rather the individual and social behaviour of the players. This is very similar to the nature-inspired coordination model of the ant colonies, where the scent replaces their pheromones. The scent represents a simple form of stigmergy since is a coordination mechanism mediated by the environment.

Battle

A battle involves more sofisticated coordination between players in order to win, because the players not have the global vision of the environment but only a local perception.\ Since the player has a probabilistic behaviour, the system (in this case the result of a battle) cannot be predictable, and thus it is non-deterministic; we can model a virtual player in order to increase the probability of the cells around him with a team mate in battle, but this does not give us any predictive tool about its behaviour.\ The aim of the our model given to the virtual player is to view an emergent self-organisation of the team, useful to win the battles and the game: self-organisation that it is impossible to reduce at the single entity but it is a property of the whole team.

Interaction dimension

At this point with the considerations made previously we can view the whole system (the FlagWars system) as a collection of autonomous entities (the virtual players) and an environment that acts as a mediator for the interaction of these entities: the interaction dimension become in this way the fundamental one.\ Through the environment the players can communicate and coordinate themselves indirectly; coordination useful for reach the goal of win the match. The environment encapsulates a notion of locality, necessary to allow players to move through a topology. Moreover, it is active since its dynamic affects the coordination of the player; for example its role is crucial in the dynamic of the battle and in the research of the flag: without the scent left in the environment the player can not be able to find the latter.\ These features are fundamental for defining of this system as a complex system and to conceive its coordination model as one inspired by nature.\ The local interactions due to the coordination between players during the battle and the search of the flag will make arise emergent phenomena at the global level.

A first architecture of the system

The previous considerations lead to a first architecture for the entire system both from a behavioural point of view and from the interaction point of view, under the assumption, that basically lower the complexity of the game, that the game is turn-based, and only one player can make a move in a selected turn.The following UML diagram represents the behaviour of an entire match of FlagWars.As it is easy to note from the diagram, the game is essentially composed of a loop in which the player allowed to move is selected and the environment is updated after his move. When a team brings the flag to its basis, or its players have eliminated all the enemies, the match ends with a winner team.Furthermore, the game is composed by an interaction loop between the environment and the players, as basically explained by the following UML sequence diagram:Synthetically, the relevant interactions that compose the game loop are basically:

• the choice of the player for the turn;
• the move of a player, that has some consequences on the environment and modifies it

AMUSE Platform and Abstraction Gap

After this first analysis we have identified the main concepts present in FlagWars and it becomes important to find the mapping that permits us to implement this game as an online multiplayer game. This mapping, from the concepts to the available technologies, should be more direct than possible, in order to give us the possibility to focus on the main issues related to the autonomous systems.\ As we can understand from the rules of this game, a player is an autonomous entity that encapsulates its control logic, situated in an environment in which it can act and interact.\ These features brought us to model a virtual player as a software agent. In few words, a software agent is an autonomous computational entity which encapsulates its control along with a criterion to govern it. This is a mapping that minimizes the abstraction gap, since the agent paradigm provides suitable abstractions for each aspect so far introduced. In fact, the agent paradigm has abstractions like:

• agents for autonomy and encapsulation of behaviour
• situated agents for local actions and perceptions

In addition, in this game there are more than one player and we can view the whole system as a MAS (Multi-Agent Systems), where the coordination/interaction between the agents is mediated by the environment. Moreover, we can talk about these agents as goal-oriented agents because we have modeled their behaviour with the embedded will to win the game.Thus, we had to choose a framework/platform that could simplify the implementation of a multi-agent system and that could give us further abstractions to build multi-player on-line games, since this was our intention.\ With these latter remarks, we have choosen the AMUSE software platform with the aim to implement this game. Part of the goal of this project is to test if the AMUSE platform is a suitable tool to construct an artificial complex system with all the features listed in this analysis.

A brief recap of the AMUSE Platform

AMUSE (Agent-based Multi-User Social Environment) is a software platform that facilitates the development of distributed social applications involving users that cooperate/compete to achieve common or private goals. Within this scope the primary focus of Amuse is on multi player on-line games. Amuse is based on JADE and its extension WADE and is developed within the same Community. In the current version only Android-based games are supported.\ AMUSE offers a lot of fetures useful for social applications development, as:

• different kind of match Coordination (Peer-to-Peer or Centralized), based on the room / table metaphore
• user management (basic user profile info like credentials, avatar or statistics)
• text message exchange
• match management: dynamic player entry/exit towards the match
• other features as peer-to-peer pipe management or clock synchronization

AMUSE is a trademark of Telecom Italia SpA.

Feasibility under AMUSE

With reference to the tutorial available at the website of AMUSE we can see that this platform is fully written in Java, is available for the Android environment and is based on JADE (Java Agents DEvelopment framework) and WADE (Workflow and Agents Development Environment): thanks to that it offers a platform with which is possible to build a truly open and distributed system, as the network communications are made transparent by the platform.AMUSE is more than only a platform for software agents because it takes charge of issues like:

• match organization (provides the basic mechanisms to manage tables inside a room and to coordinate matches played on tables)
• managing player
• managing friends
• make sure that one player can move only when it is its turn
• and other...

These properties contribute to raise the level of the abstraction of this platform with respect to another agent-software platform (like JADE for example) and thus contributes to further reduce the abstraction gap.\JADE and WADE are trademarks of Telecom Italia SpA.So AMUSE has been chosen as the development environment for this project, as it offers many of the concepts needed for FlagWars both from a computational point of view, with the Agent and behaviour abstractions, and the socio-technical point of view, with the features for match organization and user management.

Design

This section describes the design of the game and the core features on which the first prototype is based.\ From the analysis phase it is clear that the system is developed above the AMUSE platform layer, so the following considerations are obviously guided by its main concepts.\ A remarkable considerations to take into account is that the game is turn-based and only one player can make a move during a turn: this facts influences the whole design of the system as it eases the development of the game.

Architecture of the system

From a design point of view, every FlagWars match can be seen a set of players (in our case, 20) that interact with the environment in a game-specific AMUSE table created in a room.\ A FlagWars match has the features of a centralized kind of match, so the whole system is designed following the client-server architecture, in which the players assume the role of clients interacting with the server platform.\ The following feature explicits the phase of joining the table created in the platform by the players, both humans (with their android devices) or virtual (software agents "running" on the server platform).\The following UML activity diagram (with some abuse of notations, as the server and clients actions are identified with relative tags) presents instead the system architecture from the behavioural point of view, giving a glance at the AMUSE API used and at the data structured exchanged between the agents.

The field

Thanks to the AMUSE platform it has been possible to reduce the gap in the realization of this part, since it provides some useful abstractions for the realization of several components. Such as the concept of the table, which allows you to model the game, its players and other many dynamics such as the management of their entry or exit from the game.The environment in this application has a central role since it works as a mediator for the interaction between the players. More precisely, by means of this latter the players can communicate and indirectly coordinate themselves, that is no information is directly exchanged between the players, but this information is revealed before in the environment and afterwards it is perceived by other players. The realized environment presents a particular structure with a notion of locality, thus allowing agents to move through a topology. This structure has been realized in our prototype using the Field class: the notion of locality has been modeled by a set of cells, represented by the FieldCell class, that are present in the Field. Each of these cells contains the information related to the environment of that particular area: the presence of the flag, the trace, and the player base. The following is a structural diagram which includes the fields and the main methods of these two entities that make up the structure of the environment.Moreover the environment of this prototype is an active component, with its own autonomous activities.\ This aspect is realized with the introduction of an agent represented by the FieldAgent class and here it is reported its activity diagram.\In few words, its workflow is characterized by a first part in which waits all the needed players and their positioning in the FieldCell's. After this, it sends to all players a special data structure that identifies the beginning of the game, containing all the information about the environment and the name of the first player, this is the player that plays the first turn of the game.\ Now begins a phase of direct interaction with the players: each player in turn after completing its move sends information (about its move) to the FieldAgent, the latter after updating the local Field of the displacement and possible eliminations of players, sends these updates to all players.\ This interaction continues until the flag is returned by a player in his own base or until a team lose all the players, in both these cases the Field Agent will inform all the players which team has won, and finally ends.\ The presence of the environment and all the introduced features lead to the definition of the coordination that there is in this prototype in one very similar to the coordination that there can be in nature. Moreover, the presence of the trace in the environment reinforces further the inspiration to nature. This trace (scent) facilitates the search of the flag and is very similar to the pheromone of the ant colonies: a special marker left and perceived in a distributed environment that can be exploited to issues of adaptability and self-organisation.Another important aspect is related to the model of action and perception of the agents which comes as a direct result from the modeling of the environment. In particular, the fact that we have given a certain topology to the world where players are immersed, characterized by the division of the environment in cells, leads to the birth of an agent's action: move from one area of the environment (in our case the cell) to another.\ We have modeled each cell with the information regarding the presence of the flag, the trace and the base of the team: this leads the agent to develop a perceptive ability in relation to this information. In other words, these are the information that represent the state of the environment and that can perceive the agent, in this way it can adapt its behavior in accordance with its goal.

The player

We can give a structural view of the generic player, both virtual than human, by means of a UML class diagram:\

The virtual player

In this section, we define in a more detailed manner a virtual-player agent, we emphasize its behavioural dimension because it gives us the possibility to explain the choices made about its:

• Reactivity
• Situatedness
• Pro-activeness
• Social ability

Since, a virtual-player is an agent capable of autonomous action and perception in the environment we can view this entity as a simple intelligent agent.\ Moreover, we have modeled this player as a stateless agent: any sort of action taken from it is based on the actual state (at the moment of perception) of the environment; the agent doesn't have any internal data structure to record the history of its actions or the history of the environment.Thus, here we introduce an activity diagram for better explaining the reasoning made, at each turn, by a virtual-player agent for choosing in which cell it want move. Remember that to describe the reasoning of the agent we don't use a state machine diagram because in our case it is a stateless agent.The activity diagram here reported represents a workflow, that is a sort of a precompiled plane, since the deliberation phase is absent because we have modeled the virtual-player with an implicit goal (the goal of win the match).\ Its practical reasoning, made after the perception of the environment, is related to the increments of probability of the cells: the agent gives a weight to the possible actions that it can accomplish. The model of the logic of move leads to realize, put in action, its potential intention (its goal).\ The perception is the agent’s ability to observe its environment and represents the knowledge that owns the agent, knowledge underlying the actions taken.This diagram also summarizes the main concepts about one virtual-player of the FlagWars game, explaining the situatedness of the agent on the field (that represents the environment) and giving an implicit modeling of the action and of the perception.\ Moreover, we can state that the virtual player is an agent reactive to the changes that occur in the environment and it is also proactive since it has an embedded goal of win the game and thus it will act in order to achieve it.The increments of probability TEAM_MATE, FLAG and TRACE have been defined as constants in order to facilitate the tuning of the agent's behaviour in phase of testing and because with the simple changes in the value of these constants we can modify the overall behaviour of the virtual player: for example, giving a considerable increment to the TRACE value we can probably view that its choices will be towards the scent of the flag, thus making the agent more a kind of TRACE-oriented one.\ "Trace" is another term that has the same meaning of "scent".The DecisionRules class summarizes these concepts:\After an increment of probability made for a cell is necessary an operation of renormalization of the distribution in order to maintain the sum of the probabilities of the distribution equal to 1.This virtual player agent has been implemented in the server side part of this prototype.\ Since AMUSE is the referential technology for this project this agent is a JADE agent and all the workflow here presented was realized using the behaviours.

Human player interface

The human user can play FlagWars by means of an AMUSE client developed for Android devices: in synthesis, it means an Android app that represents the entry point to the game.\ This part deserves some attention as FlagWars is a socio-technical system, and so even the human user and its interaction with the system have to be designed in order to satisfy the requirements and moreover make the game enjoyable.\ So this section describes the main consideration about the game user interface, under the assumption of playing it with an Android device (a smartphone or a tablet) and so making use of the abstractions that Android offers for app development.

Workflow of the app

The following UML Activity diagram represents the Workflow for the client application: the notes explain what Android activity is involved in the process, giving also a structural glance of the project.

The match

Using AMUSE to develop this app, the designer has the possibility to easily develop a very useful set of social features, as user info management, but surely the most important part is the match.\ Two different modalities of playing have been designed for this game:

• a normal mode in which the human user decides the move to do by touching the cell in which he wants to move his player (recognizable with a different image): the app accepts only a valid move before notifying it to the platform, otherwise the user has to choose another move;
• an auto mode in which the human user delegates the app to choose a move to do: in this way, the user is like a spectator of a simulation.

It is important to say that the human user has the possibility of choosing the modality he wants at every moment.\ For the first prototype the auto-mode is not so smart: it only takes casually a move between the valid ones.During the match, the user can see information about the moves in two ways, apart from seeing the player moving in the field:

• by some text in a label under the grid that represents the field
• by some text in a pop-up that notify the user of some remarkable events, as when a team win the match.

In conclusion, it is remarkable to say that a human user has the vision of all the field, in spite of the virtual agents that have only a local perception of it: this was necessary in the development phase to have a clear feedback about the virtual player agents behaviour, but a future version of this game can easily show only a local portion of the environment to the user, giving him the same "abilities" of the virtual players.

Implementation notes and the prototype

Using the AMUSE platform has been very helpful during the implementation of the protoytpe, as it manage for the programmers a lot of issues for a distributed and social system, so there are not many implementation notes.\ The source code for both the client and the server parts is available at the bitbucket repository https://bitbucket.org/smgrotti/flagwars_as1415. To implement the stocastic behaviour of the agent, we have in part used a Commons Math library from The Apache Software Foundation: "Commons Math is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language or Commons Lang."\ The link to their website is in the References section.

A FlagWars match screenshots

In conclusion some images of the game running are presented, as they can be useful to understand a little better the game dynamics as well as give a first glance of what a real release of FlagWars could be.\ All the image represents the game at its execution with the client app (running on an Android tablet).\ The first image is about the game in an initial phase: the cells with the "scent" of the flag are highlighted in orange, the "Jedi" players are green while the "Sith" are red, the user player is recognizable because it is represented with a different image (in this case, as the player is a Sith, a Darth Vader's one); the flag and the bases are highly recognizable by their icons.\ Then it is presented a sequence of a possible battle between players (which cells are highlighted in blue).\ At this moment, if another Jedi player moves in a cell adjacent the the other two Jedi that are fighting with the human player, and this cells is confining with the human player, it will be eliminated.\ An it is what it happens (non-deterministically!), as we can see from this image, taken a little after the previous one, where the human player has been eliminated and so he has disappeared from the field, leaving the flag on the field.\ Finally, there are presented the two possible outcome of a match, resulting in the victory of one team or another, depending on the course of actions taken by the players.\A victory of the Jedi team: the cells of a player with the flag is highlighted in yellow.\ A victory of the Sith team.\

Future work

Considered the feasibility of the project, there are many things that have to be done to realise a complete version of the game: here is a list of the main things:

• improve the graphical user interface;
• manage user information (profile, statistics, etc..) with AMUSE;
• manage friendship with AMUSE;
• manage the server side to handle many match at a time;
• upload the game to the amuse server;
• etc ..

Relevance for the Autonomous Systems course

As it is clear from the above sections that represents the whole development process of FlagWars, it can be considered relevant for the Autonomous Systems course from a wide range of point of view.\ Firstly, the whole FlagWars game can be conceive as a complex, self-organising and nature inspired system, as it has some features and draws inspiration from all this models.\ It is a complex system because it is made by many entities (the players) that interacts in a non-simple way.\ It can be considered a self-organising system as the simple interaction between the single lower-level entities (again, the players), mediated by the environment, drive to emergent properties at the level of the whole system that are not amenable to the single entities that compose the system: the battles between teams are one of these phenomena that arise as a result of the behaviour of the players, even if it is not so smart or skillful. In FlagWars the players re-organise when there are environment changes (for example a team mate has been eliminated), and so the system is robust to these kind of (wanted) "perturbations", at least until a certain threshold in the number of players is respected.\ Furthermore it is a nature inspired system as the core mechanism of searching the flag has been developed drawing inspiration from the model of stigmergy: inspired by the well known ant systems, the flag has its "scent" spread over the environment, and the players can sense it in order to know the direction in which the flag is. As the ants pheromone, this scent acts as a marker that partially drives the behaviour of the virtual agents. Like the ants, our virtual players seem to be not so smart or intelligent, they don't change their goal or make a very difficult reasoning, but their simple behaviour lead to a satisfiable organised one at the global level thanks also to their stochastic behaviour: in this way we can put into the game a level of non-determinism that is a way to model the agents possibility of "choice" at a certain level, making them non predictable and so not easily predictable by human players.\ Another good reason to consider this project relevant for the course is that it gives us the possibility of engineering an environment, making decisions about what feature have to be modeled in this sense: from the model of environment depends both the perceptions and the actions of the players.\ Last, but surely not least, this project gave us the chance to focus on the autonomy concepts by many point of view: with respect to the single entities or to the whole system, but also as a tool to develop complex and entertaining systems as a game can be, giving the developer the right abstractions to go through all the phases of the production process.\ For example, if the game (or better, a match) is conceived as a system, it can be considered partially autonomous with respect to its designer as it is fundamentally non-deterministic and, even if the programmer expects the system going through a variety of states, its behaviour cannot be predicted, and at the same time it is partially autonomous even also with respect to the human user that plays with it, because he can only move a player and so cannot decide the final outcome on his own.\ Furthermore, the two modalities that a human user can choose between to play with the app can be defined, according to military definitions, as:

• human operated, the normal mode, because the human operator makes all the decisions;
• human delegated, the auto mode, because when the human delegates the function of making a move to the system, the app takes the decision of moving the user's player.

On the autonomy of entities: the virtual player

The virtual player is surely the most important entity from the point of view of the course as it exhibits some features studied in the course like:

• it has to be autonomous from other players, as it cannot be invoked and not directly influenced by them;
• it has a goal, even if it is not explicitly represented inside of it, so it is at least a goal-oriented entity;
• it is a situated entity, so it deals with a a concept of locality;
• it is non deterministic, and so it assumes a stochastic behaviour;
• it has to perform some kind of reasoning after perceiving the environment in order to achieve a satisfying behaviour;
• it is capable of changing the enviroment by means of some actions.

But the most important question is "what kind of autonomy has the virtual player?":

• as a software agent, it surely is a computational autonomous entity, and so can be proactive as well as reactive;
• it is partially autonomous from the environment as its behaviour is guided by its perceptions of the environment, but not strictly coupled to it except in the battle case, when the player is forced to not move;
• it is partially autonomous with respect to the other players, as it is not directly influenced by them, but it has to wait for its turn in order to make a move;
• it has executive autonomy, as it is autonomous in perceiving the goal (not explicitly represented but given by the programmer);
• it has not motivational autonomy, as the agents goal is externally imposed by the programmer;
• it is proactive, as it "makes something happen on its own", but also reactive, and its reactivity does not imply a lack of autonomy.

How to run the prototype

The FlagWars prototype developed in this project with the AMUSE platform is divided in two part:

• a client app
• a server-side part containing the logic of the game

The client app is an apk that is ready to be installed in an Android device, while to run the server side logic is necessary install and setup the AMUSE development environment: the exact steps that must be executed to do that can be found in the AMUSE Startup Guide (this guide is available in the AMUSE website and the link to it can be found in the "References" section).\ After setting the platform as mentioned in Amuse Startup guide each time that we want play is need to:

• open a shell in wade-home/bin and type startBootDaemon;
• open a shell in wade-home/bin and type startMain amuse;
• open a shell in wade-home/add-ons/persistence/lib and type java -jar h2-1.2.123.jar to start h2 database where amuse platform will store data;
• run the server side eclipse project;
• run the client app in the Android device, and have fun!!!