Retour d'expérience sur le développement d'un jeu amateur

Je me suis lancé en 2005 avec un ami dans le développement d'un jeu par navigateur Web : Simerion. Il s'agit d'un jeu mélangeant à la fois le genre RPG et gestion. L'idée étant d'endosser le rôle d'un colon fraîchement envoyé sur de nouvelles planètes. Chaque joueur choisit un métier, et le principe est simple : du RolePlay, tout le monde fait ce qu'il veut, tout est possible. Bref, dans le principe, le jeu idéal, mais hélas pas forcément en pratique.

J'ai quitté l'équipe de Simerion, après cinq ans de conception et de développement, en 2009 mais pour différentes raisons que j'aborderai plus loin. Mais je profite de cet article pour faire une sorte de bilan du projet, de mon point de vue. L'idée étant de faire un retour d'expérience afin de pointer du doigt ce que nous avons pu apprendre mais aussi afin de mettre en évidence les erreurs que nous avons commises. Le tout dans l'espoir de pouvoir aider des personnes s'engageant dans un projet similaire. Tout d'abord, je précise que le jeu n'est pas arrêté. Il est toujours en développement, je n'ai fait que quitter l'équipe. Donc si mon article vous donne envie d'en savoir plus ou de rejoindre l'équipe de développement, n'hésitez pas à vous rendre sur www.simerion.fr.

Tout d'abord, un rapide historique :

• 2005 : Wett et moi-même avons ressorti du fond d'un tiroir les bases d'un projet que j'avais esquissé deux ans plus tôt. Durant cinq mois nous mettons ainsi à plat toutes nos idées sur un forum et wiki. Mais très rapidement nos études respectives (classes prépa) nous ont poussés à mettre en pause le projet ;
• juillet 2006 : un an plus tard, nous reprenons notre projet en main et continuons à travailler sur la conception durant un mois de manière soutenue ;
• août 2006 : nous commençons enfin le développement et devenons membres de l'association Nainwak qui nous hébergera par la suite ;
• août 2007 : un an plus tard, avec l'aide d'Altheran qui nous a rejoints en mars, nous sortons notre première version alpha avec une cinquantaine de joueurs ;
• mars 2009 : plus d'un an et demi plus tard, la bêta sort alors que je quitte l'équipe. Voici donc une suite de points, qui maintenant avec le recul me semblent importants à souligner.

À travers ce projet, j'ai pu découvrir la nécessité de travailler à plusieurs. Et cela pour diverses raisons. Tout d'abord afin de s'entremotiver lorsque certains d'entre nous sont découragés. Voir d'autres personnes travailler sur le projet peut très facilement nous remonter à bloc. Le développement d'un jeu Web comme Simerion ne doit pas se faire en comité réduit. Attention l'effet inverse n'est pas pour autant une bonne idée. S'entourer de trop de monde peut être néfaste pour le projet. Il faut prendre le juste nombre de programmeurs, en prenant en compte leurs disponibilités et leurs compétences.

Notre choix s'est porté initialement sur le PHP couplé à de l'Ajax afin de bénéficier d'un jeu accessible partout depuis Internet avec une grande interaction avec les joueurs. Pourquoi le PHP ? Parce que ce langage m'était déjà familier et était simple à prendre en main. Cependant avec le recul, nous n'aurions sans doute pas dû employer celui-là, préférant sans doute le JAVA ou le C++ afin de réaliser un véritable MMORPG. À maintes reprises nous nous sommes mordu les doigts quant à notre choix de technologie. Nous avons très rapidement atteint les limites du PHP et de l'Ajax. Notamment dès que nous avons souhaité intégrer une interaction temps réel entre joueurs. Nous avons été bridés par nos choix initiaux qui ne nous ont pas permis pleinement de faire ce que nous souhaitions réaliser. Mais il était trop tard pour changer. Je conseille vraiment au départ de faire le tour de toutes les technologies lorsque l'on s'aventure dans un projet Web d'ampleur. Chaque langage possède ses avantages et inconvénients qu'il faut comparer. Nous ne l'avons pas fait, et cela nous a desservis. Dans ce genre de cas, il est même profitable de réaliser un PoC (Proof of Concept) en amont pour valider ou non une technologie, API, etc. Et cela pour éviter les mauvaises surprises et jauger la qualité, puissance d'un choix par rapport à un autre.

Une autre erreur que nous avons commise a été de ne pas faire le tour des Frameworks PHP et Ajax existants. En jeunes fous que nous étions, nous avons créé notre propre moteur de jeu de A à Z et notre propre Framework Ajax. Nous avons réinventé la roue et avons perdu un temps fou. D'un autre côté, nous ne savions pas forcément que des outils tout faits existaient, cela nous a toutefois permis de comprendre le fonctionnement d'un certain nombre de techniques et technologies. Mais si c'était à refaire, j'utiliserais au maximum des outils déjà disponibles. Avant de commencer un projet d'ampleur, je pense qu'il faut vraiment regarder, comparer les outils à sa disposition et ne pas foncer dans le tas tête baissée. Utiliser des outils déjà faits peut faire réellement gagner un temps précieux.

