Erreur classique n°10: le plantage post-proto

D’après une étude pas du tout objective (juste une impression en fait…), il semblerait qu’il y ait deux moments critiques dans la vie des projets amateurs, deux moments où la plupart des projets se plantent.

Le premier moment, c’est juste au début, quand le projet est vraiment foireux et que la bande de collégiens qui voulait faire un « WOW en mieux » clashe parce qu’ils ne sont pas d’accords sur la couleur des poils des loup-garous qui seront présents dans le jeu.
Ça, c’est classique, on l’a déjà abordé.

Le deuxième moment est plus étrange, on voit le projet avancer, des screenshots arrivent, c’est jouable, il y a même un prototype, une petite communauté qui se crée et soudain « pouf »… le projet s’arrête: soit d’un coup avec une annonce, soit il ne donne plus signe de vie et disparaît à petit feu.

Je me suis donc demandé pourquoi. Surtout que c’est un problème qui m’est déjà arrivé plusieurs fois.

Voici donc les principales causes selon moi:

1. Trop de différences par rapport à ce qui était souhaité :

C’est ce qui arrive quand on a passé beaucoup de temps pour atteindre le prototype et que l’on se rend compte qu’il reste encore énormément de chemin pour atteindre ce que l’on souhaitait au début. Si le développement a déjà pris plusieurs années et que l’on se rend compte qu’il reste encore plusieurs années devant soi, ça décourage.

Solution: faire des projets plus simples

2. « Les autres 90% » :

En développement informatique, on dit qu’une fois les premiers 90% du logiciel développés, il ne reste plus qu’à faire les « autres » 90%.
Cela a un même un nom, la règle des 90-90 : http://en.wikipedia.org/wiki/Ninety-ninety_rule.

En fait, cela vient de l’impression d’avancer très vite au début et de faire du sur place vers la fin.
Par exemple pour un projet de jeu vidéo, on met en place Ogre pour avoir un moteur 3d qui marche, on a un début de gameplay, etc… Ce qui fait qu’on progresse très vite au début. Au bout d’un moment, il ne reste plus que les détails… en gros équilibrer le gameplay, faire les menus, les options, l’aide en ligne, paufiner l’IA, enlever le lag du jeu en réseau, débugger, traduire les textes en anglais, etc… Presque rien quoi… (ce que l’on appelle le polishing).

Sauf qu’en fait, en cumulant tous les « petits détails » de ce genre, cela prend autant de temps (sinon plus) que tout ce qui a été fait avant.

Ceci provoque tout un tas de désagréments:

• On a l’impression de ne plus avancer car les résultats des changements sont minimes
• On ne voit pas la fin du projet car il y a toujours quelque chose à modifier
• C’est un travail ennuyeux
• Il n’y a plus de créativité, plus de challenge, ce n’est que du travail « idiot »
• Quand on voit tout ce qu’il reste à faire, on a plus envie de le faire

Solution : simplifier le projet, anticiper ces étapes

3. Le contenu :

Faire un proto avec une map de test, c’est marrant.
Faire des niveaux ou des graphismes à la chaîne, c’est moins marrant… ça peut même être lassant, voire décourageant.

Solution : éviter les jeux à contenu, ou avoir quelqu’un qui aime bien faire ça dans l’équipe.

4. La sensation « d’avoir atteint sa vision » :

Quand on veut créer un jeu amateur, on a plein d’images en tête sur ce à quoi ça ressemblera quand ça sera fini.
Le truc, c’est que lorsqu’on atteint le proto et que celui-ci est conforme aux attentes, on se dit « ouais, ça marche, j’ai enfin réussi ce que je voulais faire ».
Comme on fait abstraction des détails qui manquent (les autres 90%) et qui peuvent attendre, on a l’impression d’avoir atteint sa vision et on relâche les efforts.
Et là… c’est le drame, on perd le momentum (= la lancée qu’on avait) et c’est très dur de le récupérer.

Solution : anticiper cette sensation pour redoubler d’efforts à ce moment là

5. Les problèmes techniques non anticipés :

Quand on est tout seul sur son projet, tout va à peu près bien.
Quand on commence à avoir des joueurs, il faut gérer plein de choses supplémentaires:

• les problèmes de configuration et de compatibilité (système d’exploitation, drivers…)
• les problèmes de taille d’écran
• les problèmes de lag pour le jeu sur internet
• les problèmes de scalabilité quand le jeu est trop gourmand niveau serveur
• etc.

