Une expérience humaine

La première chose que je dois dire, c'est le plaisir que j'ai eu à travailler avec l'équipe Orasus. L'avantage du jeu vidéo, c'est qu'on travaille avec des gens qui ont des talents très variés, du scénariste au graphiste en passant par le game designer et le sound designer.  On découvre donc des gens avec des idées différentes, des points de vue différents, et c'est certainement ce qui est le plus passionnant dans cette aventure qu'est la réalisation d'un jeu vidéo.

L'équipe d'Orasus a beaucoup changé au cours du temps, parce qu'au début l'idée n'était pas la même, parce que j'ai fait des erreurs, et parce qu'avec le temps certains sont partis pour différentes raisons. Au final, l'équipe qui a réellement travaillé sur le projet était constituée de huit personnes (1 chef de projet, 2 développeurs, 2 graphistes, 2 scénaristes, 1 game designer). Outre l'aspect gestion de projet que je développerai plus tard, j'ai surtout pu rencontrer des gens intéressants à tout point de vue, avec d'autres visions du jeu vidéo. L'avantage (et peut-être était-ce un inconvénient ? ), c'est que les membres du projet n'ont pas été que des collègues de travail, mais aussi des amis.

Un défi technique

Le gros problème du projet Orasus, et la principale raison de son arrêt prématuré, se situe au niveau technique. Réaliser un RPG, c'est en effet un travail énorme, tant au niveau technique pur qu'au niveau du game design et du scénario. Le contenu d'un RPG doit être énorme pour être intéressant, tout comme le gameplay doit être approfondi. Pour une équipe amateur, en télé-travail, c'était à mon avis utopique. Mais l'avantage, c'est que nous avons pu voir à quoi ressemble la charge de travail d'un vrai projet de jeu vidéo. 

Du point de vue purement technique, j'ai pu profiter de ce projet pour améliorer mes connaissances en architecture de jeu vidéo. J'ai en effet développé la majeure partie du moteur de jeu (qui devrait, d'ici peu, devenir Open Source et reprendre le nom d'Orasus), en mettant à profit les compétences acquises lors de mon stage chez Strass Productions. Ce "Game Engine", qui encapsule la bibliothèque C++ SFML, possède une architecture basée sur des modules qui se raccrochent à un cœur. Cette approche permet d'avoir une architecture modulaire, en favorisant l'indépendance des différentes parties du programme. La version de démo, certes peu avancée, a tout de même permis de valider cette architecture.

Gestion de projet

La gestion de projet a été la partie la plus difficile et la plus enrichissante pour moi. J'ai en effet été confronté à de nombreuses problématiques tout au long du projet. Le télé-travail n'est pas un réel problème en soit, il incite juste à mettre en place des outils adaptés. Je l'ai fait au fur et à mesure du projet, à force de m'apercevoir que nos outils n'étaient pas les bons. La base a été le forum, ainsi que le serveur SVN. Ensuite, nous avons mis en place un Wiki (qui n'a pas été très utilisé). La dernière grosse amélioration a été l'utilisation d'un service de gestion de projet en ligne, permettant à chacun de consulter facilement et rapidement ses tâches, et de les mettre à jour. Malheureusement, nous n'avons pas pu approfondir l'utilisation de cet outil, le projet s'étant arrêté quelques temps après.

Le problème majeur pour la gestion de projet, c'est le fait de travailler en équipe amateur. En effet, chaque membre a d'autres occupations, des études, parfois un métier, et donc travaille sur son temps libre. Il est difficile, voire impossible, d'imposer des contraintes de temps, tout d'abord parce qu'on ne peut pas quantifier le temps de travail par jour, ni par semaine, mais aussi parce que les imprévus sont trop fréquents. De plus, les gens n'étant pas payés, ils sont libres de partir quand ils le veulent, il faut donc réussir à motiver chaque personne afin d'assurer la pérennité du projet. Ces problèmes ne se retrouvent pas dans une équipe professionnelle.

Dans une équipe amateur, on trouve aussi un autre problème : le recrutement. Il est en effet très difficile de trouver des gens qui soient à la fois compétents, motivés et qui acceptent de ne pas être payés. Et le problème est d'autant plus gros lorsque le projet débute et qu'on a rien, ou presque, à présenter au public. Pour régler ceci, j'ai utilisé les moyens disponibles sur le net, comme les sites spécialisés dans le recrutement (Le Site du Zéro, Notion Web ou Target-Graphik par exemple), mais aussi les communautés de développeurs ou de graphistes. Pour attirer les talents, rien de mieux que des images, le plus dur a donc été de recruter le premier graphiste. Si le projet est sérieux et bien présenté, et que les outils utilisés pour la communication externe sont variés, alors cette difficulté peut se contourner facilement. 

A travers ces différents obstacles, j'ai pu redécouvrir la gestion de projet, en appliquant de nouvelles méthodes de travail, en me renseignant d'avantage, en observant d'autres projets amateurs (comme par exemple le projet MitalWar par l'équipe de Futurn.net). J'ai aussi découvert des outils de gestion de projet, comme more.groupware ou Taskii (j'utilise aujourd'hui more.groupware pour un projet Fac de 20 personnes), ainsi que des services comme Assembla (fournisseur de services comme SVN, Trac, Wiki, etc. ).

Conclusion

Le projet Orasus m'a donc beaucoup apporté, et j'espère qu'il en a été de même pour mes anciens collaborateurs. Même si nous n'avons pas été loin dans la réalisation, l'expérience acquise n'est pas négligeable, et constitue une bonne base pour une future entrée dans le monde du jeu vidéo professionnel. J'espère avoir l'occasion de retravailler avec les membres du projet Orasus, et ce serait encore mieux si ça se faisait dans un cadre professionnel ! ;)