L'utilisation de diagrammes UML est assez primordiale. Il est difficile d'être rigoureux sur la durée afin de mettre sur papier les idées avant de coder. Mais c'est un mal pour un bien au final, car c'est un gain de temps non négligeable. Toutefois les diagrammes UML ne sont utiles que si l'on ne change pas d'idée en permanence. Auquel cas, les diagrammes sont en permanence remis en cause, ce qui est pour ce coup-là une grosse perte de temps.

L'approche objet d'un jeu Web est assez complexe. À première vue, le "tout objet" peut sembler être une bonne chose, mais les objets ne sont pas les amis des bases de données. Qui dit objet, dit attributs, et qui dit attributs dit base de données derrière chargée et mise à jour en permanence. Travailler avec les objets et leurs instances implique d'optimiser en permanence le code afin que le serveur ne s'écroule pas sous les requêtes SQL. Par exemple, si je veux charger une instance d'appartement d'un joueur dans Simerion, nous devons charger un objet qui va définir son type (classe), puis un objet qui va définir son instance de conteneur (bâtiment) ainsi que la classe de celui-ci. Vu que nous avons besoin parfois de localiser cet appartement, nous avons besoin de charger la région dans laquelle se trouve notre bâtiment (une table supplémentaire). Comme il y a plusieurs planètes il faut également charger sur quelle planète se trouve cette région (une table de plus). Au final la création d'un objet devient faramineuse en termes de ressources, nécessitant une flopée de requêtes SQL. Imaginez comment charger des collections entières d'appartements... De quoi mettre à terre le serveur. Nous sommes alors obligés d'optimiser en nous éloignant peu à peu du système classique d'objets. Travailler en objet est intéressant, mais dès que l'on se met à travailler sur des pages qui vont recevoir énormément de visites, l'intérêt en prend un sérieux coup. Je pense qu'il n'y a pas de solution absolue et qu'il faut privilégier les objets pour la maintenabilité du code. Par contre, en ce qui concerne le lien avec les BDD, il faut trouver un compromis et essayer de s'éloigner du schéma classique qui consiste à tout charger lors de la création de l'objet. Je pense qu'il suffirait de regarder du côté des gros Frameworks ce qu'il se fait en la matière. La liaison avec la BDD est une chose assez pointilleuse et complexe, je pense que même au bout de cinq ans, le code n'est pas optimisé au maximum de ce côté-là. Par conséquent, aller voir les outils qui existent déjà peut être d'une très grande aide.

Une des choses qui nous ont fait le plus perdre de temps a été la permanente remise en question de notre code. C'est bien plus facile à dire qu'à faire, mais il faut à tout prix se contenter au plus tôt de son travail pour aller de l'avant. De la même façon, il faut éviter d'optimiser à mort tout et tout de suite, il faut le faire au fur et à mesure en trouvant un juste milieu. J'aborderai plus loin la question du travail étape par étape, mais il est très très important, d'après l'expérience que j'ai tirée de Simerion, de se contenter de ce qui fonctionne et aller de l'avant pour avoir du concret et non pas du code en permanence remanié. Une fois que le code fonctionne, il est alors possible de l'optimiser, mais il faut viser à mon sens le fonctionnel avant de foncer tête baissée sur la sécurité et l'optimisation du jeu.

Le choix de notre cycle de développement n'a définitivement pas été le bon. Et ce dernier est à mon sens la raison de notre (mon) échec. Cinq ans ! Nous avons passé cinq ans sur ce projet et toujours pas de jeu jouable en version publique à mon départ... C'est entre autres une des raisons de mon arrêt. C'est même un exploit d'avoir tenu aussi longtemps. Nous avons choisi en effet de n'ouvrir le jeu que lorsqu'une version du jeu serait suffisamment jouable pour retenir le joueur. Or, le principe de Simerion est de pouvoir tout faire. Tout est interdépendant, et tout s'équilibre. Il est alors impossible de sortir une version jouable tant que TOUT le jeu n'a pas été programmé. Quelle erreur nous avons faite ici ! Dès que le concept est posé sur papier, un jeu amateur doit, selon moi, sortir au plus vite en production. À la fois pour avoir des retours des joueurs, mais aussi afin de se motiver dans son travail de développement. C'est extrêmement déprimant de ne pas avoir de retour de joueurs avant des mois, voire des années dans notre cas. La motivation est naturellement en constante baisse, et pas un joueur pour vous rebooster. Il ne faut compter que sur les membres de l'équipe qui eux aussi sont en manque de motivation. Donc vraiment je conseille vivement de développer les jeux Web sur des versions fréquentées par les joueurs (tout du moins pour les jeux amateurs). Il faut sortir régulièrement les versions de développement et surtout ne pas attendre aussi longtemps que nous entre chaque version. En faisant cela, on entretient la communauté de joueurs qui nous supporte et nous est très utile, et on entretient notre motivation dans le projet. Sans cela, tout s'effondre au bout de X mois ou années. Et tout l'investissement aura été vain.

