Battle is a distributed framework which allows users to programme the control algorithms for a robot, then run it within a simulation, to see how it performs against other robots.
The framework consists of a server (Server.exe), which runs the simulation. A viewer client (Viewer.exe) can be used to connect to the server, to view the state of the simulation. An API is provided which can be used to programme a robot controller client. The controller client connects to the server, inserts a robot, then sends it commands to control how it acts within the simulation environment. The API is provided in both C++ and C#.
The following development environments are supported for creating robots:
If you aren't using Visual Studio 2003 or 2005, then to run the viewer and other utilities you will need v1.1 of the .NET framework. The framework includes the free csc command-line compiler. You will also need v2.0 of the .NET framework if you wish to do .NET 2.0 development using the command-line compiler. You can download the framework from Microsoft at http://www.microsoft.com/net.
Visual Studio 2005 Express is a free version of Visual Studio 2005 which can be downloaded from Microsoft at http://msdn2.microsoft.com/express.
To use the 3D display option in the viewer, you will need DirectX 9 or newer, and a reasonable 3D video card. If you have Windows XP you may already have a sufficiently recent version of DirectX. Otherwise, you can download DirectX from Microsoft at http://www.microsoft.com/directx.
Running a sample simulation
The basic steps to run a sample simulation are as follows:
When first started the viewer defaults to 2D mode. In this mode the rendering of the simulation can be moved by dragging it with the left mouse button. The mouse wheel can be used to zoom in and out.
To switch to 3D mode, use View -> 3D. In this mode dragging with the left mouse button can be used to move the world (ie pan the camera), the mouse wheel can be used to zoom in and out, and dragging with the right mouse button changes the view angle.
While in 3D mode, if you choose the View -> Follow Selected Robot menu item and then select a robot in the list at the top left of the display, the camera will follow the selected robot.
Use View -> 2D to switch back to 2D mode.
Creating your own robots
The sample robots are the best place to start to work out how to configure robot projects, and how to use the API to develop a robot.
The following are the steps to create a robot console application in your choice of language (C++ or C#):
The general stages of a robot controller programme are as follows:
Every method on the Controller API class sends a message to the server, then waits for a response from the server, before the method returns. For the methods which are used while the robot is in its simulation loop, the server will pause (therefore also pausing the client) if it has been less than 1/30th of a second since the last message was received. This means that the client can only send up to 30 messages per second, so it needs to make the most of the API methods it decides to call.
The playing field within which the simulation takes place is a rectangle with a specified width and height, shown as the dark blue rectangle in the viewer. The dimensions of the playing field can be queried using the Controller API. Currently this is 30 metres wide by 20 metres high, but this should not be assumed to stay constant.
The coordinate system used by the simulation for positions places the origin (x = 0, y = 0) at the centre of the playing field. Positive x is to the right, and positive y is down.
The orientation of a robot is the angle in radians which the robot makes with the positive x axis, increasing positively in the clockwise direction. So if the robot is facing right, its orientation is 0. If it is facing down, its orientation is pi/2, if it is facing up, its orientation is -pi/2. There is a discontinuity at the point where the robot is facing left, since the angle wraps around from -pi to pi.
The orientation of the sensor and turret are specified in radians, relative to the robot's orientation. So an orientation of zero means pointing in the same direction as the robot. An orientation of pi/2 means pointing directly to the robot's right, and -pi/2 means pointing to the left, etc.
The following formulae can be used to convert between radians and degrees:
radians = degrees * pi / 180
degrees = radians * 180 / pi
The robots are modelled as if they are 1 metre long and 60 centimetres wide, with a turret 1 metre in length. For the purpose of collision detection between robots and other robots, munitions and the playing field boundaries, the robots are treated as circles with a radius of 60 centimetres.
Often it is difficult to visualise whether your robot is doing what you want, simply based on what it is doing in the viewer and any text your robot console app might be printing. For this reason an additional server and client API are provided which make it possible to debug your robot graphically.
C++ robots can use it by adding an additional linker input of [path to API]GraphicsNN_d.lib in Debug mode and [path to API]GraphicsNN.lib in Release mode, as well as including Graphics.h. NN is 60, 71 or 80 for Visual C++ 6.0, Visual Studio 2003 (v7.1) or Visual Studio 2005 (v8.0) respectively. C# robots can use it by adding a reference to Graphics11.dll or Graphics20.dll for Visual Studio 2003 (.NET 1.1) or Visual Studio 2005 (.NET 2.0) respectively.
GraphicsServer.exe is the server application. Run it, select File -> Start then click Start. The server will now wait for a client connection. Note that only one client can be connected at a time.
The comments in Graphics.h and the sample usage in the simple robot samples should be sufficient to work out how to use the API. Essentially you create a graphics client object, connect, then send commands to draw shapes.
The graphics server has the same mouse control as the battle viewer, ie left mouse drag to move the display, and mouse wheel to zoom in and out.
It is probably a good idea to make it possible for you to turn
off your robot's use of the graphics API, because the graphics
server won't be running in a public robot battle. The simple
robot samples use a command-line parameter to control whether
to use the graphics API, defaulting to off. The following batch
files are provided to run the simple robots with the graphics
API turned on:
In its normal mode of operation, the simulation runs continuously. Robots enter when they connect and start at a random position in the playing field. When running a competition between robots the basic approach is to run all robots at once so they enter the game at roughly the same time, and then award points and/or placings based on the order in which they leave (ie are killed).
One disadvantage of this approach is that it can be unfair - if the initial starting position of a robot is in the middle of a pack of other robots, that robot is at a disadvantage. Also, robots which enter the simulation late (either intentionally or because other robots' exes happened to be spawned first) will gain an advantage by being attacked for (slightly) less time.
The solution to this is the server administrator (ServerAdmin.exe). This can be used to control running tournaments consisting of one or more rounds, in a way which is fair. To use:
The administrator uses the name and owner of robots to distinguish between them. Therefore the combination of name and owner of each robot must be unique. If there is a duplicate, a warning message is displayed in the Notes column.
If you have a tournament consisting of multiple robots developed by the same owner, you can choose View -> Owner Scores to reveal additional columns containing the total points of all robots of each owner, and also each owner's ranking based on those points.
By default when the server is run it listens for connections on port 9386. To run the server on a different port, use the /p command-line option:
Server /p [port]
Server /p 2801