5-a-side Toroidal Bot Soccer
king-of-the-hill
Randomised teams
This is a team game. Rather than being assigned permanently to one team or the other, each bot will play in a number of games, each for a different randomly composed team of 5 players ("5-a-side"), and score a point for each game in which its team wins. This means every game requires team work, but there is still a single overall winner after all games are played.
Rules
There are no rules for the players (no referee, no penalties, no off-side rule). The movement of the ball defines the score and the players can do as they see fit.
Scoring
There are no goal posts. If the ball moves off the right hand edge of the field, it reappears at the left hand edge of the field and team 1 scores a goal. Similarly team 2 score if it moves off the left hand edge and reappears at the right. The score will be represented by a single integer, that is increased by one when team 1 scores, and decreased by one when team 2 scores. At the end of a game, team 1 wins if the score is positive, team 2 wins if the score is negative, and a zero score is a draw/tie.
Movement over the top and bottom edges has no effect on the score.
The game lasts for 2000 time steps (each bot provides 2000 moves). If there is no winner by the end of the game it is extended by up to a further 1000 moves, with the game ending if either team scores.
Physics
Physics is the main obstacle to real world toroidal soccer, and will not be respected in this game. The physics have been simplified as much as possible to hopefully allow games to be viewed live.
This is a non-contact sport. Bots pass straight through other bots (of either team) with no interaction. Each bot can only interact with the ball.
The playing field is a continuous rectangle of width 100 and height 50. The bots and the ball have radius 1. Bots and ball can move freely in any direction without meeting a boundary - the edges of the field wrap. The ball will rebound from any bot if their circumferences overlap.
Turning and acceleration
Due to the use of simplified physics this is quick to explain:
A bot has a facing angle and a velocity. A constant acceleration applies in the direction specified by the facing angle. Drag is a deceleration proportional to the velocity (an acceleration in the opposite direction to the velocity, proportional to the size of the velocity). This means a bot that does not turn will accelerate to a maximum velocity where the drag matches the acceleration.
A bot can turn any angle instantaneously, but the velocity (and hence direction) will only change gradually. For example, a bot changing direction by 180 degrees will continue travelling backwards while it slows down to zero velocity, and then accelerate in its new direction.
The ball has no acceleration of its own, so other than collisions, its only change in velocity is due to drag. There is no spin.
Collisions
Only the ball can be involved in a collision with a bot - bots pass straight through each other.
Although the radius of both bots and ball will be displayed visually as 1, I believe the results are the same if collision calculations are based on the bots having radius 2 and the ball being a point.
To keep calculation simple, the ball will be tested for collision with each bot by considering the bot to be a circle moving with constant velocity and the ball to be a point moving with constant velocity (that is, the acceleration will occur at instants, rather than continuously over time). Since this is also how the motion will be modelled generally, the collisions should be consistent with the motion of objects in the game.
This allows the exact point of collision to be calculated so the rebound can occur with no overlap.
Communication
There is no communication between bots. Each bot communicates solely with the controller.
The communication method will depend on the controller type (language agnostic/specific). Players will either be functions/objects in a specific language, or separate programs that communicate through STDIN/STDOUT.
Each step all bots will be supplied with the same information, and will provide a facing angle which will be a float in the range [0, 360).
The information supplied to bots will be as follows.
- Team direction (
1
for team 1 or -1
for team 2)
- Current score (positive if team 1 is winning, negative if team 2 is winning)
- Facing angle and velocity of itself
- Facing angle and velocity of 4 team mates
- Facing angle and velocity of 5 opponents
Facing angle will be given as a float.
Velocity will be given as x and y components, so two floats.
The information will therefore be received as two integers followed by 15 floats.
Sandbox questions
- Are any terms not familiar that would be worth linking or further explaining?
- Are there any further simplifications that could be made, without detracting from the game?
- Are any of the simplifications too much? Am I overlooking some way in which the game could become trivial?
- Is it correct to model the bots as radius 2 and the ball as a point? Does this give identical results to modelling the bots as radius 1 and the ball as radius 1?
- Are there any problems likely to arise from basing collision detection on constant velocity bots and ball? (Acceleration being applied instantaneously each step, rather than spread out over continuous time.)