Tout cela démotive car on doit régler les problèmes des autres que l’on a pas chez soi, ils sont souvent inattendus et ne font pas progresser le jeu d’un point de vue créatif.

On rajoute à cela tous les problèmes techniques liés à l’apprentissage de technos différentes (rendu graphique, moteur physique, IA, etc.), ce qui allonge la liste de toutes les choses à régler.

Solution : ne pas avoir de projets sur lesquels il faut apprendre trop de choses techniques en même temps, ça limitera les surprises.

6. La différence de qualité :

Si le projet est conséquent, on apprend beaucoup au cours de son développement. Le problème est que la différence de qualité entre ce qui a été fait au début et maintenant (qualité des graphismes, des maps, du code, etc.) est parfois telle que le jeu est devenu beaucoup trop inégal.
Comme continuer sur une base instable n’est pas une bonne idée, généralement soit le projet est recommencé du début « en plus propre », soit abandonné au profit d’un autre projet.

Solution : privilégier les projets courts, surtout si ce projet sert d’apprentissage

7. Les engueulades dans l’équipe :

Si le projet commence à avoir du potentiel, il arrive que l’équipe se déchire pour divergences d’opinions. Soit parce que certains veulent avoir une plus grosse part du gâteau que prévu, soit parce que rien n’a été prévu et que chacun a sa propre vision de ce que le jeu pourrait lui rapporter…

Une autre raison peut être un désaccord sur l’objectif réel du jeu (gratuit, open source, payant, etc.) ou de son style graphique une fois un proto technique réalisé.

Solution: bien définir les rôles et prévoir un accord à l’avance avant de s’engager avec quelqu’un, notamment sur la propriété des éléments réalisés en cas de départ de la personne.

8. Le départ des membres qualifiés :

Si l’équipe est composée de personnes compétentes et que le projet commence à se faire connaître, celles ci vont sûrement avoir des propositions rémunérées pour leur talent… A ce moment là, il sera dur de les garder pour un jeu amateur…

De plus, les nouveaux qui pourraient être recrutés pour les remplacer risquent d’être largués.

Solution: avoir des projets courts, particulièrement s’ils sont bénévoles. Si le projet est à visée commerciale, l’objectif est d’être rentable rapidement pour pouvoir payer l’équipe.

9. Le nouveau super projet qui est vachement mieux que l’actuel :

Ben oui, vous avez une super nouvelle idée qui est vachement mieux que le projet actuel. Et puis de toute façon votre code il est pas beau, il faudrait le rendre plus flexible. Et puis il y a ce nouveau moteur 3D qui a l’air bien mieux que Ogre/Irrlicht/Unity/Whatever. Quoique vous avez vu un tuto sur « comment créer son propre moteur 3D » et ça a pas l’air si compliqué que ça en fait…

De plus, c’est à ce moment que vous allez voir tous les défauts du projet actuel. Il est pas assez ceci, un peu trop cela… et au final, est-ce que ça vaut vraiment le coup de le finir ?

Solution : Savoir se fixer sur un projet. Pas toujours facile. Cela dépend aussi de vos objectifs: apprendre ou finir un projet ?

10. Être un concepteur et non un réalisateur :

Certaines personnes sont très bonnes pour concevoir des projets, élaborer la stratégie, les différents éléments du concept, etc.
D’autres personnes sont très bonnes pour les réaliser, passer au concret, appliquer les stratégies.

Être les deux en même temps n’est pas toujours facile.

Solution : être les deux, ou trouver les personnes qui vous complètent

Conclusion :
Tout ceci peut être changé par des facteurs aggravants :

– Être sur plusieurs projets en même temps (à éviter au maximum car un projet va toujours prendre le dessus sur un autre)
– Complexité du projet
– Facteurs externes qui jouent sur le moral

Si je devais résumer, la plupart des causes viennent de la complexité du projet. Donc :

• Faîtes court
• Faîtes simple
• Créez un momentum pour bosser d’une traite sur le jeu et qu’il n’y ait pas de temps morts, surtout si vous êtes une équipe
• Méfiez vous de l’impression d’aller super vite au début
• Une fois fini, recommencez en augmentant légèrement la difficulté

Et vous, pour quelles raisons votre projet a planté après le proto ?