Super Mario Soccer
Robocup Soccer Simulator 2D
Team Description Paper
David Saldaña1 , Ramon Melo, Anderson Tavares, Rafael Colares,
Levi Vasconcelos, Igor Campos, Elerson Rubens, Omar Pino, Hector Azpúrua.
Abstract— This paper describes the strategy of Super Mario
Soccer team for the 2014 edition of RoboCup Simulation 2D
soccer competition. Match situations are encoded in the states of
a finite state machine. Player actions depend on their state and
role. Roles are assigned according to soccer player functions
(e.g. center forward or defensive midfielder). We build from a
simple codebase that implements the communication protocol
with the simulation server, allowing us to focus on implementing
the team strategy. The simple approach based in finite state
machines will allow us to gain familiarity with the domain of
robot soccer in order to propose more sophisticated approaches
in the future.
Index Terms— Multi-robot systems, multiagent coordination,
robot soccer.
I. I NTRODUCTION
A robot soccer match involves coordination both in a
cooperative and an adversarial setting at the same time.
This happens because players of the same team must work
together in order to defend their own goal while attempting
to score against the opponent team. Also, the game is played
in real time in a continuous environment.
Agent coordination in complex scenarios is one of the
greatest challenges in multi agent systems. In general, a
complex scenario is composed of a set of agents that must
perform multiple tasks in a dynamic and partially observable
environment, where existing tasks can disappear and new
tasks can arrive. Robot soccer can be considered a complex
scenario and therefore, a rich domain for research in multiagent systems.
This paper describes strategies that guide Super Mario
Soccer team in the RoboCup Simulation 2D soccer competition. Basically, we adopt a behavior-based approach
where the player behavior is determined by its position (e.g.
defensive midfielder, center-forward) and the game situation
(e.g. opponent has the ball). This simpler approach will
enable us to familiarize with the robot soccer domain where
we will be able to build more sophisticated techniques in the
future.
This paper is organized as follows: Section II describes
the behavior-based strategy adopted by Super Mario Soccer
team. Section III describes the basic modules and technical
aspects of our implementation. Section IV presents concluding remarks and future work.
1 Computer Vision and Robotics Laboratory (VeRLab), Computer Science Department, Universidade Federal de Minas Gerais, MG, Brazil.
Corresponding author: [email protected]
II. S TRATEGY
A. Motivation
The player behavior is determined by its team role and the
match situation. The player role is defined by its assigned
position in the pitch. For example, in modern soccer, teams
usually distribute the ten line players in 4-4-2, 4-5-2 or
4-3-3 formations. In these formations, player roles usually
are: center back, side back, defensive midfielder (responsible
for destroying opponent plays), offensive midfielder (playmaker), center midfielder (midterm between offensive and
defensive), side attacker and center forward.
When the opponent has the ball, usually all team members
help in defense, but attackers and playmakers remain in
forward locations in the field, preparing for counter-attacks.
Defensive midfielders, center and side backs place themselves in suitable positions to recover the ball, marking the
opponent players and tackling the ball owner.
Conversely, while attacking, all team members move forward but center backs and defensive midfielders usually
retain backward positions to minimize a potential counter
attack from the opponent. Moreover, the behavior of the
player who has the ball must be different from the other
teammates. The ball owner has either to carry the ball
forward, to pass it to a better located teammate, or to shoot it
at the goal. Offensive players who don’t possess the ball must
get rid of marking opponents in order to create playmaking
opportunities.
This way of reasoning led us to model different behavioural patterns, one for each role. Those patterns differ
from each other in the way the possible actions are chosen,
for example: if a center back has the ball, it should pass to
an offensive team-mate rather then try to perform a dribble
maneuver. Each one will be explained in the forwarding
sections.
B. Action choice and execution
In our approach, a player chooses its actions based on the
observable match state together with its assigned role. An
agent perceives other agents, including teammates, as part
of the environment to which it has to react. However, as
action choices depend on the match situation and the player
behaviour, different actions will be taken by different players.
We expect that a coordinated team behaviour emerge from
those independent choices.
Player behaviour is encoded via a Finite State Machine.
Each state encodes the observable information of the environment available to the player agent, i.e., the match situation
as perceived by the player. Transitions between states are
based on significant facts that happen in the game, example:
if a player is in Defensive Position and the team recovers the
ball, it goes to Offensive Position. The player who gained
ball possession goes to Ball possession state. Although all
players implements finite state machines with the same states
and transitions, action execution is different according to the
player role.
Figure 1 illustrates the finite state machine to be implemented in our players. Defensive states are defensive position and tackling ball owner. Offensive states are offensive
position and with ball possession. This finite state machine
summarizes match situations in a high level of abstraction.
Fig. 1: Finite state machine for Super Mario Soccer players.
Defensive states are in green. Offensive states are in Red
The action to be executed in each state depends on the
player role. Player roles are: center back (CB), side back
(SB), defensive midfielder (DM), center midfielder (CM),
offensive midfielder (OM), side attacker (SA) and center
forward (CF). The list that follows shows player roles and
the actions that should be executed in each state of the finite
state machine of Fig. 1. Goal kicker is not listed because its
actions are simple: stay in goal when team has the ball and
block scoring attempts from opponents.
• Center Back
– With ball possession: Pass
– Offensive position: Mark opponent CF or SA
– Defensive position: Mark opponent CF or SA
– Tackling opponent: Intercept
• Side Back
– With ball possession: Pass or Dribble
– Offensive position: Ease playmaking
– Defensive position: Mark zone
– Tackling opponent: Intercept
• Defensive Midfielder
– With ball possession: Pass
– Offensive position: Mark opponent OM
– Defensive position: Mark opponent OM
– Tackling opponent: Intercept
• Center Midfielder
– With ball possession: Pass or Dribble
– Offensive position: Ease playmaking
– Defensive position: Mark zone
– Tackling opponent: Intercept
• Offensive Midfielder
– With ball possession: Pass, Dribble or Shoot
– Offensive position: Ease playmaking
– Defensive position: Mark zone
– Tackling opponent: Intercept
• Side Attacker
– With ball possession: Pass, Dribble or Shoot
– Offensive position: Ease playmaking
– Defensive position: Mark zone
– Tackling opponent: Intercept
• Center Forward
– With ball possession: Pass, Dribble or Shoot
– Offensive position: Ease playmaking
– Defensive position: Mark zone
– Tackling opponent: Intercept
Marking actions involve marking zone or specific opponent players. When marking zone, players cover an area
of the pitch. When a player marks a specific opponent, it
gets close to the opponent in order to reduce its available
space for offensive moves. Ease playmaking involves getting
rid of opponent marking. This could be done by moving
to less occupied pitch areas. Specifically for side backs,
this can be accomplished by advancing parallel to the side
line towards the opponent goal line. Intercept means to
move itself towards the ball trajectory, in order to catch
an opponent pass or towards the opponent ball owner, to
tackle him. Dribble action involves carrying the ball, trying
to deviate from opponents. Shooting refers to a score attempt
and pass refers to deliver the ball to a better placed teammate.
Implementation of these actions can be accomplished with
several techniques. For example, Ease playmaking could be
implemented with potential fields and Intercept could be
implemented with chase or interception algorithms.
III. F RAMEWORK
We are going to develop our codebase in a high level
programing language like Java or Python in order to reduce
development time. Therefore, we can focus on solving high
level problems like: agent coordination and cooperation;
strategies, role definition, etc. The initial code is based
in soccerpy[https://github.com/jasontbradshaw/soccerpy]. It
is implemented in Python and offers a simple team with
example code to follow the ball and kick. Our version defines
a open-source framework that is available for every new team
which wants to work with Python. Source code is available
at [https://github.com/dsaldana/soccerpy].
Figure 2 illustrates the framework modules, which are:
•
•
•
•
•
•
Agent: intelligence and role definition. It abstracts the
common behaviours for every agent, and allows to write
specific players.
Actions: high level actions based on primitive server
actions.
World: a world perception for the agent based on
observations. It must update in every iteration the agent
position, players and ball localizations.
Communication: all about UDP messages, parsers, and
sockets. It follows the message definitions of the server
manual.
Strategy: formations and tactics.
Utilities: it is a traversal module that offers useful
methods such as exception management or geometric
calculations, among others.
As a future work, we would like to adapt our framework to
support classic methodologies such as STP [1]. It offers effective strategies for our agents based in finite state machines
in adversarial multi-robot contests. STP consists of skills for
executing the low-level actions that make up robot behaviour,
tactics for determining what skills to execute, and plays for
coordinating synchronized activity among team members.
Another branch to be explored is to look at the problem as
a Markov Decision Process. Design the states as a finer representation of the environment and exploit Bellman’s equation
to help on the decision making process, maybe using reinforcement learning techniques to look for good policies to be
followed. Current approaches using reinforcement learning in
RoboCup soccer 2D need substantial number of matches to
achieve meaningful performance [2], where the calculations
are done after a goal is scored. A different approach using
in-game data could improve the efficiency of the learning
algorithm and minimize the time it takes to achieve a good
result.
R EFERENCES
[1] B. Browning, J. Bruce, M. Bowling, and M. Veloso, “STP: Skills,
tactics, and plays for multi-robot control in adversarial environments,”
Proceedings of the Institution of Mechanical Engineers, Part I: Journal
of Systems and Control Engineering, vol. 219, no. 1, pp. 33–52, 2005.
[2] J. A. Fabro, A. L. C. Botta, G. A. P. Parra, and J. R. F. Neri,
“The GPR-2D 2013 Team Description Paper: Reinforcement Learning
to Improve Attack decision-making and attack strategy modification
during a match.” 2013.
Fig. 2: Modules of the framework.
Under this structure, we do not need to worry about communication or computing world perceptions (e.g. position
of the agent based on observations or information fusion)
meanwhile the intelligence of the agent is being developed.
The agent module is the core where the intelligence must
be programmed. It has an abstraction of all the necessary
functions for initialization and structure creation. Every
player, such as center forward or defensive midfielder must
extend that generic agent.
IV. C ONCLUSION AND F UTURE W ORK
In this work, we presented the strategy of Super Mario
Soccer team for the 2014 edition of RoboCup Simulation
2D soccer competition. By encoding the match dynamics as
perceved by the player in a finite state machine, we simplify
decision making. Every player has a role assigned according
to its position (e.g.: side attacker or center back) in the pitch.
We describe a framework for a high level programming
language in order to define an efficient approach for automated soccer game play. Despite that this is the first approach
of our team on the RoboCup 2D soccer simulator, we intend
to improve our current work in several possible ways.