Air hockey - solution

task description

Air hockey was a long-running real-time multiplayer game. There is no official solution as there are various possible strategies and mallet control methods.

Simple client

Our simple client used three basic ideas:

Visualization: draw the pucks and everything and make the mallet easy to control manually. (send a command after every update fragment).
Find and mark dangerous pucks: if a puck trajectory intersects with the goal line or a small circle around it then that puck should be blocked.
Automation: use simple PD controller to move the puck to a specific location automatically:
```
err = target - malletpos
accel = Kp*err - Kd*malletvel
```
For some well chosen positive Kp and Kd consts.

Networking - protocol design

One may wonder what all this complicated networking setup was about (UDP packets and TCP control connection).

The reason we used UDP broadcast was

to reduce latency (if a packet is lost we don't want it to be retransmitted, because it will be invalid by the time it arrives),
to reduce bandwidth requirements (without using broadcast our server would had to output 30x more data: sending the state to every team separately instead of relying on the switch to do it).

This meant that we could make the game reasonably fast and send updates at high rate (20Hz).

The control commands and game parameters require much less bandwidth and better be done over a reliable transport so a TCP connection was used for that.

The size of each UDP packet was around 1400 bytes which was chosen so no fragmentation was possible. (UDP packets get fragmented according to the MTU size of the network and the OS of the client has to wait for each fragment and put them together before presenting it to the application, increasing latency. If any fragment is lost the entire state update is lost.)

Unfortunately it cannot be guaranteed that control commands arrive in the right time slice which could hinder real-time control of the mallet. (Although the 50ms between status updates should be enough normally). As a solution we planned to change the control command syntax to

ax ay timetick

This makes it possible to specify a sequence of acceleration commands in advance (until a few time ticks into the future, and commands for future timeticks are modifiable). We didn't have time to implement this but fortunately there were no serious packet loss issues during the contest.