The Answer Protocol

Le projet (en cours)

Un jeu d’aventure multijoueur en mode texte, dans l’esprit des MUD (Multi-User Dungeon) des années 80. Plusieurs joueurs se connectent au même monde, se déplacent, se parlent, combattent et font des quêtes ensemble, en direct.

C’est un projet de l’École 42, en binôme et en Go. Le vrai sujet n’est pas le jeu : c’est le client-serveur et la concurrence.

Le défi : la concurrence

Un serveur de jeu fait beaucoup de choses en même temps :

• il accepte de nouveaux joueurs pendant que les autres jouent ;
• il lit les commandes de chaque joueur, sans qu’un joueur lent bloque les autres ;
• il modifie un monde partagé (salles, objets, personnages, combats) : deux joueurs qui prennent le même objet au même moment ne doivent pas le recevoir tous les deux ;
• il envoie les événements (« un joueur entre », « un combat commence ») à tous les joueurs concernés, tout de suite ;
• il gère les déconnexions proprement : l’état du joueur est retiré avant que les autres en soient prévenus.

Go est fait pour ça : les goroutines (des tâches très légères) permettent de suivre chaque connexion séparément, et les channels et les verrous (mutex) protègent l’état partagé.

Ce qu’il faut construire

• Un serveur TCP qui gère le monde et tous les joueurs.
• Un client en terminal et un client graphique, qui restent fluides pendant qu’ils reçoivent des messages du serveur.
• Un protocole commun, écrit comme une RFC (le format des documents qui décrivent les protocoles d’Internet). Nos clients doivent marcher avec les serveurs des autres équipes, et inversement : chaque détail du format compte.
• Des logs structurés (en JSON) : connexions, commandes, réponses, changements du monde, et détection des abus (par exemple un client qui envoie trop de commandes). Sans ralentir le serveur.

Ce que je vais y apprendre

• La programmation réseau et la concurrence en Go, sans conditions de course (race conditions : deux tâches qui modifient la même donnée en même temps).
• Écrire une spécification assez précise pour que d’autres équipes l’implémentent sans nous parler.
• Rendre un serveur observable grâce à ses logs.

Cette page sera complétée quand le projet sera terminé.