Cela fait un moment que j’ai envie de partager mon expérience sur mon projet d’avant Crypto.INC, le projet EOZ ou Exterminator of zombie (oui, mon niveau d’anglais touche vraiment le fond) qui à commencé en novembre 2017.
Bien qu’abandonné, j’ai appris énormément de choses avec ce projet, autant au niveau programmation et utilisation d’Unity 3D, qu’au niveau game design, création de personnages ou encore gestion d’équipe. Cependant j’ai aussi beaucoup appris de mes nombreuses erreurs qui ont menées à l’abandon du projet en juillet 2019 soit un an et demi après le début du projet.
Car oui pour la première fois je ne suis pas partis sur un projet solo, j’ai été vite rejoint par un ami game designer (coucou Dorian :p), lui aussi très motivé pour ajouter ce projet sur son portefolio. L’équipe a été (trop) vite agrandie mais on y reviendra plus tard.
I. Introduction
Il faut savoir qu’EOZ n’est à l’origine qu’un vulgaire prototype de génération de maps, j’étais parti pour faire un générateur de map à la Terraria mais force est de constater que c’était vachement plus difficile que ce que j’imaginais et je suis parti sur quelque chose de plus simple : une simple map rectangulaire de largeur et longueur aléatoire. J’ai récupéré les assets graphiques d’un tuto sur Unity Learn, un style pixel art apocalyptique avec des zombies.
J’ai donc eu l’idée d’en faire un jeu ou le but est de tuer tous les monstres de la map pour passer à la zone suivante.
II. Le spitch
(tiré du Game Design Document sans aucune modification) :
Notre histoire se déroule dans un monde post apocalyptique, où il est très difficile de vivre quand on est un être humain.
Suite à une expérience qui a mal tourné 10 ans auparavant un virus à décimer la population mondiale. Nos personnages, Bob, Laura et Sam était des personnes très ordinaires, avec un travail ordinaire, une vie ordinaire.
Mais ils avaient un point commun : ils étaient tous persuadés que le monde courait à sa perte.
-Bob car il était persuadé que l’entreprise pharmaceutique chez qui il était technicien de surface préparait un mauvais coup.
-Sam parce qu’il regardait beaucoup trop de vidéos sur la théorie du complot
-Laura parce qu’après un bad trip était persuadée d’avoir vu un avenir apocalyptique. Ils se trouvèrent sur internet et décidèrent de se préparer sérieusement à une attaque… 10 ans plus tard après un entrainement acharné ils sont prêts à partir détruire la source de cet accident en détruisant tous les mutants au passage.
III. Première ébauche
J’ai tout d’abord amélioré le générateur pour en faire un exactement du même style que celui de Pokémon Donjon mystère. J’ai créé la map qui se dévoile petit à petit. J’ai créé un système d’inventaire, de craft (et donc d’arme, armure).
Tous ces fonctionnalités m’ont pris 1 an de développement, entre-temps, Dorian a imaginé en parallèle plusieurs types d’ennemis avec des comportements différents ce qui nous faisait un petit bestiaire.
Le système de craft
Génération de map
Un trailer
Refonte totale du gameplay
Après 1 an de développement, une première ébauche un peu près jouable était donc disponible et je l’ai faite tester.
Et là c’est le drame, l’accueil est mitigé, on reproche au jeu d’être trop mou, l’IA des monstres est beaucoup trop bancale. Ce n’est pas facile à entendre quand cela fait un an qu’on travaille dessus. Et là, j’ai eu la fameuse fausse bonne idée qui avec le recule s’est avérée être la plus mauvaise idée que je n’ai jamais eu sur ce projet : changer absolument tout le gameplay, passer à un système de salle à la binding of Issac et partir sur beaucoup plus d’arme, monstre etc. (comme s’il n’y en avait pas assez)
Et là, c’est la catastrophe, le changement de gampelay demande un changement draconien de la structure du code, le code (déjà bien crade) devient un vrai foutoire, je décide de revoir le système d’inventaire qui va casser complètement le système de craft. Bref cela devient complètement n’importe quoi. Et plus j’avançais, plus cela devenait difficile d’ajouter des features tellement le code était un méli mélo de références à tout va.
Et c’est donc en juillet 2019 que je me rends compte que je n’ai absolument plus aucun plaisir à rouvrir ce projet et travailler dessus, la motivation n’est plus là et dans l’idéal il faudrait tout recommencer depuis le début pour partir sur des bases saines… Sauf que recommencer un projet d’un an et demi ça fout le moral à zéro…
Je décide donc de mettre en pause jusqu’à la rentrée le projet avec un autre projet a priori simple à faire : un clicker.
Sauf que cette fois, je n’ai pas attendu 1 an pour avoir un retour de joueur et c’est avec ces retours que j’ai décider de prendre le temps d’écrire le temps d’écrire un Game Design Document ainsi que de réfléchir à la structure du code avant !
C’est ainsi que Crypto.Inc est né et que le projet EOZ fût donc abandonné.
IV. Gérer une équipe c’est difficile
Comme je l’ai dit en introduction, je n’ai pas fait ce jeu tout seul, j’ai constitué une équipe et mon Dieu cela était une vraie aventure, surtout pour trouver un graphiste.
Il faut savoir qu’à l’époque, de par mes expériences en game jam j’avais déjà quelques contacts et je n’ai pas eu de mal à trouver un premier graphiste issu de ma toute première game jam. Celui-ci est super motivé, il me sort quelques assets rapidement. Sauf que malheureusement il n’avait aucune compétence en animation et donc faire les personnages était difficile voire impossible pour lui. J’ai donc dû chercher un autre graphiste, j’ai cherché très longtemps pour au final tomber sur mon second graphiste. Celui-ci m’a créé le logo de Gatito Studio mais encore une fois, il était incapable de faire des spirites de personnages, étant étudiant, il n’avait pas encore assez de compétence ni trop de temps.
Il a fallu encore trouver une autre personne. Et là, miracle, j’en trouve un, il est doué, motivé et commence à faire une ébauche sympa du personnage.
Il fit correctement le travail, rapidement et régulièrement il me livra des sprites pour que je l’intègre au projet Au bout d’une semaine , il quitte la conversation du projet sans aucune explication, et me bloqua.. Autant dire que je commençait sérieusement à en avoir marre.
Et ce n’était pas fini, le suivant « motivé » aussi m’abandonna aussi au bout de quelques semaines.
J’ai finalement contre toute attente trouvé un graphiste bon, travailleur et motivé (et cette fois pour de vrai). Seul petit bémol, il est canadien donc disons que nous discutions sont très souvent décalée à cause des 6h de décalage horaire x)
Petite mention spéciale à mon compositeur (qui comme toujours quand on rencontre quelqu’un), était très motivé mais qui n’a jamais donné aucun signe de vie après la première conversation et qui aujourd’hui n’a toujours pas répondu à mon message lui disant qu’il était viré !
Mais à part cette épopée à la recherche d’un graphiste, j’ai eu une introduction à la gestion de projets et j’ai compris une chose importante sur les projets amateurs : les personnes qui viennent te voir de prime à bord et te disent qu’ils sont motivés, ne le seront pas forcément sur le long terme. Il est très difficile de tomber sur les bonnes personnes et cela prend du temps.
V conclusion
Pour conclure, l’expérience EOZ fût très enrichissante, finalement le projet était plus un énorme projet « recherche et développement » qu’un vrai projet de jeu. J’ai réussi à faire des features qui me semblaient difficile voir quasi-impossible à faire pour moi à l’époque. J’ai appris à imbriquer plusieurs briques de gameplay entre elles (inventaire + système de craft) et rien que pour ça je ne regrette absolument pas d’avoir lancé ce projet. Je pense que le projet était finalement beaucoup trop ambitieux pour une équipe d’amateurs. J’ai envie de le reprendre un jour, mais le gameplay à tellement changé que je ne sais absolument pas comment le reprendre, que garde etc. Je pense donc qu’EOZ restera un projet inachevé 🙂
Si je devais tirer des leçons à partir de cette expérience ;
– Tout d’abord, réfléchir avant d’agir : écrire le Game Design Document avant de commencer à coder mais pas que, réfléchir à l’ensemble de son code avant est très important et peut éviter bien des problèmes
-Ne pas tout changer en cours de route : on peut se donner une marge de manœuvre mais il y a une différence entre changer une toute petite mécanique et le gameplay tout entier.
-Constituer une équipe c’est bien mais il ne faut pas engager la première venue, soyez curieux sur ses compétences, celui-ci peut tout simplement ne pas convenir. Si vous voulez trouver des gens, il vaut mieux avoir quelque chose de solide à présenter.
-Communiquer, n’attendez pas que le travail soit fait: les gens de votre équipe (mis à part si c’est un pro que vous payez auquel cas ça sera son boulot), ne feront pas de votre projet leur but principal, ils ont une vie, un boulot et la procrastination prennent vite le dessus. Organisez régulièrement des réunions de 10/15 mns pour que chacun dise ce qu’il a fait. Si les personnes ne sont jamais disposées pour une réunion d’un quart d’heure c’est qu’elles ne seront jamais disponibles pour faire le travail !
Et surtout (et le plus important) N’ayez pas peur de faire tester le jeu. Je sais que c’est très difficile de faire tester, on n’arrête pas de se dire que le jeu n’est pas prêt à être montré, on se donne toutes les excuses du monde mais la vérité est qu’il n’y a pas meilleur que le feedback d’autre personnes.
Pour finir, j’ai décidé de redonner accès à la version d’EOZ avant la grosse refonte (octobre 2018) . Le jeu est mal équilibré, il y a des bugs mais désormais je me sens prêt à partager le projet. Vous pouvez le télécharger ici.
N’hésitez pas à me faire des retours sur le jeu 🙂
Et vous, vous êtes vous lancé dans un projet beaucoup trop ambitieux que vous avez finalement abandonné ? Faites part de vos expériences dans les commentaires !
0 commentaire