Au delà des aspects fonctionnels, de gamedesign, graphisme, son et autres évidences, le développement de jeux en ligne pose souvent des problématiques quand à la gestion des ressources réseau.
Ils sont sujets à de nombreux débats la façon d’aborder le système de « salles » de jeux, le matchmaking, ou encore la manière de faire parvenir à tous les joueurs d’une partie les mêmes informations, le tout avec une emprunte réseau et CPU minimale.

J’ai découvert il y a peu dans le cadre d’un projet de jeu multijoueur pour navigateur Web, le projet Colyseus.io.

Démarré fin 2015, le projet en est aujourd’hui à sa version 0.13 et offre une structure solide. Bien que minimale pour la création de serveurs de jeux multijoueurs / tour par tour en temps réel, il est trouvable sur Github et est publié sous licence Opensource MIT.

Aujourd’hui de nombreux projets utilisent un serveur basé sur Colyseus : assez pour considérer cette option lors d’une étude pour un nouveau projet.

Que fait Colyseus et comment ?

Le projet, comme toute base d’un jeu multijoueur, se décompose en deux parties :

  • Une librairie serveur, basée sur NodeJS, qui permet de créer toutes les ressources nécessaires pour les échanges de données entre clients, ainsi que la persistence de ces données.
    Colyseus vous permet plus concrètement de créer des types de « Room » qui ont un ensemble d’attributs et une logique propre pour gérer les clients qui s’y connecteraient. Une Room est en clair un serveur de jeu, avec un état et des joueurs connectés, et qui aura la charge de dispatcher à tous ses clients toute modification de son état.

  • Un ensemble de librairies client compatible (Javascript, Defold, Haxe, Cocos2d, Unity3d …) qui vous permettront de communiquer avec le serveur.

L’ensemble des interactions entre les clients et le serveur se font via Websocket.

Les forces

  • Sa capacité à gérer toute seule les Rooms : lors de la création d’une room, on peut lui attribuer un nombre maximal d’utilisateurs. Si un client essaie de rejoindre « n’importe quelle Room de ce type », le serveur lui attribuera automatiquement une Room de ce type dans laquelle des places sont libres. Sinon, il lui créera une Room et l’y connectera.

  • Sa capacité à répliquer chez tous les clients l’état de la Room dans laquelle ils se trouvent avec un impact réseau minimal, le serveur n’envoyant à tous les clients que le delta de son état.

Les faiblesses

  • scalable, certes, mais pas sans utiliser le projet « colyseus-proxy » qui va avec. Impossible donc de faire une vrai répartition de charge entre serveurs (ce qui n’est pas si grave) et surtout, vous aurez toujours ce proxy en front, c’est donc lui qui prendra tout votre trafic de front.

  • L’API Javascript ne présente pas de système de « switch automatique de serveur ».
    Je m’explique : dans le cas où vous seriez connecté sur un serveur et où le matchmaking voudrait vous mettre en relation avec une Room sur un autre serveur, vous devriez vous connecter dans un premier temps à ce serveur, et ensuite rejoindre la Room attribuée par id, pour éviter de recommencer ce rodéo indéfiniment.

Conclusion

Il s’agit d’un petit projet très sympatique si vous voulez développer rapidement un jeu en ligne, mais avec son lot de problèmes de scalabilité.

Rien de très méchant, la majorité des problèmes rencontrés étant des cas particuliers qui se résolvent facilement en éditant la librairie, sous licence MIT, rappelons-le.