release-0.1.2

pong-client

release-0.1.1

release-0.1.0

release-0.0.9

release-0.0.8

release-0.0.7

release-0.0.6

release-0.0.5

release-0.0.4

release-0.0.3

A multi-player version of the classic Pong game. This project started as an exercise to implement a very simple
use of the case of the Unity physics engine, then evolved in to an exercise in multi-player code.
<h3 id="the-challenge">The Challenge</h3>
Keeping multiple game states in sync over a network with lag and with (in some cases) non-deterministic physics
behaviour [<a href="#marked-fn:1">1</a>].
<h3 id="architecture">Architecture</h3>
A client/server architecture was developed that allowed for optimized network utilization.
The Server
The server is a <a href="https://bitbucket.org/furgin/pong-server">nodejs application</a> written to provide a number
of features:
<ul>
<li>It is the authoritative source of all games, which limits the scope of cheating.</li>
<li>It is a game lobby for players to join.</li>
<li>It is a transmission hub for all game traffic. This allows spectating and removes the need for clients
to set up firewalls.</li>
</ul>
The server provides a <a href="https://bitbucket.org/furgin/pong-client/src/master/Assets/Network/Protocol.proto">gRPC service</a>
that is used by the clients to share game state and share messages [<a href="#marked-fn:2">2</a>].
The server is bundled as a docker container and can be found <a href="https://hub.docker.com/repository/docker/furgin/pong-server">here</a>.
The Client
The client is a <a href="https://bitbucket.org/furgin/pong-client">unity c# application</a> written as the main game interface
for all players.
It communicates over a bi-directional stream with the server&#39;s gRPC service.
<h3 id="network-protocol">Network Protocol</h3>
The game server updates the physics of each game 60 times per second.
To minimize the network traffic, it only sends a GameState message to the clients when
<ul>
<li>The ball hits a paddle or wall</li>
<li>A player starts, or stops movement</li>
</ul>
To minimize the impact of lag, each client (using Unity&#39;s physics engine) updates the ball&#39;s position each frame. Only
when a GameState message is received from the server is the ball&#39;s position and direction manually updated. The
GameState message includes the ball position and velocity allowing the client side physics simulation to take over in
between.
The client does not implement the non-natural rebound logic, resulting in a small window of opportunity for some ball
teleportation after it hits a wall or paddle. This is generally not too bad but could be improved by implementing
the same logic client side.
<hr>
1 Ball rebounds are manipulated to make the game more interesting. Non-natural rebounds occur when the ball 
hits off center on the paddle, and when the ball hits a wall and the horizontal velocity is under a threshold.
2 The state of Unity multiplayer support is extremely confusing, with the current implementation (UNet) totally
deprecated, but the replacement in an unclear state. I also wanted to be able to write non-unity clients, so went
with an open protocol.

Server

Client

Docker

Pong

Pong

Releases