Comme je le disais précédemment, il est nécessaire de s'entourer dès le début d'une communauté de joueurs. Ces derniers pourront tester votre jeu, donner leur avis, proposer leurs idées d'améliorations, etc. N'ayant pas lancé de version jouable durable de Simerion, nous n'avons pas eu de communauté derrière nous pour nous soutenir dans notre développement. Et c'est une conséquence très négative, qui va avec notre mauvais choix de cycle de développement. Je conseille donc vraiment de travailler dès le début à la création d'une communauté entourant le projet à la fois pour y puiser de la motivation, mais aussi afin de se faire aider. Car bien souvent, la communauté gravitant autour de votre jeu est source de nouveaux membres pour votre équipe de développement.

Cela fait mal à dire, mais la création d'un jeu RPG complexe n'est pas à la portée d'une équipe d'amateurs. Qu'on me montre le contraire et j'en serai ravi ! Mais le fait est que la création d'images, de décors, d'histoires, de scénarios, de quêtes et de missions nécessite un travail pharaonique. J'ai, les 95 % du temps, endossé le rôle du développeur, du scénariste et de l'illustrateur à la fois. Ceci est quasiment impossible à gérer dans un tel projet. Idéalement, il faudrait avoir dans son équipe au moins un graphiste / illustrateur et plusieurs scénaristes pour remplir le jeu. Mais il s'agit d'atouts rares, et il faut bien souvent ne compter que sur soi même. Sur cet aspect, je suis assez pessimiste hélas, je pense que des jeux de l'envergure de Fallout, Baldur's gate, Final Fantasy, ou même Zelda n'auraient pas pu être réalisés par des amateurs. Cela demande trop de travail en dehors de la partie programmation. Le jeu ultime est à mon sens impossible à développer par des amateurs, hélas... À mon sens, un jeu amateur ne doit pas voir trop gros dès le départ. Il faut y aller au fur et à mesure, en se faisant plaisir et tout en gardant à l'esprit que nous ne pouvons pas rivaliser avec les grands. Le jeu ultime amateur n'est pas réalisable, cela demande beaucoup trop de travail. Avec Simerion nous sommes partis sur un concept trop complexe, trop utopique... La clé de la réussite est un cadrage dès le départ qui trouve un compromis entre un concept novateur et le minium de code possible.

Un point important dans le cycle de développement réside dans la tenue d'un cahier des charges et d'une documentation à jour. En effet, il n'est pas rare de mettre en pause le projet pendant X mois. Et reprendre le code après une période d'inactivité est vraiment très difficile (même pour du code tapé soi-même). Le cahier des charges permet de garder une vue globale sur le projet avec un certain recul, il vous permet de poser au clair toutes les idées et mieux structurer ses idées. La documentation permet, elle de son côté, d'expliquer le fonctionnement du jeu (aspect technique) mais aussi d'expliquer pourquoi tel ou tel choix d'algorithme. La documentation peut vous faire gagner un temps fou pour vous remettre dans votre code, ou pour comprendre le code d'un autre programmeur. Ces deux outils permettent également l'intégration de nouveaux membres à l'équipe de développement (chose à laquelle on ne pense pas forcément). Le fait est que Simerion est devenu une véritable usine à gaz et que plusieurs personnes se sont cassé les dents à essayer de comprendre notre code pas toujours commenté ni expliqué. Le manque d'explication peut alors être un frein au recrutement de nouveaux développeurs.

Nous avons rejoint dès le départ l'association Nainwak, qui nous a hébergés, soutenus et conseillés. Nous n'aurions sans doute pas tenu autant de temps sans elle. Nous avons même eu la chance grâce à elle d'être exposants à deux reprises au festival du jeu vidéo. Nous avons pu rencontrer des professionnels qui ont été intéressés par notre jeu. Ce fut une expérience très enrichissante. Je conseille vivement à toute personne se lançant dans un jeu Web sérieux de contacter Nainwak. La mission de cette association est d'aider les amateurs, et elle y travaille à merveille.

XIII-A. En 2009, lors de mon départ▲

XIII-B. En 2012, trois ans après avec un peu plus de recul▲

XIII-C. Publication des images en Creative Commons BY 3.0▲

Simerion est sur le point de fermer (juillet 2012) et j'ai réalisé qu'il serait réellement dommage de perdre toutes ces tiles qui nous ont pris tellement de temps à réaliser. J'ai décidé de les publier toutes sous licence Creatives Commons BY 3.0. Étonnant de voir comment mon rapport au Libre a évolué depuis 2005. Le contexte s'y prête beaucoup ici aussi. Mais je m'amuse à repenser à l'enveloppe Soleau que j'avais déposée à l'INPI pour "protéger" mon travail à l'époque.

Vous pouvez retrouver les tiles :

• sur mon blog ;
• sur OpenGameArt.org ;
• via l'article posté sur DVP à ce sujet.

Je remercie LittleWhite et ClaudeLELOUP pour leur relecture.