Last update: Mar 25, 2024
4. Soccer Server
4.1. Objects
Fig. 4.1 UML diagram of the objects in the simulation
4.2. Protocols
4.2.1. Player Command Protocol
Connecting, reconnecting, and disconnecting
From player to server |
From server to client |
|---|---|
(init TeamName [(version VerNum )] [(goalie)])
TeamName ::= [+-_a-zA-Z0-9]+
VerNum ::= the protocol version (e.g. 15)
|
(init Side Unum PlayMode)
Side ::=
l | rUnum ::= 1~11
PlayMode ::= one of play modes
(error no_more_team_or_player_or_goalie)
|
(reconnect TeamName Unum)
TeamName := [+-_a-zA-Z0-9]+
|
(error Side PlayMode)
Side ::=
l | rUnum ::= 1~11
PlayMode ::= one of play modes
(error reconnect)
|
(bye) |
If your client connects or reconnects successfully with a protocol version >= 7.0, the
server will additionally send following messages: server_param (a message
containing the server parameters), player_param (a message containing the
player parameters) and player_type (a message containing the player types).
Finally, the player will receive a message on changed
players (see Sec. Heterogeneous Players).
Initial Settings
From player to server |
From server to player |
|---|---|
(compression Level)
Level ::= zlib compression level [0,9]
or negative number
|
(ok compression Level)
(warning compression_unsupported)
|
(clang (ver MinVer MaxVer))
MinVer ::= integer
MaxVer ::= integer
|
(ok clang (ver MinVer MaxVer)) |
(ear (OnOff [Team] [Type]))
OnOff ::=
on | offTeam ::=
our | opp |left | right |l | r |TeamName
|
no response if succeeded
(error no team with name TeamName)
|
(synch_see) |
(ok synch_see) |
(gaussian_see) |
(ok gaussian_see) |
Player Control
From player to server |
Only once per cycle |
|---|---|
(turn Moment)
Moment ::= minmoment ~ maxmoment degrees
|
Yes |
(dash Power [Direction])
(dash (l Power [Direction]) (r Power [Direction]))
(dash (r Power [Direction]) (l Power [Direction]))
(dash (l Power [Direction]))
(dash (r Power [Direction]))
Power ::= min_dash_power ~ max_dash_power
Direction ::= min_dash_angle ~ max_dash_angle degrees
Note: backward dash (negative power) consumes double stamina.
|
Yes |
(kick Power Direction)
Power ::= minpower ~ maxpower
Direction ::= minmoment ~ maxmoment degrees
|
Yes |
(tackle PowerOrAngle [Foul])
PowerOrAngle ::= minmoment ~ maxmoment degrees
: if client version >= 12
PowerOrAngle ::= -max_back_tackle_power ~ max_tackle_power
: if client version < 12
Foul ::=
true | false | on | off |
Yes |
(catch Direction)
Direction ::= minmoment ~ maxmoment degrees
|
Yes |
(move X Y)
X ::= real number
Y ::= real number
|
Yes |
(change_view [Width] Quality)
Width ::=
narrow | normal | wideQuality ::=
high | low |
No |
(say “Message”)
Message ::= [-0-9a-zA-Z ().+*/?<>_]*
|
No |
(pointto Distance Direction)
(pointto Off)
Distance ::= real number
Direction ::= real number degree
Off ::=
false | off |
No |
(attentionto Team Unum)
(attentionto Off)
Team ::=
our | opp |left | right |l | r |TeamName
Unum ::= integer
Off ::=
false | off |
No |
(done) |
Yes |
Others
From player to server |
From server to player |
|---|---|
(sense_body) |
sense_body message |
(score) |
(score Time Our Opp)
Time ::= simulation cycle of rcssserver
Our ::= sender’s team score
Opp ::= opponent team score
|
The server may respond to the above commands with the errors: (error unknown command) or (error illegal command form)
4.2.2. Player Sensor Protocol
The following table shows the protocol for client version 14 or later.
From server to player |
|---|
(hear Time Sender “Message”)
(hear Time OnlineCoach CoachLanguageMessage)
Time ::= simulation cycle of rcssserver
Sender ::=
online_coach_left | online_coach_right | coach | referee | self | DirectionDirection ::= -180 ~ 180 degrees
Message ::= string
OnlineCoach ::=
online_coach_left | online_coach_rightCoachLanguageMessage ::= see the standard coach language section
|
(see Time ObjInfo+)
Time ::= simulation cycle of rcssserver
ObjInfo ::=
(ObjName Distance Direction DistChange DirChange BodyFacingDir HeadFacingDir
[PointDir] [t] [k]])
| (ObjName Distance Direction DistChange DirChange [PointDir] [{t|k}])
| (ObjName Distance Direction [t] [k])
| (ObjName Diretion)
ObjName ::= (p [”TeamName” [UniformNumber [goalie]]])
| (b)
| (g {l|r})
| (f c)
| (f {l|c|r} {t|b})
| (f p {l|r} {t|c|b})
| (f g {l|r} {t|b})
| (f {l|r|t|b} 0)
| (f {t|b} {l|r} {10|20|30|40|50})
| (f {l|r} {t|b} {10|20|30})
| (l {l|r|t|b} 0)
| (P)
| (B)
| (G)
| (F)
Distance ::= positive real number
Direction ::= -180 ~ 180 degrees
DistChange ::= real number
DirChange ::= real number
BodyFacingDir ::= -180 ~ 180 degrees
HeadFacingDir ::= -180 ~ 180 degrees
PointDir ::= -180 ~ 180 degrees
TeamName ::= string
UniformNumber ::= 1 ~ 11
|
(sense_body Time
(view_mode {high|low} {narrow|normal|wide})
(stamina Stamina Effort Capacity)
(speed AmountOfSpeed DirectionOfSpeed)
(head_angle HeadAngle)
(kick KickCount)
(dash DashCount)
(turn TurnCount)
(say SayCount)
(turn_neck TurnNeckCount)
(catch CatchCount)
(move MoveCount)
(change_view ChangeViewCount)
(arm (movable MovableCycles) (expires ExpireCycles) (count PointtoCount))
(focus (target {none|{l|r} Unum}) (count AttentiontoCount))
(tackle (expires ExpireCycles) (count TackleCount))
(collision {none|[(ball)] [(player)] [(post)]})
(foul (charged FoulCycles) (card {red|yellow|none})))
|
(fullstate Time
(pmode {goalie_catch_ball_{l|r}|*PlayMode*})
(vmode {high|low} {narrow|normal|wide})
(count KickCount DashCount TurnCount CatchCount MoveCount TurnNeckCount ChangeViewCount SayCount)
(arm (movable MovableCycles) (expires ExpireCycles))
(target Distance Direction) (count PointtoCount)
(score Time Our Opp)
((b) X Y VelX VelY)
Players+)
Players ::= ((p {l|r} UniformNumber [g] PlayerType)
X Y VelX VelY BodyDir NeckDir [PointtoDist PointtoDir]
(stamina Stamina Effort Recovery Capacity)
[k|t|f] [r|y]))
|
4.3. Sensor Models
A RoboCup agent has three different sensors (and one special sensor). The aural sensor detects messages sent by the referee, the coaches and the other players. The visual sensor detects visual information about the field, like the distance and direction to objects in the player’s current field of view. The visual sensor also works as a proximity sensor by “seeing” objects that are close, but behind the player. The body sensor detects the current “physical” status of the player, like its stamina, speed and neck angle. Together the sensors give the agent quite a good picture of the environment.
4.3.1. Aural Sensor Model
Aural sensor messages are sent when a client or a coach sends a say command. The calls from the referee is also received as aural messages. All messages are received immediately.
The format of the aural sensor message from the soccer server is:
(hear Time Sender ‘’Message’’)
Time indicates the current time.
Sender is the relative direction to the sender if it is another player, otherwise it is one of the following:
self: when the sender is yourself.referee: when the sender is the referee.online_coach_leftoronline_coach_right: when the sender is one of the online coaches.
Message is the message. The maximum length is server::say_msg_size bytes. The possible messages from the referee are described in Section Play Modes and referee messages.
The server parameters that affects the aural sensor are described in Table 4.1.
Parameter in server.conf |
Value |
|---|---|
audio_cut_dist |
50.0 |
hear_max |
1 |
hear_inc |
1 |
hear_decay |
1 |
Capacity of the Aural Sensor
A player can only hear a message if the player’s hear capacity is at least server::hear_decay, since the hear capacity of the player is decreased by that number when a message is heard. Every cycle the hear capacity is increased with server::hear_inc. The maximum hear capacity is server::hear_max. To avoid a team from making the other team’s communication useless by overloading the channel the players have separate hear capacities for each team. With the current server.conf file this means that a player can hear at most one message from each team every second simulation cycle.
If more messages arrive at the same time than the player can hear, the messages
actually heard are chosen randomly.
This rule does not include messages from the referee, or messages from oneself.
From rcssserver 8.04, players can send attentionto commands to focus their attention on a particular player.
Focus
If the player focuses on player A from team T (AKA pTA), the player will hear one message selected randomly from the say messages issued by pTA in the previous cycle. If pTA did not issue any say commands, the player will hear one message selected randomly from all the say messages issued by players in team T. At the same time, the player will hear one message selected randomly from the other team. If attentionto is off (default) the player will hear one message from each team selected randomly from the messages available.
The way to focus is using attentionto commands.
See Attentionto Model in detail.
Range of Communication
A message said by a player is transmitted only to players within server::audio_cut_dist meters from that player. For example, a defender, who may be near his own goal, can hear a message from his goal-keeper but a striker who is near the opponent goal can not hear the message. Messages from the referee can be heard by all players.
Aural Sensor Example
This example should show which messages get through and how to calculated the hear capacity.
Example: Each coach sends a message every cycle. The referee send a message every cycle. The four players in the example all send a message every cycle. Show which messages gets through during 10 cycles (6 might be enough).
4.3.2. Vision Sensor Model
Basics
The visual sensor reports the objects currently seen by the player. The information is automatically sent to the player with the frequency determined by the player’s view width, view quality, and the synchronous/asynchronous mode. Furthermore, the server mixes noise into the information sent to the player. There are two types of noise models: the quantiazaiton model and the Gaussian model, and the default is the quantization model. Gaussian model was introduced from version 19
Visual information arrives from the server in the following basic format:
(see ObjName Distance Direction DistChng DirChng BodyDir HeadDir [t|k])
Distance, Direction, DistChng and DirChng are calculated in the following way:
where \((p_{xt},p_{yt})\) is the absolute position of the target object, \((p_{xo},p_{yo})\) is the absolute position of the sensing player, \((v_{xt},v_{yt})\) is the absolute velocity of the target object, \((v_{xo},v_{yo})\) is the absolute velocity of the sensing player, and \(a_o\) is the absolute direction the sensing player is facing. The absolute facing direction of a player is the sum of the BodyDir and the HeadDir of that player. In addition to it, \((p_{rx},p_{ry})\) and \((v_{rx},v_{ry})\) are respectively the relative position and the relative velocity of the target, and \((e_{rx},e_{ry})\) is the unit vector that is parallel to the vector of the relative position. BodyDir and HeadDir are only included if the observed object is a player, and is the body and head directions of the observed player relative to the body and head directions of the observing player. Thus, if both players have their bodies turned in the same direction, then BodyDir would be 0. The same goes for HeadDir.
The (goal r) object is interpreted as the center of the right hand side goalline. (f c) is a virtual flag at the center of the field. (f l b) is the flag at the lower left of the field. (f p l b) is a virtual flag at the lower right corner of the penalty box on the left side of the field. (f g l b) is a virtual flag marking the right goalpost on the left goal. The remaining types of flags are all located 5 meters outside the playing field. For example, (f t l 20) is 5 meters from the top sideline and 20 meters left from the center line. In the same way, (f r b 10) is 5 meters right of the right sideline and 10 meters below the center of the right goal. Also, (f b 0) is 5 meters below the midpoint of the bottom sideline.
In the case of (l …), Distance is the distance to the point where the center line of the player’s view crosses the line, and Direction is the direction of the line.
Currently there are 55 flags (the goals counts as flags) and 4 lines to be seen. All of the flags and lines are shown in Fig. 4.2.
Fig. 4.2 The flags and lines in the simulation.
In protocol versions 13+, when a player’s team is visible, their tackling and kicking state is also visible via t and k. If the player is tackling, t is present. If they are kicking, k is present instead. If an observed player is tackling, the kicking flag is always overwritten by the tackle flag. The kicking state is visible the cycle directly after kicking.
Asynchronous mode and Synchronous mode
There are two modes available for all players in in the vision sensor:
asynchronous mode and synchronous mode.
The asynchronous mode functions exactly like the default time step
in version 11 or older.
Until server version 17, asynchronous mode is the default mode for all
players.
Since version 18, synchrnonous mode is the default mode.
If v17 or older players wish to switch to synchronous mode, they have
to send the (synch_see) command.
Once they have switched to synchronous mode, they cannot return to
asynchronous mode.
In asynchronous mode, the information is automatically sent to the player every server::sense_step, currently 150, milliseconds, in the default setting. The frequency is changed according to the player’s view width and view quality. Please note that the message arrival timig is not synchronized with the simulation step interval.
In synchronous mode, players’ view quality is always set to ‘high’ and they cannot change their view quality. Instead of that, the message arrival timing of the visual information is automatically synchronized with the simulation step interval. The server executes the visual information transmission process server::synch_see_offset milliseconds after the simulation step update. The frequence is changed according to the player’s view width.
Range of View and View Frequency in Asynchronous mode
The visible sector of a player is dependant on several factors. In asynchronous mode, we have the server parameters server::sense_step and server::visible_angle which determines the basic time step between visual information and how many degrees the player’s normal view cone is. The default values in the asynchronous mode are 150 milliseconds and 90 degrees.
The player can also influence the frequency and quality of the information by changing ViewWidth and ViewQuality.
To calculate the current view frequency and view angle of the agent use equations (4.1) and (4.2).
where view_quality_factor is 1 if ViewQuality is high
and 0.5 if ViewQuality is low;
view_width_factor is 2 if ViewWidth is narrow,
1 if ViewWidth is normal, and 0.5 if ViewWidth is wide.
where view_width_factor is 0.5 if ViewWidth is narrow,
1 if ViewWidth is normal, and 2 if ViewWidth is wide.
The player can also “see” an object if it’s within server::visible_distance meters of the player. If the objects is within this distance but not in the view cone then the player can know only the type of the object (ball, player, goal or flag), but not the exact name of the object. Moreover, in this case, the capitalized name, that is “B”, “P”, “G” and “F”, is used as the name of the object rather than “b”, “p”, “g” and “f”.
Fig. 4.3 The visible range of an individual agent in the soccer server. The viewing agent is the one shown as two semi-circles. The light semi-circle is its front. The black circles represent objects in the world. Only objects within server::view_angle/2, and those within server::visible_distance of the viewing agent can be seen. unum_far_length, unum_too_far_length, team_far_length, and team_too_far_length affect the amount of precision with which a player’s identity is given. Taken from [Stone98].
The following example and Fig. 4.3 are taken from [Stone98].
The meaning of the view_angle parameter is illustrated in Fig. 4.3. In this figure, the viewing agent is the one shown as two semi-circles. The light semi-circle is its front. The black circles represent objects in the world. Only objects within \(view\_angle^\circ/2\), and those within visible_distance of the viewing agent can be seen. Thus, objects b and g are not visible; all of the rest are.
As object f is directly in front of the viewing agent, its angle would be reported as 0 degrees. Object e would be reported as being roughly \(-40^\circ\), while object d is at roughly \(20^\circ\).
Also illustrated in Fig. 4.3, the amount of information describing a player varies with how far away the player is. For nearby players, both the team and the uniform number of the player are reported. However, as distance increases, first the likelihood that the uniform number is visible decreases, and then even the team name may not be visible. It is assumed in the server that unum_far_length \(\leq\) unum_too_far_length \(\leq\) team_far_length \(\leq\) team_too_far_length. Let the player’s distance be dist. Then
If dist \(\leq\) unum_far_length, then both uniform number and team name are visible.
If unum_far_length \(<\) dist \(<\) unum_too_far_length, then the team name is always visible, but the probability that the uniform number is visible decreases linearly from 1 to 0 as dist increases.
If dist \(\geq\) unum_too_far_length, then the uniform number is not visible.
If dist :math`leq` team_far_length, then the team name is visible.
If team_far_length \(<\) dist \(<\) team_too_far_length, then the probability that the team name is visible decreases linearly from 1 to 0 as dist increases.
If dist \(\geq\) team_too_far_length, then the team name is not visible.
For example, in Fig. 4.3, assume that all of the labeled circles are players. Then player c would be identified by both team name and uniform number; player d by team name, and with about a 50% chance, uniform number; player e with about a 25% chance, just by team name, otherwise with neither; and player f would be identified simply as an anonymous player.
Parameter in |
Value |
|---|---|
server::sense_step |
150 |
server::visible_angle |
90.0 |
server::visible_distance |
3.0 |
server::quantize_step |
0.1 |
server::quantize_step_l |
0.01 |
Parameters in player_type |
Value |
|---|---|
unum_far_length |
20.0 |
unum_too_far_length |
40.0 |
team_far_length |
maximum_dist_in_pitch |
team_too_far_length |
maximum_dist_in_pitch |
player_max_observation_length |
maximum_dist_in_pitch |
ball_vel_far_length |
20 |
ball_vel_too_far_length |
40 |
ball_max_observation_length |
maximum_dist_in_pitch |
flag_chg_far_length |
20 |
flag_chg_too_far_length |
40 |
flag_max_observation_length |
maximum_dist_in_pitch |
Range of View and View Frequency in Synchronous mode
In synchronous mode, the “low” view quality is not available, and the view widths in Table 4.4 are available. In all view widths, rcssserver send see messages at server::synch_see_offset milliseconds from the beginning of the cycle.
The amount of information the player can receive changes depending on the distance to the target object, the same as in asynchronous mode.
mode |
view width(degree) |
see frequency |
|---|---|---|
narrow |
60 |
every cycle |
normal |
120 |
every 2 cycles |
wide |
180 |
every 3 cycles |
Focus Point
The focus point concept was developed in server version 18 to make observations in the game more closely resemble those made by human observers and camera lenses. The position of the focus point affects the observation noise model. In brief, the server introduces more noise to the distance of an observed object if the object is farther from the observer’s focus point.
The default position of the focus point is the player’s position. However,
the player can change the focus point by sending the
(change_focus DIST_MOMENT DIR_MOMENT) command.
It’s worth noting that the focus point cannot be outside the
player’s view angle, and its maximum distance from the player is 40.
This feature is available to players using version 18 or above on server versions 18 or above.
Visual Sensor Noise Model: Quantization
The quantizaiton noise model is the default mode for all players. In this mode, in order to introduce noise in the visual sensor data the values sent from the server is quantized. For example, the distance value of the object, in the case where the object in sight is a ball or a player, is quantized in the following manner:
where \((p_{xf},p_{yf})\) is the absolute position of the focus point of the observer, \((p_{xo},p_{yo})\) is the absolute position of the observer, \(d\) is the exact distance of the observer to the object, \(f\) and \(f'\) are the exact distance and quantized distance of the focus point to the object respectively, and \(d''\) is the result distance value sent to the observer. \(Quantize(V,Q)\) is as follow:
This means that players can not know the exact positions of very far objects. For example, when distance from the focus point is about 100.0 the maximum noise is about 10.0, while when distance is less than 10.0 the noise is less than 1.0.
In the case of lines, the distance value is quantized in the following manner.
Visual Sensor Noise Model: Gaussian
The Gaussian noise model has been introduced in server version 19.
Players can change their noise model by sending (gaussian_see)
command.
All version players can use this command.
If the command is accepted, rcssserver sent a reply message, (ok gaussian_see).
In this model, the noised distance in the player’s observation is determined by a Gaussian distribution:
where \(d\) is the exact distance from the observer to the object, \(f\) is the exact distance from the focus point to the object, and \(d'\) is the result distance value sent to the observer. \(NormalDistribution(mean,stddev)\) is a random number generator based on a Gaussian distribution with given mean and standard deviation. Therefore, the resulting value \(d'\) is generated from a Gaussian distribution with mean \(d'\) and standard deviation \(s\).
\(r_d\) and \(r_f\) are the noise rate parameter defined as heterogenious parameters. There are four parameters, dist_noise_rate, focus_dist_noise_rate, land_dist_noise_rate, and land_focus_dist_noise_rate. The former two paramters are used for movable object (ball and players), and the latter two paramters are used for landmark objects (flags and goals). In server version 19, all heterogeneous players use same values defined in server.conf (Table 4.5).
Parameters in player_type |
Value |
|---|---|
dist_noise_rate |
0.0125 |
focus_dist_noise_rate |
0.0125 |
land_dist_noise_rate |
0.00125 |
land_focus_dist_noise_rate |
0.00125 |
4.3.3. Body Sensor Model
The body sensor reports the current “physical” status of the player. he information is automatically sent to the player every server::sense_body_step, currently 100, milli-seconds.
The format of the body sensor message is:
(sense_body Time
(view_mode ViewQuality ViewWidth)
(stamina Stamina Effort Capacity)
(speed AmountOfSpeed DirectionOfSpeed)
(head_angle HeadAngle)
(kick KickCount)
(dash DashCount)
(turn TurnCount)
(say SayCount)
(turn_neck TurnNeckCount)
(catch CatchCount)
(move MoveCount)
(change_view ChangeViewCount)
(arm (movable MovableCycles) (expires ExpireCycles) (count PointtoCount))
(focus (target {none|{l|r} Unum}) (count AttentiontoCount))
(tackle (expires ExpireCycles) (count TackleCount))
(collision {none|[(ball)] [(player)] [(post)]})
(foul (charged FoulCycles) (card {red|yellow|none})))
(focus_point FocusDist FocusDir))
|
ViewQuality is one of
highandlow.ViewWidth is one of
narrow,normal, andwide.AmountOfSpeed is an approximation of the amount of the player’s speed.
DirectionOfSpeed is an approximation of the direction of the player’s speed.
HeadDirection is the relative direction of the player’s head.
*Count variables are the total number of commands of that type executed by the server. For example DashCount = 134 means that the player has executed 134 dash commands so far.
MovableCycles
ExpireCycles
FoulCycles
TODO: add descriptions about values. arm [8.03], focus [8.04], tackle [8.04], collision [12.0.0_pre-20071217], foul [14.0.0], focus_point [18.0.0] in NEWS
The semantics of the parameters are described where they are actually used. The ViewQuality and ViewWidth parameters are for example described in the Section Vision Sensor Model.
The server parameters that affects the body sensor are described in the following table:
Parameter in server.conf |
Value |
|---|---|
server::sense_body_step |
100 |
4.3.4. Fullstate Sensor Model
TODO
4.4. Movement Models
4.4.1. Basics
In each simulation step, movement of each object is calculated as following manner:
where, \((p_x^t,p_y^t)\), and \((v_x^t,v_y^t)\) are respectively position
and velocity of the object in timestep \(t\). decay is a decay parameter
specified by ball_decay or player_decay. \((a_x^t,a_y^t)\) is
acceleration of object, which is derived from Power parameter in dash
(in the case the object is a player) or kick (in the case of a ball)
commands in the following manner:
where \(\theta^t\) is the direction of the object in timestep \(t\) and
power_rate is dash_power_rate or is calculated from kick_power_rate
as described in Sec. Kick Model.
In the case of a player, this is just the direction the player is facing.
In the case of a ball, its direction is given as the following manner:
where \(\theta^t_{ball}\) and \(\theta^t_{kicker}\) are directions of ball and kicking player respectively, and Direction is the second parameter of a kick command.
4.4.2. Movement Noise Model
In order to reflect unexpected movements of objects in real world, rcssserver adds noise to the movement of objects and parameters of commands.
Concerned with movements, noise is added into Eqn.:ref:eq:u-t as follows: TODO: new noise model. See [12.0.0 pre-20071217] in NEWS
where \(\tilde{r}_{\mathrm rmax}\) is a random number whose distribution is uniform over the range \([-{\mathrm rmax},{\mathrm rmax}]\). \({\mathrm rmax}\) is a parameter that depends on amount of velocity of the object as follows:
where \({\mathrm rand}\) is a parameter specified by server::player_rand or server::ball_rand.
Noise is added also into the Power and Moment arguments of a command as follows:
4.4.3. Collision Model
Collision with other movable objects
If at the end of the simulation cycle, two objects overlap, then the objects are moved back until they do not overlap. Then the velocities are multiplied by -0.1. Note that it is possible for the ball to go through a player as long as the ball and the player never overlap at the end of the cycle.
Collision with goal posts
Goal posts are circular with a radius of 6cm and they are located at:
The goal posts have different collision dynamics than other objects. An object collides with a post if it’s path gets within object.size + 6cm of the center of the post. An object that collides with the post bounces off elastically.
4.5. Action Models
4.5.1. Catch Model
Fig. 4.4 Catchable area of the goalie when doing a (catch 45)
The goalie is the only player with the ability to catch a ball. The
goalie can catch the ball in play mode play_on in any direction,
if the ball is within the catchable area and the goalie is inside the
penalty area. If the goalie catches into direction \(\varphi\),
the catchable area is a rectangular area of length
server::catchable_area_l and width server::catchable_area_w in
direction \(\varphi\) (see Fig. 4.4).
The ball will be caught with probability
server::catch_probability, if it is inside this area (and it will
not be caught if it is outside this area).
For the current values of catch command parameters see Table 4.7:
Parameter in |
Value |
|---|---|
server::catchable_area_l |
2.0 |
server::catchable_area_w |
1.0 |
server::catch_probability |
1.0 |
server::catch_ban_cycle |
5 |
server::goalie_max_moves |
2 |
player::catchable_area_l_stretch_max |
1.3 |
player::catchable_area_l_stretch_min |
1 |
First time when goalie has been introduced in Soccer Simulation 2D was with server version 4.0.0: When a client connects the server with ‘(init TEAMNAME (goalie)’, the client becomes a goalies. The goalie can use ‘(catch DIR)’ command that enable to capture the ball.
With server version 4.0.2 another parameter named server::catch_probability has been introduced. This parameter represents the probability that a goalie succeed to catch the ball by a catch command. (default value: 1.0)
If the goalie successfully catches a ball it is moved adjacent to and facing the ball and both the goalie and ball have their velocities set to zero. When the goalie moves, dashes or turns while the ball is caught, the ball remains adjacent to and directly in front of the goalie.
The goalie can issue catch commands at any location. If the catch is successful, and the ball is outside of the penalty area or if the goalie moves the ball outside of the penalty area and it’s still in the field, an indirect free kick is awarded to the opposing team at the ball’s current location. If a caught ball is moved over the goal line but not inside the goal, a corner kick is awarded. If a caught ball is moved into the goal, a goal is awarded.
Later, in server version 14.0.0 a heterogeneous goalie has been introduced. Beginning with this version online coaches can change the player type of goalie. The ‘catchable_area_l_stretch’ variable was added to each heterogeneous player type through two new parameters: player::catchable_area_l_stretch_min (default value: 1.0) and player::catchable_area_l_stretch_max (default value: 1.3)
The following pseudo code shows a trade-off rule of the catch model:
// catchable_area_l_stretch is the heterogeneous parameter, currenlty within [1.0,1.3]
double this_catchable_are_delta = server::catchable_area_l * (catchable_area_l_stretch - 1.0)
double this_catchable_area_l_max = server::catchable_area_l + this_catchable_are_delta
double this_catchable_area_l_min = server::catchable_area_l - this_catchable_are_delta
if (ball_pos is inside the MINIMAL catch area)
{
// the MINIMAL catch area has a length of this_catchable_area_l_min and width server::catchable_area_w goalie
// catches the ball with probability server::catch_probability (which is 1.0 by default)
}
else if (ball_pos is beyond the MAXIMAL (stretched) area)
{
// the MAXIMAL catch area has a length of this_catchable_area_l_max and width server::catchable_area_w goalie
// definitely misses the ball
}
else
{
double ball_relative_x = (ball_pos - goalie_pos).rotate(-(goalie_body + catch_dir)).x
double catch_prob = server::catch_probability
- server::catch_probability
* (ball_relative_x - this_catchable_area_l_min)
/ (this_catchable_area_l_max - this_catchable_area_l_min)
// goalie catches the ball with probability catch_prob it holds: catch_prob is in [0.0,1.0]
}
If a catch command was unsuccessful, it takes server::catch_ban_cycle cycles until another catch command can be used (catch commands during this time have simply no effect).
If the goalie succeeded in catching the ball, the play mode will change to goalie_catch_ball_[l|r] first and free_kick_[l|r], after that during the same cycle.
Once the goalie caught the ball, it can use the move command to move with the ball inside the penalty area.
The goalie can use the move command server::goalie_max_moves times before it kicks the ball.
Additional move commands do not have any effect and the server will respond with (error too_many_moves).
Please note that catching the ball, moving around, kicking the ball a short distance and immediately catching it again to move more than server::goalie_max_moves times is considered as ungentlemanly play.
Starting with server version 15.0.0 an improvement of the catch model has been introduced:
If goalie fails to catch the ball beyond the fuzzy catchable area, the ball has no effect. (same as the previous model)
If goalie fails to catch the ball within a fuzzy catchable area, the ball is accelerated to the catch command direction. (it is similar to the ball bouncing from the wall that the normal vector’s direction is same as the catch command direction)
4.5.2. Dash Model
The dash command is used to accelerate the player in direction of
its body.
dash takes the acceleration power as a parameter.
The valid range for the acceleration power can be configured in
server.conf, the respective parameters are server::min_dash_power
and server::max_dash_power.
For the current values of parameters for the dash model, see
the following table:
Default Parameters
server.conf |
Default Value (Range)
|
Heterogeneous Player Parameters
player.conf |
Value
|
|---|---|---|---|
server::min_dash_power |
-100.0 |
||
server::max_dash_power |
100.0 |
||
server::player_decay server::inertia_moment |
0.4 ([0.3, 0.5])
5.0 ([2.5, 7.5])
|
player::player_decay_delta_min
player::player_decay_delta_max
player::inertia_moment_delta_factor
|
-0.1
0.1
25.0
|
server::player_accel_max |
1.0 |
||
server::player_rand |
0.1 |
||
server::player_speed_max |
1.05 |
||
server::player_speed_max_min |
0.75 |
||
server::stamina_max |
8000.0 |
||
server::stamina_capacity |
130600.0 |
||
server::stamina_inc_max
server::dash_power_rate
|
45.0 ([40.2, 52.2])
0.006 ([0.0048, 0.0068])
|
player::new_dash_power_rate_delta_min
player::new_dash_power_rate_delta_max
player::new_stamina_inc_max_delta_factor
|
-0.0012
0.0008
-6000
|
server::extra_stamina
server::effort_init
server::effort_min
|
50.0 ([50.0, 100.0])
1.0 ([0.8, 1.0])
0.6 ([0.4, 0.6])
|
player::extra_stamina_delta_min
player::extra_stamina_delta_max
player::effort_max_delta_factor
player::effort_min_delta_factor
|
0.0
50.0
-0.004
-0.004
|
server::effort_dec |
0.3 |
||
server::effort_dec_thr |
0.005 |
||
server::effort_inc |
0.01 |
||
server::effort_inc_thr |
0.6 |
||
server::recover_dec_thr |
0.3 |
||
server::recover_dec |
0.002 |
||
server::recover_init |
1.0 |
||
server::recover_min |
0.5 |
||
server::wind_ang |
0.0 |
||
server::wind_dir |
0.0 |
||
server::wind_force |
0.0 |
||
server::wind_rand |
0.0 |
Each player has a certain amount of stamina that will be consumed by dash commands. At the beginning of each half, the stamina of a player is set to server::stamina_max. If a player accelerates forward (\(power> 0\)), stamina is reduced by power. Accelerating backwards (\(power< 0\)) is more expensive for the player: stamina is reduced by \(-2 \times power\). If the player’s stamina is lower than the power needed for the dash, power is reduced so that the dash command does not need more stamina than available. Some extra stamina can be used every time the available power is lower than the needed stamina. The amount of extra stamina depends on the player type and the parameters player::extra_stamina_delta_min and player::extra_stamina_delta_max.
After reducing the stamina, the server calculates the effective dash power for the dash command. The effective dash power edp depends on the dash_power_rate and the current effort of the player. The effort of a player is a value between effort_min and effort_max; it is dependent on the stamina management of the player (see below).
edp and the players current body direction are tranformed into vector and added to the players current acceleration vector \(\vec{a}_n\) (usually, that should be 0 before, since a player cannot dash more than once a cycle and a player does not get accelerated by other means than dashing).
At the transition from simulation step \(n\) to simulation step \(n + 1\), acceleration \(\vec{a}_n\) is applied: TODO: dash speed restriction. See [12.0.0_pre-20071217]
\(\vec{a}_n\) is normalized to a maximum length of server::player_accel_max.
\(\vec{a}_n\) is added to current players speed \(\vec{v}_n\). \(\vec{v}_n\) will be normalized to a maximum length of player_speed_max. players, the maximum speed is a value between server::player_speed_max + player::player_speed_max_delta_min and server::player_speed_max + player::player_speed_max_delta_max in
player.conf.Noise \(\vec{n}\) and wind \(\vec{w}\) will be added to \(\vec{v}_{n}\). Both noise and wind are configurable in server.conf. Parameters responsible for the wind are server::wind_force, server::wind_dir and server::wind_rand. With the current settings, there is no wind on the simulated soccer field. The responsible parameter for the noise is server::player_rand. Both direction and length of the noise vector are within the interval \([ -|\vec{v}_{n}| \cdot {\mathrm player\_rand} \ldots |\vec{v}_{n}| \cdot {\mathrm player\_rand}]\).
The new position of the player \(\vec{p}_{n+1}\) is the old position \(\vec{p}_{n}\) plus the velocity vector \(\vec{v}_{n}\) (i.e.the maximum distance difference for the player between two simulation steps is player_speed_max).
player_decay is applied for the velocity of the player: \(\vec{v}_{n+1} = \vec{v}_{n} \cdot {\mathrm player\_decay}\). Acceleration \(\vec{a}_{n+1}\) is set to zero.
Sideward and Omni-Directional Dashes
Besides the forward and backward dashes that were already described in the previous section, since version 13 the Soccer Server also supports the possibility to perform sideward and even omni-directional dashes. In addition to the already known parameter of the dash(x) command where \(x\in[-100,100]\) determines the relativ strength of the dash (with negative sign indicating a backward dash), the omni-directional dash model uses two parameters to the dash command:
where \(power\) determines the relative strength of the dash
and \(dir\) represents the direction of the dash accelaration
relative to the player’s body
angle. The format in which the command needs to be sent to the Soccer Server
is (dash <power> <dir>).
If a negative value is used for \(power\), then the reverse side angle
of \(dir\)
will be used. Practically, the direction of the dash is restricted to by the
corresponding Soccer Server parameters to
The effective power of the dash command is determined by the absolute value
of the dash direction. Players will always dash with full effective power
(100%) alongside their current body orientation, i.e. when using a zero
direction angle as described in the preceding section.
Two further Soccer Server parameters, server::side_dash_rate
and server::back_dash_rate, determine the
effective power that is applied when a non-straight dash is performed.
Thus, for example, strafing movements (90 degrees left/right to the player) will be performed with 40% of effective power, whereas backward dashes will performed with 60% (according to current Soccer Server parameter default values). For values between these four main directions a linear interpolation of the effective power will be applied. The following formula explains the maths behind the sideward dash model.
As discussed in the description of the forward/backward dash model in the
preceding section, there exists the server parameter
server::min_dash_power which determines the highest minimal value
that can be used for the first parameter \(power\) of the dash command.
It is expected that
this parameter will be set to zero in future versions of the Soccer Server,
while, for reasons of compatibility with older team binaries, its default value
of -100 is encouraged currently.
Finally, the parameter server::dash_angle_step allows for a finer
discreteness
of players’ dash directions. If this value is set to 90.0 degrees, players are
allowed to dash into the four main directions, for a setting of 45.0 we
arrive at eight different directions. Setting this parameter to 1.0,
the Soccer Server is capable of emulating an omnidirectional movement
model as it is commen, for example, in the MidSize League.
The following table summarizes all Soccer Server parameters that are of relevance for omni-directional dashing.
Default Parameters
server.conf |
Default Value (Range)
|
Heterogeneous Player Parameters
player.conf |
Value
|
|---|---|---|---|
server::server::max_dash_angle |
180.0 |
||
server::server::min_dash_angle |
-180.0 |
||
server::side_dash_rate |
0.4 |
||
server::back_dash_rate |
0.6 |
||
server::dash_angle_step |
1 |
Bipedal Dash Model
Since rcssserver version 19, a bipedal dash model has been introduced. In the bipedal model, players can independently issue dash commands to the left and right legs. This means that players can now apply different accelerations to each leg. With the bipedal dash model, players can perform acceleration and direction changes simultaneously. The bipedal dash model is based on the differential drive dynamics model used in two-wheeled mobile robots and is available regardless of the client version.
In the bipedal dash model, parameters can be independently assigned to each leg using the dash command. The parameters, namely power and direction, are the same as the dash command in versions 18 and earlier. The derivation formula for acceleration obtained for each leg also follows the conventional model. The differences from the conventional model lie in the stamina consumption, the derivation formula for the player’s body acceleration obtained as a result, and the player’s rotation based on the speed difference between both legs.
Stamina consumed by each leg is half of the conventional model.
The overall stamina consumption is the sum of stamina consumption for both legs.
In other words, when the same power is applied to both legs (dash (l power dir) (r power dir)),
the stamina consumption is the same as applying that power to both legs in the conventional model (dash power dir).
The dash command can be issued not only simultaneously to both legs but also separately. Even if the dash command is issued separately, as long as a dash command has been issued to both legs by the time of the cycle update, the same effect as issuing simultaneously can be achieved. If the dash command is issued to only one leg, rotation of the player does not occur, and acceleration is obtained solely from the individual leg.
Based on the given command parameters, velocity is first derived for each leg. This derivation formula is the same as the conventional model. Provisional accelerations \(\hat{a}_L\) and \(\hat{a}_R\) are independently calculated for each leg. Next, the current player velocity \(v_t\) and the provisional velocities \(\hat{v}_L\) and \(\hat{v}_R\) for each leg are obtained from the provisional accelerations. The provisional velocity \(\hat{v}^{t+1}\) for the player’s body is then determined by the average of \(\hat{v}_L\) and \(\hat{v}_R\). The player’s body acceleration \(a^t\) is reverse-calculated from the difference between \(\hat{v}^{t+1}\) and \(v^t\). Noise is added according to the update formula in section Movement Models, and the velocity for the next step, \(v{t+1}\), is updated.
When dash parameters are assigned to both legs and there is a difference in the velocity component of each leg in the body direction, the player rotates based on that speed difference. The rotation equation is identical to the differential drive kinematics.
where \(\omega\) is the angular velocity, and \(b\) is the width between wheels (=player_size x 2).
Stamina Model
For the stamina of a player, there are three important variables: the
stamina value, recovery and effort.
stamina is decreased when dashing and gets replenished slightly each
cycle. recovery is responsible for how much the stamina recovers
each cycle, and the effort says how effective dashing is (see
section above).
Important parameters for the stamina model are changeable in the files
server.conf and player.conf.
Basically, the algorithm shown in the following code block says that
every simulation step the stamina is below some threshold, effort or
recovery are reduced until a minimum is reached.
Every step the stamina of the player is above some threshold, effort
is increased up to a maximum.
The recovery value is only reset to 1.0 each half, but it will not
be increased during a game.
# if stamina is below recovery decrement threshold, recovery is reduced
if stamina <= recover_dec_thr * stamina_max
if recovery > recover_min
recovery = recovery - recover_dec
# if stamina is below effort decrement threshold, effort is reduced
if stamina <= effort_dec_thr * stamina_max
if effort > effort_min
effort = effort - effort_dec
effort = max(effort, effort_min)
# if stamina is above effort increment threshold, effort is increased
if stamina >= effort_inc_thr * stamina\_max
if effort < effort_max
effort = effort + effort_inc
effort = min(effort, effort_max)
# recover the stamina a bit
stamina_inc = recovery * stamina_inc_max
stamina = min(stamina + stamina_inc, stamina_max)
In rcssserver version 13 or later, the stamina_capacity variable
has been implemented as one of the player’s stamina models in addition to the above
three stamina variables.
stamina_capacity is defined as the maximum recovery capacity of each player’s stamina.
When a player’s stamina is recovered during a game, the same amount of stamina is also consumed from one’s stamina_capacity.
Once the player’s stamina_capacity becomes 0, one’s stamina is never recovered and the only extra_stamina is consumed instead of the normal stamina.
The updated algorithm is shown in the following code block.
stamina_inc can be available from the previous code block.
# stamina_inc is restricted by the residual capacity
if stamina_capacity >= 0.0
if stamina_inc > stamina_capacity
stamina_inc = stamina_capacity
stamina = min(stamina + stamina_inc, stamina_max)
# stamina capacity is reduced as the same amount as stamina_inc
if stamina_capacity >= 0.0
stamina_capacity = max(0.0, stamina_capacity - stamina_inc)
stamina_capacity is reset to the initial value just after the kick-off of normal halves as well as the other stamina-related variables. However, stamina_capacity is never recovered at the half time of extra-inning games and before the penalty shootouts. The stamina_capacity is defined as one of the parameters of rcssserver server::stamina_capacity (the default value of stamina_capacity is 130600 as of rcsserver version 16.0.0). If server::stamina_capacity is set to a negative value, each player has an infinite stamina capacity. This setting makes the stamina-model including stamina_capacity completely the same with the stamina model before rcssserver version 13. stamina_capacity information is received as the following sense_body message:
(stamina <STAMINA> <EFFORT> <CAPACITY>)
4.5.3. Kick Model
The kick command takes two parameters, the kick power the player client wants to use (between server::minpower and server::maxpower) and the angle the player kicks the ball to. The angle is given in degrees and has to be between server::minmoment and server::maxmoment (see Table 4.10 for current parameter values).
Once the kick command arrived at the server, the kick will be executed if the ball is kick-able for the player and the player is not marked offside. The ball is kick-able for the player, if the distance between the player and the ball is between 0 and kickable_margin. Heterogeneous players can have different kickable margins. For the calculation of the distance during this section, it is important to know that if we talk of distance between player and ball, we talk about the minimal distance between the outer shape of both player and ball. So the distance in this section is the distance between the center of both objects minus the radius of the ball minus the radius of the player.
The first thing to be calculated for the kick is the effective kick power ep:
If the ball is not directly in front of the player, the effective kick power will be reduced by a certain amount dependent on the position of the ball with respect to the player. Both angle and distance are important.
If the relative angle of the ball is \(0^\circ\) wrt. the body direction of the player client - i.e. the ball is in front of the player - the effective power will stay as it is. The larger the angle gets, the more the effective power will be reduced. The worst case is if the ball is lying behind the player (angle \(180^\circ\)): the effective power is reduced by 25%.
The second important variable for the effective kick power is the distance from the ball to the player: it is quite obvious that - should the kick be executed - the distance between ball and player is between 0 and player’s kickable margin. If the distance is 0, the effective kick power will not be reduced again. The further the ball is away from the player client, the more the effective kick power will be reduced. If the ball distance is player’s kickable margin, the effective kick power will be reduced by 25% of the original kick power.
The overall worst case for kicking the ball is if a player kicks a distant ball behind itself: 50% of kick power will be used. For the effective kick power, we get the formula (4.8). (dir diff means the absolute direction difference between ball and the player’s body direction, dist diff means the absolute distance between ball and player.) \(0\le\mathrm{dir\_diff}\le180^\circ\land0\le\mathrm{dist\_diff}\le\mathrm{kickable\_margin}\)
The effective kick power is used to calculate \(\vec{a}_{{n}_{i}}\), an acceleration vector that will be added to the global ball acceleration \(\vec{a}_{n}\) during cycle \(n\) (remember that we have a multi agent system and each player close to the ball can kick it during the same cycle).
There is a server parameter, server::kick_rand, that can be used to
generate some noise to the ball acceleration.
For the default players, kick_rand is 0.1.
For heterogeneous players, kick_rand depends on
player::kick_rand_delta_factor in player.conf and on the
actual kickable margin.
.. In RoboCup 2000, kick_rand was used to generate some noise during evaluation round for the normal players.
TODO: new kick/tackle noise model. See [12.0.0 pre-20080210] in NEWS
TODO: heterogeneous kick power rate. See [14.0.0] in NEWS
During the transition from simulation step \(n\) to simulation step \(n+1\) acceleration \(\vec{a}_{n}\) is applied:
\(\vec{a}_{n}\) is normalized to a maximum length of server::ball_accel_max.
\(\vec{a}_{n}\) is added to the current ball speed \(\vec{v}_{n}\). \(\vec{v}_{n}\) will be normalized to a maximum length of server::ball_speed_max.
Noise \(\vec{n}\) and wind \(\vec{w}\) will be added to \(\vec{v}_{n}\). Both noise and wind are configurable in
server.conf. The responsible parameter for the noise is server::ball_rand. Both direction and length of the noise vector are within the interval \([ -|\vec{v}_{n}| \cdot \mathrm{ball\_rand} \ldots |\vec{v}_{n}| \cdot \mathrm{ball\_rand}]`\). Parameters responsible for the wind are server::wind_force, server::wind_dir and server::wind_rand.The new position of the ball \(\vec{p}_{n+1}\) is the old position \(\vec{p}_{n}\) plus the velocity vector \(\vec{v}_{n}\) (i.e. the maximum distance difference for the ball between two simulation steps is server::ball_speed_max).
server::ball_decay is applied for the velocity of the ball: \(\vec{v}_{n+1} = \vec{v}_{n} \cdot \mathrm{ball\_decay}\). Acceleration \(\vec{a}_{n+1}\) is set to zero.
With the current settings the ball covers a distance up to 50, assuming an optimal kick. 55 cycles after an optimal kick, the distance from the kick off position to the ball is about 48, the remaining velocity is smaller than 0.1. 18 cycles after an optimal kick, the ball covers a distance of 34 - 34 and the remaining veloctity is slightly smaller than 1.
Implications from the kick model and the current parameter settings are that it still might be helpful to use several small kicks for a compound kick – for example stopping the ball, kick it to a more advantageous position within the kickable area and kick it to the desired direction. It would be another possibility to accelerate the ball to maximum speed without putting it to relative position (0,0{textdegree}) using a compound kick.
Default Parameters
server.conf |
Default Value (Range)
|
Heterogeneous Player Parameters
player.conf |
Value
|
|---|---|---|---|
server::minpower |
-100 |
||
server::maxpower |
100 |
||
server::minmoment |
-180 |
||
server::maxmoment |
180 |
||
server::kickable_margin |
0.7 ([0.6, 0.8]) |
player::kickable_margin_delta_min
player::kickable_margin_delta_max
|
-0.1 0.1 |
server::kick_power_rate |
0.027 |
||
server::kick_rand |
0.1 ([0.0, 0.2]) |
player::kick_rand_delta_factor
player::kickable_margin_delta_min
player::kickable_margin_delta_max
|
1 -0.1 0.1 |
server::ball_size |
0.085 |
||
server::ball_decay |
0.94 |
||
server::ball_rand |
0.05 |
||
server::ball_speed_max |
3.0 |
||
server::ball_accel_max |
2.7 |
||
server::wind_force |
0.0 |
||
server::wind_dir |
0.0 |
||
server::wind_rand |
0.0 |
4.5.4. Move Model
The move command can be used to place a player directly onto a desired position on the field. move exists to set up the team and does not work during normal play. It is available at the beginning of each half (play mode before_kick_off’) and after a goal has been scored (play modes goal_l_? or goal_r_? ’). In these situations, players can be placed on any position in their own half (i.e. X < 0) and can be moved any number of times, as long as the play mode does not change. Players moved to a position on the opponent half will be set to a random position on their own side by the server.
A second purpose of the move command is to move the goalie within the penalty area after the goalie caught the ball. If the goalie caught the ball, it can move together with the ball within the penalty area. The goalie is allowed to move goalie_max_moves times before it kicks the ball. Additional move commands do not have any effect and the server will respond with (error too_many_moves).
Parameter in |
Value |
|---|---|
goalie_max_moves |
2 |
4.5.5. Say Model
Using the say command, players can broadcast messages to other players. Messages can be say_msg_size characters long, where valid characters for say messages are from the set sth (without the square brackets). Messages players say can be heard within a distance of audio_cut_dist by members of both teams . Say messages sent to the server will be sent back to players within that distance immediately. The use of the say command is only restricted by the limited capacity of the players of hearing messages.
Parameter in |
Value |
|---|---|
say_msg_size |
10 |
audio_cut_dist |
50 |
hear_max |
1 |
hear_inc |
1 |
hear_decay |
1 |
4.5.6. Tackle Model
The tackle command is to accelerate the ball towards the player’s body(TODO:new tackle model [12.0.0 pre-20080210]). Players can kick the ball that can not be kicked with the kick command by executing the tackle command. The success of tackle depends on a random probability related to the position of the ball. It can be obtained by the following formula.
The probability of a tackle failure when the ball is in front of the player is:
The probability of a tackle failure when the ball is behind the player is:
The probability of processing success is:
In this case, when the ball is in front of the player, it is used to tackle_dist (default is 2.0), otherwise it is used to tackle_back_dist (default is 0.5); player_to_ball is a vector from the player to the ball, relative to the body direction of the player. When the tackle command is successful, it will give the ball an acceleration in its own body direction.
The execution effect of tackle is similar to that of kick, which is obtained by multiplying the parameter tackle_power_rate (default is 0.027) with power. It can be expressed by the following formula:
Once the player executes the tackle command, whether successful or not, the player can no longer move within 10 cycles. The following table shows the parameters used in tackle command.
TODO
[12.0.0 pre-20080210] new kick/tackle noise model
[12.0.0 pre-20080210] max_back_tackle_power
[13.0.0] forbid backward tackle
[14.0.0] increasing tackle noise using server::tackle_rand_factor
Parameter in |
Value |
|---|---|
tackle_dist |
2 |
tackle_back_dist |
0 |
tackle_width |
1.25 |
tackle_cycles |
10 |
tackle_exponent |
6 |
tackle_power_rate |
0.027 |
max_tackle_power |
100 |
max_back_tackle_power |
0 |
tackle_rand_factor |
2 |
4.5.7. Foul Model
TODO
[14.0.0] foul model and intentional foul option
[14.0.0] trade off between foul detect probability and kick power rate
[15.0.0] improve foul model (red_card_probability)
4.5.8. Turn Model
While dash is used to accelerate the player in direction of its body, the turn command is used to change the players body direction. The argument for the turn command is the moment; valid values for the moment are between server::minmoment and server::maxmoment. If the player does not move, the moment is equal to the angle the player will turn. However, there is a concept of inertia that makes it more difficult to turn when you are moving. Specifically, the actual angle the player is turned is as follows:
server::inertia_moment is a server.conf parameter with default value 5.0. Therefore (with default values), when the player is at speed 1.0, the maximum effective turn he can do is \(\pm30\). However, notice that because you can not dash and turn during the same cycle, the fastest that a player can be going when executing a turn is \(player\_speed\_max \times player\_decay\), which means the effective turn for a default player (with default values) is \(\pm60\).
For heterogeneous players, the inertia moment is the default inertia value plus a value between \({\mathrm player\_decay\_delta\_min \times inertia\_moment\_delta\_factor}\) and \({\mathrm player\_decay\_delta\_max \times inertia\_moment\_delta\_factor}\).
Default Parameters
server.conf |
Default Value (Range)
|
Heterogeneous Player Parameters
player.conf |
Value
|
|---|---|---|---|
Name |
Name |
||
server::minmoment |
-180 |
||
server::maxmoment |
180 |
||
server::inertia_moment |
5.0([2.5, 7.5]) |
player::player_decay_delta_min
player::player_decay_delta_max
player::inertia_moment_delta_factor
|
-0.1
0.1
25
|
4.5.9. TurnNeck Model
With turn_neck, a player can turn its neck somewhat independently of its body. The angle of the head of the player is the viewing angle of the player. The turn command changes the angle of the body of the player while turn_neck changes the neck angle of the player relative to its body. The minimum and maximum relative angle for the player’s neck are given by server::minneckang and server::maxneckang in server.conf. Remember that the neck angle is relative to the body of the player so if the client issues a turn command, the viewing angle changes even if no turn_neck command was issued. Also, turn_neck commands can be executed during the same cycle as turn, dash, and kick commands. turn_neck is not affected by momentum like turn is. The argument for a turn_neck command must be in the range between server::minneckmoment and server::maxneckmoment.
Parameter in |
Value |
|---|---|
minneckang |
-90 |
maxneckang |
90 |
minneckmoment |
-180 |
maxneckmoment |
180 |
4.5.10. Change Focus Model
The focus point is a feature developed in server v.18, which can be used by all versions of players. It represents a position inside a player’s view angle, and can be up to 40.0 meters away from the player’s position. The focus point affects the visual sensor noise model, with the noise of observed objects increasing as the distance between the focus point and the object increases.
The initial position of the focus point is the player’s position. Players can change the position of the focus point by sending a change_focus command. This command takes two parameters, dist_moment and dir_moment, and changes the position of the focus point relative to the player’s neck angle.
It is important to note that players are not allowed to move the focus point outside of their view angle. Additionally, if a player changes their view angle to a smaller one, the server will automatically move the focus point back into the player’s view angle.
See Vision Sensor Model in detail about the vison sensor.
4.5.11. Pointto Model
Players can send commands to point to a spot on the field of the form:
(pointto <DIST> <DIR>)
or
(pointto off)
The first form will cause the arm to point to the spot DIST meters
from the player in DIR direction, relative to the player’s current
face direction.
The player will continue to point to the same location on the field
independent of an motion or rotation of the player for at least
server::point_to_ban cycles, and until another pointto command is
issued or server::point_to_duration cycles pass.
The second form disables a previous call of pointto.
Parameter in |
Value |
|---|---|
point_to_ban |
5 |
point_to_duration |
20 |
Version 8+ clients can see where a player is pointing, if the player is pointing, the player is in view and they are close enough to determine their team name.
In these cases the player part of the see message has the form (without the newline):
- (p “<TEAMNAME>” <UNUM>) <DIST> <DIR> <DISTCHG> <DIRCHG>
<BDIR> <HDIR> <POINTDIR>)
or
(p “<TEAMNAME>”) <DIST> <DIR> <POINTDIR>)
Where POINTDIR is the direction the players are is pointing with random Gaussian (normal)noise added to the actual direction, with a mean of zero and a standard deviation calculated as follows:
sigma = pow(dist / team_too_far_length, 4) * 178.25 + 1.75
This means that sigma is a minimum of 1.75 deg and reaches 180 deg when the player is observing a pointing arm from a distance of team_too_far_length. Since 95% of values in a normal distributionare within two standard deviations, then 95% of the time the noise will be in the range +- 2.5 deg when the player is very close and in the range +- 360.0 deg when the player is team_too_far_length away.
sense_body messages for version 8+ clients contain information about the arm actuator.
The following has been inserted into the sense_body message, just before the last ‘)’, without the new line:
- (arm (movable <MOVABLE>) (expires <EXPIRES>)
(target <DIST> <DIR>) (count <COUNT>))
Where:
<MOVABLE> is the number of cycles till the arm is movable. 0 indicates the arm is movable now
<EXPIRES> is the number of cycles till the arm stops pointing. 0 indicates that the arm is no longer pointing,
<DIST> and <DIR> are the distance and direction of the point the player is pointing to, relative to the players location, orientation and neck angle, accurate to 10cm or 0.1 deg.
<COUNT> is the number of times the
pointtocommand has been successfully executed by the player.
Fullstate messages have both <POINTDIST> and <POINTDIR> included between neck angle and stamina. The players own arm state has the same format as in sense body (see below) and can be found between the count and score part.
Version 8+ coaches (on and offline) can see where a player is pointing to if the player is pointing. The direction the player is pointing comes just after the players neck angle.
4.5.12. Attentionto Model
Version 8 and above players can send attentionto commands to focus their attention on a particular player.
The command has the form:
(attentionto <TEAM> <UNUM>) | (attentionto off)
Where <TEAM> is
opp|our|l|r|left|right| <TEAM_NAME>
and <UNUM> is integer identifying a member of the team specified.
Players can only focus on one player at a time (each attentionto command
overrides the previous) and cannot focus on themselves.
See Sensor Models in detail about the aural sensor.
4.6. Heterogeneous Players
With the rcssserver version 7, heterogeneous players were introduced. For heterogeneous players, the server generates player::player_types random player types at startup. The player types have different capabilities based on the trade-offs defined in the player.conf file. Both teams of a match use the same player types. Type 0 is the default type and is always the same. If player::random_seed is not 0, the fixed set of heterogenous player paramters can be generated based on the given seed value. Table 4.17 shows the differences of heterogeneous players:
When players and coaches connect to the server, they can receive information about the available player types. The online coaches can change player types unlimited times before the first kick off and change player types player::subs_max times during other non-play_on play modes using the change_player_type command (see Commands).
The online coach can substitute a same player type within player::pt_max times. This restriction also applied to the default player type. This means that all field players have to be changed to the non-default type. In version 16, the goalie is still allowed to be assigned the default type. However, if server::allow_mult_default_type is false and teams use the default player type more than player::pt_max, rcssserver automatically assign the heterogeneous player type to field players just before the playmode is changed to kick-off.
The online coach can substitute a same player type within player::pt_max times. This restriction is not applied to the default player type. If player::pt_max is 1, each player type except the default type can be used only once.
Each time a player is substituted by some other player type, its stamina, recovery and effort is reset to the initial (maximum) value of the respective player type.
Parameter |
Description |
|---|---|
PlayerSpeedMax |
maximum speed |
StaminaIncMax |
Amount of stamina recovered in one step |
PlayerDecay |
Player speed decay rate |
InertiaMoment |
Player inertia force when moving |
DashPowerRate |
Dash acceleration rate |
PlayerSize |
Player size |
KickableMargin |
Kickable area radius |
KickRand |
The amount of noise added to the kick |
ExtraStamina |
Extra stamina available when stamina is exhausted |
EffortMax |
Maximum value of the player’s effort amount |
EffortMin |
The minimum amount of effort for the player |
CatchAreaLengthStretch |
Streach Length to Catch |
KickPowerRate |
Kick Power Rate |
FoulDetectProbability |
Probability that the referee will take the foul |
UnumFarLength |
If dist less than unum_far_length, then both uniform number and team name are visible |
UnumTooFarLength |
If dist more than unum_too_far_length, then the uniform number is not visible |
TeamFarLength |
If dist less than team_far_length, then the team name is visible |
TeamTooFarLength |
If dist more than team_too_far_length, then the team name is not visible. |
PlayerMaxObservationLength |
If dist more than player_max_observation_length, then the player is not visible. |
BallVelFarLength |
If dist less than ball_vel_far_length, then ball vel is visible |
BallVelTooFarLength |
If dist more than ball_vel_too_far_length, then ball vel is not visible |
BallMaxObservationLength |
If dist more than ball_max_observation_length, then the ball is not visible. |
FlagChgFarLength |
If dist less than flag_chg_far_length, then the flag dist change is sent. |
FlagChgTooFarLength |
If dist less than flag_chg_too_far_length, then the flag dist change is not sent. |
FlagMaxObservationLength |
If dist more than flag_max_observation_length, then the flag is not visible. |
Heterogeneous player parameters given for each match are different. Therefore, each agent does not necessarily have the parameters needed to implement the tactics. Whatever the situation, you need a way to choose the best combination of heterogeneous players.
Parameter in player.conf |
Value |
|---|---|
player_types |
18 |
subs_max |
3 |
pt_max |
1 |
4.7. Referee Model
The Automated Referee sends messages to the players, so that players know the actual play mode of the game. The rules and the behavior for the automated referee are described in Sec. Kick-Off. Players receive the referee messages as hear messages. A player can hear referee messages in every situation independent of the number of messages the player heard from other players.
4.7.1. Play Modes and referee messages
The change of the play mode is announced by the referee. Additionally, there are some referee messages announcing events like a goal or a foul. If you have a look into the server source code, you will notice some additional play modes that are currently not used. Both play modes and referee messages are announced using (referee String ), where String is the respective play mode or message string. The play modes are listed in Table 4.19, for the messages see Table 4.20.
Play Mode |
tc |
subsequent play mode |
comment |
|---|---|---|---|
before_kick_off |
0 |
kick_off_Side |
at the beginning of a half |
play_on |
during normal play |
||
time_over |
End of the game |
||
kick_off_Side |
announce start of play (after pressing the Kick Off button) |
||
kick_in_Side |
|||
free_kick_Side |
|||
corner_kick_Side |
when the ball goes out of play over the goal line, without a goal being scored and having last been touched by a member of the defending team. |
||
goal_kick_*Side* |
play_on |
play mode changes once the ball leaves the penalty area |
|
goal_*Side* |
currently unused |
||
drop_ball |
0 |
play_on |
|
offside_Side |
30 |
free_kick_Side |
An offside player who is closer to the opponent’s goal when his teammate hits the ball, both in front of the ball and in front of the last player of the opposing team. The offside rule prevents players from concentrating in front of the opponent’s goal, as no player can stand near the opponent’s goal and have a chance to score by waiting for the ball, and the possibility of sending long passes close to the opponent’s goal is limited. In this way, defenders can distance themselves from their own goal and participate more during the game. |
penalty_kick_Side |
When the game ends in a draw of 6,000 cycles and overtime, the winner will be determined by penalty kicks. |
||
foul_charge_Side |
Pushing the opposing player |
||
back_pass_Side |
A goalkeeper is not allowed to catch the ball inside his own penalty area if a teammate sends the ball to him. The opposing team will receive an indirect free-kick at the point of touch if the goalkeeper makes the mistake. |
||
free_kick_fault_Side |
Players are not allowd to kick the ball to themselves after a free kick. If a player does kick the ball to themselves after a free kick, a free kick is awarded to the opposing team at the point that the second kick occurred. |
||
indirect_free_kick_Side |
In a direct free kick, the player can shoot the ball directly towards the goal, but an indirect free kick cannot and must pass the ball to a teammate. |
||
illegal_defense_Side |
where Side is either the character l or r, OSide means opponent’s side. tc is the time (in number of cycles) until the subsequent play mode will be announced
Message |
tc |
subsequent play mode |
comment |
|---|---|---|---|
goal_*Side*_*n* |
50 |
kick_off_*OSide* |
announce the n th goal for a team |
foul_*Side* |
0 |
free_kick_*OSide* |
announce a foul |
yellow_card_*Side*_*Unum* |
0 |
announce an yellow card information |
|
red_card_*Side*_*Unum* |
0 |
announce a red card information |
|
goalie_catch_ball_*Side* |
0 |
free_kick_*OSide* |
|
time_up_without_a_team |
0 |
time_over |
sent if there was no opponent until the end of the second half |
time_up |
0 |
time_over |
sent once the game is over (if the time is ≥ second half and the scores for each team are different) |
half_time |
0 |
before_kick_off |
|
time_extended |
0 |
before_kick_off |
where Side is either the character l or r, OSide means opponent’s side. tc is the time (in number of cycles) until the subsequent play mode will be announced.
4.7.2. Time Referee
TODO
Judges the game time
server::half_time
[12.1.3] server::extra_half_time
[13.0.0] change a length of overtime
4.7.3. Offside Referee
The offside referee is a module that observes the field, particularly passes, to check whether the offside foul happens. This module determines offside lines every cycle, then specifies several candidates from players which would result in an offside if they receive a pass.
The referee is configurable by some parameters in server.conf file. some useful parameters are explained below.
server::use_offside = true // true: enable, false: disable
This parameter determines whether the offside referee is enabled or disabled.
server::offside_active_area_size = 2.5
This parameter determines the radius of an area around a candidate pass receiver. If the ball enters the area and the candidate performs a kick or tackle command, the offside foul is called. Offside is also called if the candidate collides with the ball.
offside_kick_margin = 9.15
This parameter determines the radius of area that every player in the team which has done offside foul must stay out when the other team wants to free-kick. If there is a player in that area, server moves them out of that.
4.7.4. FreeKick Referee
Free kicks are detected automatically by the soccer server in many relevant cases. The Free kick referee is a module that observes the play mode, to check whether the free kick foul happens and what should teams do. Some methods are explained below.
void FreeKickRef::kickTaken
This method is executed when foul has occurred by the player. This method checks whether the kick is correctly done or not.
void FreeKickRef::tackleTaken
This method is executed when a tackle foul has occurred by the player
void FreeKickRef::ballTouched
This method checks whether the ball has been touched by an unauthorized player.
void FreeKickRef::analyse
This method checks the game play mode and removes unauthorized players from the foul area due to the situation.
void FreeKickRef::playModeChange
This method provides the free kick conditions according to the game mode and occurs when the mode has changed.
void FreeKickRef::callFreeKickFault
This method is for calling the free kick and receives the side and the foul location as inputs.
bool FreeKickRef::goalKick
If the right or left goal kick has occurred, the output value of this method is true.
bool FreeKickRef::freeKick
If foul occurs, the output value of this method is true.
bool FreeKickRef::ballStopped
If the ball stops moving, the output value of this method is true.
bool FreeKickRef::tooManyGoalKicks
If the value of goal kick count is greater than maxGoalKicks the output value of this method is true.
void FreeKickRef::placePlayersForGoalkick
This method sends the opponent players out of the penalty area if a goal kick occurs.
4.7.5. Touch Referee
TODO
Judge the goal
[14.0.0] golden goal option, server::golden_goal
Checking for goals, out of bounds and within penalty area no complies with FIFA regulations. For a goal to be scored the ball must be totally within the goal - i.e.
Similarly the ball must be completely out of the pitch before it is considered out - i.e
Lastly the ball is within the penalty area (and thus catchable) if the ball is at least partially within the penalty area - i.e.
4.7.6. Catch Referee
TODO
Judges the goalie’s catch behavior
[12.0.0 pre-20071217] change the rules of back pass and catch fault
[12.0.0 pre-20071217] change the rule of goalies’ catch vioration
[12.1.1] fix the back pass rule
4.7.7. Foul Referee
TODO
Judges the foul
[14.0.0] foul model and intentional foul option
[14.0.0] foul information in sense_body/fullstate
[14.0.0] red/yellow card message
If an intentional and dangerous foul is detected, the referee penalizes the player and sends the yellow/red card message to clients. The message format is similar to playmode messages. Side and uniform number information of penalized player are appended to the card message:
(referee TIME yellow_card_[lr]_[1-11]) or (referee TIME red_card_[lr]_[1-11])
4.7.8. Ball Stuck Referee
TODO: server::ball_stuck_area. [11.0.0] in NEWS
4.7.9. Illegal Defense Referee
From the server version 16, a new referee module has been added to control the number of defensive players. We have four new variables in server_param to change the parameters of this referee.
server::illegal_defense_duration = 20
This parameter determines the number of cycles that illegal defense situation would have to remain before calling a free kick.
server::illegal_defense_number = 0
This parameter determines how many players would need to be in the specified zone before the illegal defense situation countdown starts. If the value is set to 0, the referee never detects illegal defense situations.
server::illegal_defense_dist_x = 16.5
This parameter determines the distance from the field’s goal lines for detecting defensive players.
server::illegal_defense_width = 40.32
This parameter determines the horizontal distance from the horizontal symmetry line for detecting defensive players.
4.7.10. Keepaway Referee
TODO
[9.1.0] keepaway mode
4.7.11. Penalty Shootouts Referee
TODO
[9.3.0] penalty shootouts
[9.4.0] pen_coach_moves_players
Rules
If defensive players exists within the rectangle defined by illegal_defense_dist_x and illegal_defense_width, they are marked as an illegal state. if the number of markerd players becomes greater than or equal to illegal_defense_number and this continues for illegal_defense_duration cycles, then play mode will change to free_kick_[lr] for the offensive team.
A team is considered as the offensive team when their player is the latest player to kick the ball. If both teams perform a kick on the same cycle, neither team is considered as offensive, and the countdown resets. The above rule is applied to the tackle action too. The change of play mode does not affect cycles of illegal defense situations.
4.8. The Soccer Simulation
In Movement Models, we gave a description on how the objects are moved with respect to their accelerations and velocities. In this section, we describe at what point in time acceleration and velocities are applied to the objects during the simulation.
4.8.1. Description of the simulation algorithm
In Soccer Server, time is updated in discrete steps. A simulation step is 100ms. During each simulation step, objects (i.e. players and the ball) stay on their positions. If players decide to act within a step, actions are applied to the players and the ball at the transition from one simulation cycle to the next. Depending on the play mode, not all actions are allowed for the players (for instance in ‘before kick off’ mode, players can turn and move, but they cannot dash), so only allowed actions will be applied and take effect. If during a step, several players kick the ball, all the kicks are applied to the ball and a resulting acceleration is calculated. If the resulting acceleration is larger than the maximum acceleration for the ball, acceleration is normalized to its maximum value. After moving the objects, the server checks for collisions and updates velocities if a collision occurred (see also Sec. 4.4.2). When applying accelerations and velocities to the objects, the order of application is randomized. After changing objects positions, and updating velocities and accelerations, the automated referee checks the situation and changes the play mode or the object positions, if necessary. Changes to the play mode are announced immediately. Finally, stamina for each player is updated.
In Soccer Server, time is updated in discrete steps. A simulation step is 100ms. During each simulation step, objects (i.e. players and the ball) stay on their positions. If players decide to act within a step, actions are applied to the players and the ball at the transition from one simulation cycle to the next. Depending on the play mode, not all actions are allowed for the players (for instance in before_kick_off mode, players can turn and move, but they cannot dash), so only allowed actions will be applied and take effect.
If during a step, several players kick the ball, all the kicks are applied to the ball and a resulting acceleration is calculated. If the resulting acceleration is larger than the maximum acceleration for the ball, acceleration is normalized to its maximum value. After moving the objects, the server checks for collisions and updates velocities if a collision occurred (see also Collision Model).
When applying accelerations and velocities to the objects, the order of application is randomized. After changing objects positions, and updating velocities and accelerations, the automated referee checks the situation and changes the play mode or the object positions, if necessary. Changes to the play mode are announced immediately. Finally, stamina for each player is updated.
4.8.2. Keepaway Mode
TODO: [9.1.0] in NEWS
4.9. Using Soccerserver
To start the server either type:
./rcssserver
from the directory containing the executable or:
rcssserver
if you installed the executables in your PATH.
4.9.1. Configuration Files
rcssserver will look in your home directory for the configuration files:
.rcssserver/server.conf
.rcssserver/player.conf
.rcssserver/CSVSaver.conf
.rcssserver-landmark.xml
If .conf files do not exist, they will be created and populated with default values.
You can include additional configuration files by using the include=FILE
option to rcssserver.
TOOD
[8.01] landmark reader
[13.0.0] RCSS_CONF_DIR
4.9.2. Recording Command Log
TODO: description about .rcl file
4.9.3. Automatic Mode
TODO: [9.0.2]
4.9.4. Anonyous Mode
Anonymous Mode,which was introduced in server version 16.0.0 allows the server to hide team names from opponents. There are two parameters inside server.conf, which allow each side’s name to be set to a fixed string. If the parameter is empty, the real name of the team will be reported to the opponent.
Parameter |
Description |
|---|---|
server::fixed_teamname_l |
Fixed name of the left team, which is sent to the right team. Leave empty for real name. |
server::fixed_teamname_r |
Fixed name of the left team, which is sent to the right team. Leave empty for real name. |
4.9.5. Synchronous Mode
TODO: [7.11] in ChangeLog
4.9.6. Result Saver
TODO
[9.4.0] StdOutSaver, MySQLSaver
[9.4.3] CSVSaver
4.9.7. The Soccerserver Parameters
Name |
Current Value in |
Description |
|---|---|---|
version |
VERSION |
soccer server version |
catch_ban_cycle |
5 |
goalies cannot execute the next catch until this cycle has passed after the successful catch. |
clang_win_size |
300 |
time window which controls how many messages can be sent (coach language) |
clang_advice_win |
1 |
number of advice messages per window |
clang_define_win |
1 |
number of define messages per window |
clang_del_win |
1 |
number of del messages per window |
clang_info_win |
1 |
number of info messages per window |
clang_mess_delay |
50 |
delay between receipt of message and send to players |
clang_mess_per_cycle |
1 |
maximum number of coach messages sent per cycle |
clang_meta_win |
1 |
number of meta messages per window |
clang_rule_win |
1 |
number of rule messages per window |
clang_win_size |
1 |
The length of clang message window |
coach_port |
6001 |
(offine) coach port |
connect_wait |
300 |
maximum cycle to wait for client connections in automatic mode |
drop_ball_time |
100 |
number of cycles to wait until dropping the ball automatically |
extra_half_time |
100 |
length of a half time of extra halves in seconds |
foul_cycles |
5 |
idle cycles of foul charged players |
freeform_send_period |
20 |
online coaches can send a freeform message during this period after the waiting period |
freeform_wait_period |
600 |
online coaches can send a freeform message after waiting this period |
game_log_compression |
0 |
compression level of game log file |
game_log_version |
5 |
version of game log format |
game_over_wait |
100 |
maximum cycle to wait for server termination in automatic mode |
goalie_max_moves |
2 |
goalie max. moves after a catch |
half_time |
300 |
length of a half time in seconds |
hear_decay |
1 |
value that reduces the auditory capacity when receiving an auditory message |
hear_inc |
1 |
value that increases the auditory capacity when the game cycle is updated |
hear_max |
1 |
maximum value of audiotory capacity |
illegal_defense_duration |
20 |
threshold count to detect illegal defense behavior |
illegal_defense_number |
0 |
number of players judged to be illegal illegal defense behavior |
keepaway_start |
-1 |
|
kick_off_wait |
100 |
maximum cycle to wait kick-off in automatic mode |
max_goal_kicks |
3 |
(actually no effect) |
max_monitors |
-1 |
max number of monitor connections |
nr_extra_halfs |
2 |
number of extra halves in a game |
nr_normal_halfs |
2 |
number of normal halves in a game |
olcoach_port |
6002 |
online coach port |
pen_before_setup_wait |
10 |
max waiting cycles in penalty_miss_[lr] or penalty_score_[lr] |
pen_max_extra_kicks |
5 |
max extra kick trials in penalty shootouts |
pen_nr_kicks |
5 |
number of normal kick trials in penalty shootouts |
pen_ready_wait |
10 |
max waiting cycles in penalty_ready_[lr] |
pen_setup_wait |
70 |
max waiting cycles in penalty_setup_[lr] |
pen_taken_wait |
150 |
max cycles in penalty_taken_[lr] |
point_to_ban |
5 |
players cannot execute the next pointto until this cycle has passed |
point_to_duration |
20 |
point to continues automatically for up to this cycle |
port |
6000 |
player port number |
recv_step |
10 |
time step of acception of commands [unit: msec] |
say_coach_cnt_max |
128 |
upper limit of the number of online coach’s message |
say_coach_msg_size |
128 |
upper limit of length of online coach’s message |
say_msg_size |
10 |
string size of say message [unit:byte] |
send_step |
150 |
time step of visual information [unit:msec] |
send_vi_step |
100 |
interval of online coach’s look |
sense_body_step |
100 |
time step of player’s body information [unit:msec] |
simulator_step |
100 |
time step of simulation [unit:msec] |
slow_down_factor |
1 |
coefficient that slows down simulation time |
start_goal_l |
0 |
initial score of the left team |
start_goal_r |
0 |
initial score of the right team |
synch_micro_sleep |
1 |
sleep time to wait clients in synch mode [unit:msec] |
synch_offset |
60 |
offset time from the beginning of the cycle to send think message [unit:msec] |
synch_see_offset |
0 |
offset time from the beginning of the cycle to send see message if players uses synch_see mode [unit:msec] |
tackle_cycles |
10 |
idle cycles of the players that executed tackle |
text_log_compression |
0 |
compression level of text log file |
auto_mode |
false |
enable auto start of the match |
back_passes |
true |
enable back pass rule |
coach |
false |
|
coach_w_referee |
false |
allows trainer with automatic referee |
forbid_kick_off_offside |
true |
forbid kick off offside |
free_kick_faults |
true |
enable free kick fault rule |
fullstate_l |
false |
enable full state information for left team |
fullstate_r |
false |
enable full state information for right team |
game_log_dated |
true |
flag to write date in game log name |
game_log_fixed |
false |
enable fixed name in game log |
game_logging |
true |
flag for game logging |
golden_goal |
false |
flag for the golden goal rule |
keepaway |
false |
flag for keepaway mode |
keepaway_log_dated |
true |
flag to write date in keep away log name |
keepaway_log_fixed |
false |
enable fixed name in keep away log |
keepaway_logging |
true |
enable logging in keep away mode |
log_times |
false |
|
old_coach_hear |
false |
|
pen_allow_mult_kicks |
true |
Turn on to allow dribbling in penalty shootouts |
pen_coach_moves_players |
true |
Turn on to have the server automatically position players for peanlty shootouts |
pen_random_winner |
false |
enable random winner in penalties |
penalty_shootouts |
true |
Set to true to enable penalty shootouts after normal time and extra time if the game is drawn. |
profile |
false |
|
proper_goal_kicks |
false |
|
record_messages |
false |
enables recording message to game log file |
send_comms |
false |
enables sending message to monitors |
synch_mode |
false |
enables synchronous mode |
team_actuator_noise |
false |
flag whether to use team specic actuator noise |
text_log_dated |
true |
flag to write date in text log name |
text_log_fixed |
false |
enable fixed name in text log |
text_logging |
true |
flag for recording client command log |
use_offside |
true |
flag for using off side rule |
verbose |
false |
flag for verbose mode |
wind_none |
false |
wind factor is none |
wind_random |
false |
wind factor is random |
audio_cut_dist |
50.0 |
audio cut off distance |
back_dash_rate |
0.6 |
dash power date for the backward dash |
ball_accel_max |
2.7 |
max. ball acceleration |
ball_decay |
0.94 |
ball decay |
ball_rand |
0.05 |
noise parameter for the ball movement |
ball_size |
0.085 |
ball size |
ball_speed_max |
3.0 |
max. ball velocity |
ball_stuck_area |
3.0 |
threshold of distance to detect a stucked situation |
ball_weight |
0.2 |
(not used) weight of the ball |
catch_probability |
1.0 |
default goalie catch probability |
catchable_area_l |
1.2 |
goalie’s defalut catchable area length |
catchable_area_w |
1.0 |
goalie’s catchable area width |
ckick_margin |
1.0 |
corner kick margin |
control_radius |
2.0 |
(not used) |
dash_angle_step |
1.0 |
minimum angle step for dash command |
dash_power_rate |
0.006 |
default dash power rate |
effort_dec |
0.005 |
dash effort decrement |
effort_dec_thr |
0.3 |
player dash effort decrement threshold |
effort_inc |
0.01 |
dash effort increment |
effort_inc_thr |
0.6 |
dash effort increment treshold |
effort_init |
1.0 |
default effort value |
effort_min |
0.6 |
min. player dash effort |
extra_stamina |
50.0 |
default extra stamina |
foul_detect_probability |
0.5 |
default foul detect probability |
foul_exponent |
10.0 |
|
goal_width |
14.02 |
goal width |
illegal_defense_dist_x |
16.5 |
|
illegal_defense_width |
40.32 |
|
inertia_moment |
5.0 |
default intertia moment for turn |
keepaway_length |
20 |
length of rectangle in keep away mode |
keepaway_width |
20 |
width of rectangle in keep away mode |
kick_power_rate |
0.027 |
kick power rate |
kick_rand |
0.1 |
base parameter for noise added directly to kicks |
kick_rand_factor_l |
1.0 |
factor to multiply kick rand for left team |
kick_rand_factor_r |
1.0 |
factor to multiply kick rand for right team |
kickable_margin |
0.7 |
default kickable margin |
max_back_tackle_power |
0.0 |
maximum back tackle power |
max_dash_angle |
180.0 |
maximum dash angle relative to player’s body angle |
max_dash_power |
100.0 |
maximum dash acceleration power |
max_tackle_power |
100.0 |
maximum tackle power |
maxmoment |
180.0 |
max. moment |
maxneckang |
90.0 |
max. neck angle |
maxneckmoment |
180.0 |
max. neck moment |
maxpower |
100.0 |
max kick power |
min_dash_angle |
-180.0 |
minimum dash angle relative to player’s body angle |
min_dash_power |
-100.0 |
minimum dash acceleration power |
minmoment |
-180.0 |
max. moment |
minneckang |
-90.0 |
max. neck angle |
minneckmoment |
-180.0 |
max. neck moment |
minpower |
-100 |
min kick power |
offside_active_area_size |
2.5 |
|
offside_kick_margin |
9.15 |
|
offside_kick_margin |
9.15 |
|
pen_dist_x |
42.5 |
|
pen_max_goalie_dist_x |
14 |
|
player_accel_max |
1.0 |
max. player acceleration |
player_decay |
0.4 |
default player decay |
player_rand |
0.1 |
players’ movement noise parameter |
player_size |
0.3 |
player radius |
player_speed_max |
1.05 |
maxium speed of players |
player_speed_max_min |
0.75 |
The minumum value of the maximum speed of players |
player_weight |
60.0 |
(not used) player weight |
prand_factor_l |
1 |
factor to multiply prand for left team |
prand_factor_r |
1 |
factor to multiply prand for right team |
quantize_step |
0.1 |
quantize step of distance for movable objects |
quantize_step_l |
0.01 |
quantize step of distance for landmarks |
recover_dec |
0.002 |
player recovery decrement |
recover_dec_thr |
0.3 |
player recovery decrement threshold |
recover_init |
1.0 |
player’s initial recovery value |
red_card_probability |
0.0 |
probability of red card in a foul |
side_dash_rate |
0.4 |
factor to multiply effective power when side dash is performed |
slowness_on_top_for_left_team |
1 |
|
slowness_on_top_for_right_team |
1 |
|
stamina_capacity |
130600 |
max. recovery capacity of each player’s stamina |
stamina_inc_max |
45.0 |
default max. player stamina increment |
stamina_max |
8000.0 |
max. player stamina |
stopped_ball_vel |
0.01 |
threshold value to detect ball is moving or not |
tackle_back_dist |
0.0 |
max. x distance between player and ball that player may perform a tackle when ball is behind the player |
tackle_dist |
2.0 |
max. x distance between player and ball that player may perform a tackle when ball is in front of the player |
tackle_exponent |
6.0 |
exponent used in tackle failure probability equation |
tackle_power_rate |
0.027 |
tackle power rate |
tackle_rand_factor |
2.0 |
|
tackle_width |
1.25 |
max. y distance between player and ball that player may perform a tackle when ball is in front of the player |
visible_angle |
90.0 |
visible angle |
visible_distance |
3.0 |
|
wind_ang |
0.0 |
|
wind_dir |
0.0 |
wind direction |
wind_force |
0.0 |
|
wind_rand |
0.0 |
|
coach_msg_file |
‘’ |
|
fixed_teamname_l |
‘’ |
fixed name of left team’s opponent |
fixed_teamname_r |
‘’ |
fixed name of right team’s opponent |
game_log_dir |
‘./’ |
path to game log directory |
game_log_fixed_name |
‘rcssserver’ |
fixed name of game log |
keepaway_log_dir |
‘./’ |
path to keep away log directory |
keepaway_log_fixed_name |
‘rcssserver’ |
fixed name of keep away log |
landmark_file |
‘~/.rcssserver-landmark.xml’ |
|
log_date_format |
‘%Y%m%d%H%M%S-’ |
date format in game log |
team_l_start |
‘’ |
path to start script of left team |
team_r_start |
‘’ |
path to start script of right team |
text_log_dir |
‘./’ |
path to text log directory |
text_log_fixed_name |
‘’ |
fixed name of text log |
Name |
Current Value in |
Description |
|---|---|---|
version |
soccer server version |
|
player_types |
18 |
number of random player types generated at match startup |
pt_max |
1 |
number of times that online coach can substitute a player to another player of the same type |
random_seed |
-1 |
seed to generate heterogeneous players parameters of a match if it is non zero |
subs_max |
3 |
maximum number of substitutions in a match |
allow_mult_default_type |
false |
|
catchable_area_l_stretch_max |
1.3 |
defines the upper bound of player’s catchable_area_l_stretch |
catchable_area_l_stretch_min |
1 |
defines the lower bound of player’s catchable_area_l_stretch |
dash_power_rate_delta_max |
0 |
defines the upper bound of player’s dash power rate when added to default dash power rate |
dash_power_rate_delta_min |
0 |
defines the lower bound of player’s dash power rate when added to default dash power rate |
effort_max_delta_factor |
-0.004 |
controls the upper bound of player’s effort amount |
effort_min_delta_factor |
-0.004 |
controls the lower bound of player’s effort amount |
extra_stamina_delta_max |
50 |
defines the upper bound of player’s extra stamina when added to default extra stamina |
extra_stamina_delta_min |
0 |
defines the lower bound of player’s extra stamina when added to default extra stamina |
foul_detect_probability_delta_factor |
0 |
defines the range of heterogeneous player’s foul detect probability |
inertia_moment_delta_factor |
25 |
factor to control the length of inertia moment delta interval |
kick_power_rate_delta_max |
0 |
defines the upper bound of player’s kick power rate when added to default kick power rate |
kick_power_rate_delta_min |
0 |
defines the lower bound of player’s kick power rate when added to default kick power rate |
kick_rand_delta_factor |
1 |
|
kickable_margin_delta_max |
0.1 |
defines the upper bound of player’s kickable margin when added to default kickable margin |
kickable_margin_delta_min |
-0.1 |
defines the lower bound of player’s kickable margin when added to default kickable margin |
new_dash_power_rate_delta_max |
0.0008 |
|
new_dash_power_rate_delta_min |
-0.0012 |
|
new_stamina_inc_max_delta_factor |
-6000 |
|
player_decay_delta_max |
0.1 |
defines the upper bound of inertia moment delta when multiplied by inertia moment delta factor |
player_decay_delta_min |
-0.1 |
defines the lower bound of inertia moment delta when multiplied by inertia moment delta factor |
player_size_delta_factor |
-100 |
controls the range of heterogeneous player’s size |
player_speed_max_delta_max |
0 |
defines the upper bound of player’s maximum speed when added to server::player_speed_max |
player_speed_max_delta_min |
0 |
defines the lower bound of player’s maximum speed when added to server::player_speed_max |
stamina_inc_max_delta_factor |
0 |
Name |
Current Value in |
Description |
|---|---|---|
version |
soccer server version |
|
save |
false |
flag to save matches result in a file |
filename |
‘rcssserver.csv’ |
file to save the results to. If this file does not exist it will be created. Otherwise, the results will be appended to the end. |