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:

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

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.