MultiQuest est pour moi un projet de longue date que j’ai commencé lors de ma 2ème année de DUT aux alentours de Février 2015. J’ai commencé avec une approche très naïve c’était juste un jeu en local à la base.

J'ai commencé avec le Framework Slick2d mais je me suis rapidement tourné vers LibGDX car Slick2d était trop limité et n’était plus mis à jour. J’ai commencé par développer tout plein de fonctionnalités, les monstres, le système d’inventaire, les différentes attaques puis enfin le passage au multi-joueurs. Le réseau c’était un vrai challenge pour moi. J’avais déjà fait un mini jeu en réseau, mais rien de cette ampleur. Alors j’ai fait des erreurs mais j’ai beaucoup appris. Et quand pour la première fois j'ai pu voir deux joueurs partager le même monde c’était un moment magique pour moi.

Au fil du développement, je me suis rendu compte que le projet devenait de plus en plus complexe et qu’il avait besoin d’une meilleure structure afin de pouvoir évoluer par la suite. C'était mes premiers tests alors je codais sans vraiment me poser de questions je voulais juste que ça fonctionne. Alors ça fonctionnait bien mais le code n'était absolument pas maintenable. Il y avait beaucoup de duplication de code, de design mal pensé etc... J'avais appris des nouveaux concepts à l'université et pendant mon temps libre alors j'ai entamé mon premier réusinage de code. C'était déjà plus propre, et j'ai encore une fois appris beaucoup de choses.

Comme j’étudie à l’Université, je travaille sur ce projet durant mon temps libre il m’arrive donc de faire des pauses de plusieurs mois quand je suis débordé au niveau des cours ou tout simplement quand je n’ai pas l’envie de programmer.

Malgré mon gros réusinage, je n’étais toujours pas satisfait de ma structure de code. Je me suis heurté à d’autres problèmes de conception notamment le  problème du diamant. Ce dernier est bien connu des développeurs de l’industrie du jeu vidéo car ils ont imaginé une architecture pour pallier à ce problème l’ECS ou « Entity Component System ». J'ai donc lu pas mal d'articles concernant cette façon de programmer, qui favorise la composition (J'ai) à l'héritage (Je suis), et j'ai été séduit par le concept.

Je me suis tourné vers un autre Framework en plus de LibGDX : Ashley afin que mon code bénéficie des avantages d'une architecture en ECS. J'ai donc du adapter tout mon jeu pour qu'il suive l'architecture ECS. Ce fut long et éprouvant mais c’était une étape nécessaire pour avoir des bases stables et pouvoir faire évoluer le jeu par la suite. J’ai pu par exemple, en plus d’avoir un système beaucoup plus flexible introduire des tests dans le jeu, chose qui était totalement absente dans l’ancien système.

Enfin j’ai du réusiner la toute la partie réseau car elle était dépendante de l’ancien système.

J'ai changé de méthode en passant d'un système d'envois de commandes (Je vais à gauche, j'attaque etc...) à un envois d'états (J’appuie sur la flèche du haut et sur mon clic gauche). C'était nécessaire car le jeu se veut en temps réel. Je suis donc aussi passé à 90% sur le protocole UDP et j'ai réduit l'utilisation du protocole TCP au strict minimum. Le système est basique pour le moment mais ça marche.

Il reste encore une bonne partie du réseau à faire depuis que j'ai changé d'architecture. Notamment la partie inventaire et l’optimisation de la bande passante dans les mois à venir.

Bien sur même si travailler sur l’architecture du code peut être très intéressant, cela peut avoir l'effet inverse et me démotiver si je n'avance plus car j'ai l'impression de ne pas faire correctement les choses. C'est pourquoi j'essaye de trouver un juste milieu entre rajouter des fonctionnalités, quitte à avoir plus de travail si je dois réusiner le code par la suite, et réfléchir à une architecture encore plus stable.

Tout cela étant fait en parallèle de mes études et d’autres projets de jeux je ne garantis pas que les mises à jours seront régulières. En tout cas en ce moment, je travaille sur le jeu dès que j’ai du temps libre, alors c'est plutôt bon signe !