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. 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, lors de mes recherches dans le cadre d’un projet de jeu multijoueur pour navigateur, le projet Colyseus.io qui a retenu mon attention. Débuté 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, autant en tour par tour qu’en temps réel. Il est trouvable sur Github et est publié sous licence MIT.

De nombreux projets sont aujourd’hui backés par un serveur basé sur Colyseus, assez pour considérer cette option lors d’une étude pour un nouveau projet.

 

Pour rentrer dans le vif du sujet, qu’est ce 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 (Javascript, Defold, Haxe, Cocos2d, Unity3d, etc.) qui vous permettront de communiquer avec le serveur.

 

Les interactions entre les clients et le serveur se font via Websocket.

 

La plus grande force pour moi de cette librairie réside dans deux choses :

  • 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.

 

Le projet présente néanmoins à mon sens un inconvénient majeur : il est 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 dans la figure. L’API Javascript ne présentant pas de système de « switch automatique de serveur », 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.

 

En conclusion : 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.