Retour au récit
Chapitre I2021Archivé
Première partie
Un jeu vidéo, une équipe de quatre, et le réseau à faire tenir
Contexte
Un jeu multijoueur construit à quatre, en C# sous Unity. J’étais en charge du multijoueur : la partie qu’on ne voit pas, et celle qui casse.
Mon rôleDéveloppeur — responsable de la partie multijoueur
Période2021
Technologies
- C#
- Unity
- Git
Le problème
Un sujet volontairement fun pour un premier projet d’équipe — sauf que le multijoueur ne pardonne rien. Deux machines, deux horloges, et un état de jeu qui doit rester le même des deux côtés.
La réponse
J’ai pris le réseau et je m’y suis tenu : synchronisation de l’état, gestion des connexions, et des parties jouables à plus de dix. Le reste de l’équipe couvrait les niveaux, le design et l’interface — et il a fallu apprendre à travailler sur un dépôt commun sans s’écraser.
Résultats
0personnes dans l’équipe
0niveaux construits
0+joueurs en simultané
En images
Ce que j’en ai tiré
- 01Un projet à plusieurs se joue sur le dépôt avant de se jouer sur le code.
- 02Le multijoueur apprend brutalement qu’un état partagé n’existe pas : il se négocie.
- 03Choisir un sujet qui amuse l’équipe est une décision de projet, pas un caprice.
Ce qui a résisté
- 01Aucune expérience de Git à quatre : les premiers conflits ont coûté plus cher que les bugs.
- 02Une latence qui rendait injouable ce qui fonctionnait parfaitement en local.