-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
netPong meets the assignment requirements: two processes play a full networked game over TCP, with the SPPBTP handshake, ball handoff, scoring, and a clean endgame. The Phase 3 report documents a few items from the RFC that I did not implement. They are the obvious next work, so I list them here with what each would take.
Right now the keyboard only works while the ball is on your court. In WAIT the local process blocks on recv_msg(), so a Q press does not register until the ball comes back. The assignment marks immediate input during WAIT as extra credit through select() or poll().
The fix is to replace the blocking read in run_wait_loop() with a select() over both the socket and standard input. The PLAY loop already peeks the socket with a zero-timeout select(), so the same idea applies in reverse during WAIT. The physics ticker would still stay off in WAIT; only the input and socket readiness would be watched together.
wait_for_client() closes the listening socket right after accept(), so one launch serves one game. The assignment item about the server returning to waiting mode is not implemented. To support back-to-back games, the server would keep the listening socket open, loop back to accept() after a game ends, and reset the game state for the next client.
When the server reads an unexpected or malformed line, it replies ?ERR and closes. A friendlier design would let ?ERR ask the peer to resend the last message, or resynchronize the state, instead of ending the game. That needs a small acknowledgment step in the protocol and a place in the state machine to retry.
- A title or menu screen before the handshake, so a player can pick the number of balls instead of using the fixed default.
- A configurable court size negotiated in
HELO, using thenet_heightfield that the handshake already carries but the engine currently ignores. - A reconnect path so a dropped TCP connection does not end the match outright.