Erreur classique n°10: le plantage post-proto

16 février 2010 - 19:51 | Dans Création de jeux vidéo, Erreurs classiques | 19 commentaires

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 ?

19 Comments »

RSS feed for comments on this post.
TrackBack URI

  1. Bon résumé 🙂
    En effet, créer un jeu et concevoir un jeu sont deux choses très différentes. On peut avoir une super idée, et ne pas savoir quoi en faire ou comment l’intégrer dans un réel projet.
    Ce que je retiendrai c’est, en effet, de d’abord faire court. Quand on se lance, plein de petits projets, l’un après l’autre bien sûr sinon c’est n’importe quoi, c’est l’idéal pour apprendre.

    Commentaire by William — 17 février 2010 - 10:40 - #

  2. Salut Dam’s, ça fait plaisir de voir ce blog ressuscité (d’autant que tomber sur la tronche d’Albanel à chaque visite commençait à m’irriter !)

    Je rajouterais bien un point supplémentaire:

    « Compter sur un éventuel succès du prototype pour avancer »

    Mon précédent projet était une idée ré-vo-lu-tion-naire. Comme pour tout le monde, ais-je envie de dire, hein ! 😉 Je l’ai synthétisée, ça fonctionnait et ça fonctionne toujours. Seulement, je comptais sur une base d’utilisateurs (oui c’est un outil un peu ludique et non un jeu, mais je pense que ça rentre dans le même cadre) minimale qui auraient commencé à utiliser la version de base de mon système pour son évolution. Ca faisait partie de ma roadmap, j’ai atteint l’étape « peupler le système » et je n’ai pas réussi.
    C’est un cercle vicieux qui fait que tant qu’on n’a pas une base d’utilisateurs suffisante on ne peut pas montrer le potentiel du système (ou jeu, ça revient au même), et tant qu’on ne peut pas démontrer le potentiel du système, on n’a aucune chance d’avoir une base d’utilisateurs suffisante.
    Ce qui ma fait dire que cette expérience ne rentre dans aucun de tes points, c’est que même après plusieurs années de (non-)fonctionnement, je pense toujours que l’idée est bonne, il est suffisamment simple et structuré pour pouvoir le faire grandir (l’adapter aux utilisateurs, aux problèmes techniques liés aux configurations, sortir des versions téléphone, etc…), je ne pense pas que mon nouveau super projet de remplacement soit spécialement mieux que l’ancien, il est juste différent et rentre dans un autre cadre, etc…

    Bref ma solution a été de me tourner vers un projet plus simple à « vendre » au niveau du concept, qui, s’il a le succès espéré, pourrait servir de tremplin pour promouvoir l’autre concept. Il est malheureusement encore trop tôt pour confirmer que ma solution est la bonne.

    A ce sujet, si tu as un peu de temps libre dans les jours qui viennent (au moins une heure serait bien), j’aimerais avoir une discussion en direct avec toi, justement pour parler de mon prototype actuel. Comme je vais détruire pas mal de choses en vue d’une refonte assez lourde, j’aimerais recueillir ton avis sur ce qui existe déjà. Je t’envoie les détails par e-mail.

    Commentaire by Ono — 18 février 2010 - 14:15 - #

  3. William> même en sachant faire les choses, certaines personnes sont bien meilleures pour les conceptualiser que pour les faire, car elles prennent plus leur pied dans l’aspect conceptuel. De l’autre côté, d’autres adorent appliquer (même sans savoir faire) mais n’aiment pas l’aspect de conceptualisation… (j’espère que je suis clair 🙂 )

    Ono> Bah t’aimes pas Albanel ?
    Sinon j’ai oublié de t’en parler après, mais j’ai aussi euh le même genre de problème… où le truc est génial mais il ne peut pas avancer s’il n’y a pas assez de monde, et les gens ne viennent pas tant que ce n’est pas déjà utilisable.
    J’ai dû totalement changer mon projet de boîte à cause d’un problème de ce genre.

    Commentaire by Dam's — 21 février 2010 - 15:34 - #

  4. Salut!
    Très juste comme récapitulatif de problèmes!

    Actuellement sur mon jeu je suis un peu sur certains problèmes que tu cites, notamment les projets multiples (que je suis en train de régler mais c’est assez difficile).

    Un truc que tu notes pas mais je sais pas si c’est courrant : lorsqu’on a reussi le proto seul et qu’on sait que pour aller plus loin il faut des gens avec à la fois des compétences et une volontées poussés (surtout quand toi-même tu n’es pas débutant). Dans ce genre de cas il peut être difficile de monter une équipe parcequ’on ne peut pas prendre n’importe quel volontaire. Et du coup ça peut plomber un projet qui « bloque » a ce stade (n’avance pas beaucoup plutot) et rends difficile la motivation.

    J’avais d’autres commentaires mais je suis à court de temps alors je repasserai plus tard 🙂

    Commentaire by klaim — 24 février 2010 - 18:11 - #

  5. Je suis tombé plusieurs fois dans ces pièges où on voit tout le contenu qu’il manque :/
    Ca résume assez bien.

    Mais faire des prototypes de jeu a aussi son charme ^^

    Commentaire by nepser — 7 mars 2010 - 0:01 - #

  6. Dans ce cas là faut être développeur de prototypes, pas de jeux 🙂

    Commentaire by Dam's — 7 mars 2010 - 14:55 - #

  7. Je poste pas souvent (non en fait c’est la première fois) , mais je dois dire que j’ai lu attentivement les 10erreur a pas faire , et par rapport a mon expérience personnel je suis plutôt d’accord x).
    Disons que c’est plutôt la règle des 90-90 qui bloque les projets , surtout etant le seul prog c globalement chiant a faire , pour la sauvegarde du jeu il fallait image du jeu baf donc on s’amuse a programmer une fonction pour sauvegarder en format bmp , ah il faut un interpréteur parce que le scénariste est pas bien malin (ou son mes cours sur la compilation..),ah il faut protéger les données allez hop on va faire de la cryptographie D= , surtout que la plupart de ces codages ne sont pas visible pour utilisateur pourtant c’est un bouffe temps énorme , ce qui peut décourager les programmeurs (vu que j’avais grave la flemme de les faire u_u).
    Excellent article qui résume bien le tous^^.

    Commentaire by Kilik — 23 mars 2010 - 16:35 - #

  8. Kilik > Merci 🙂

    Commentaire by Dam's — 11 avril 2010 - 17:12 - #

  9. Salut Dam’s aarrgh tout ce que tu écris c’est tellement vrai !
    Comme la régle des 90%-90% ; je suis sur la finition de mon jeu et cela prend du temps.
    Bravo pour cet excellentissime blog..

    Commentaire by Mat — 27 avril 2010 - 21:22 - #

  10. Merci Mat 🙂
    C’est quoi ton jeu ?

    Commentaire by Dam's — 28 avril 2010 - 6:52 - #

  11. Super fan de ce billet. 🙂
    J’en ferais la promo à chaque occase !

    Commentaire by Ebene — 16 juin 2010 - 13:21 - #

  12. Fou … je suis passé à côté de ces problèmes.

    Dans notre équipe, le développement va au rythme de chacun. Chaque partie du jeu est fortement distincte des autres partie du jeu. On appelle ça des modules.
    Cela à plusieurs avantages :
    – un module du projet est plus court que le projet lui-même … le « momentum » est donc proportionnellement plus grand sur chaque module. La satisfaction du module finie est aussi directement ressenti par les félicitations des joueurs.
    – Le projet Magdales grossi tout le temps depuis 7 ans.
    – Lorsqu’un DEV a fini sa partie, il peut en attaquer une autre tout de suite après.
    – Si un DEV abandonne sa programmation, on n’a plus qu’à finir son travail. Au pire, on abandonne son travail, ce qui n’impacte pas le jeu.

    Les modules de mon jeu sont visibles ici :
    http://www.drafts.fr/fiche-projet.php?Id=20

    Actuellement 4 modules sont en cours.

    Par ailleurs, le découpage de la responsabilité intellectuelle avait été discuté dès le début du projet. Lorsqu’un DEV qui l’équipe, il embarque les sources du jeu au moment de son départ.
    Le nom de domaine, le nom du jeu et la partie physique (serveur, doc, compte bancaire) sont de ma responsabilité personnelle.

    Kéké

    Commentaire by kéké — 1 juillet 2010 - 14:03 - #

  13. Ebene> pas de pb 🙂

    Kéké > Vous avez bien réussi, bien joué !
    L’avantage des jeux web aussi c’est que tu peux avoir une version rapide et les testeurs vous donnent un feedback immédiat qui motive. Si les testeurs se barrent pas et continuent de jouer, après vous vous sentez redevables pour continuer le jeu.

    Si tu veux faire un postmortem un de ces 4 pour montrer les « bonnes pratiques » qui ont réussi chez vous, n’hésites pas, je le publierai !

    Commentaire by Dam's — 2 juillet 2010 - 19:01 - #

  14. Dam’s > Ton blog est très intéressant! Je me fais les 11 erreurs classiques là, ça fait mal XD

    Kéké > J’aime beaucoup le principe que vous utilisez, je l’ai aussi déjà vu en application dans une entreprise pour un simulateur a haute complexité. (apparemment, ça fonctionne pas mal 🙂 )

    Commentaire by 311 — 18 août 2010 - 22:32 - #

  15. 311> Merci. Le principe dont tu parles, c’est de montrer les erreurs ?

    Commentaire by Dam's — 19 août 2010 - 7:14 - #

  16. Tu as oublié un détail, dans ton paragraphe sur les 90-90. En effet, il existe une solution très simple, les 10-10 : on commence par les 10 premier pour-cents, l’interface, le menu, les traductions … il ne reste plus que les 10 % après !!! Bon, en fait, ce serait plus tôt les 10 % – 10 % – 10 %, parce qu’il reste encore du peaufinage après … mais je t’assure que c’est très efficace. A moins que l’on ne soit pas tout à fait sur de son projet, évidemment… Autre méthode (que je n’ai pas encore testée, toutefois) : recruter un type se chargeant des détails facilement accessibles et des textes, en même temps que notre projet avance. J’imagine que ça doit donner de bons résultat, à condition d’être sûr de sa technique, de la base de son projet, et du travail qu’on produit.

    Commentaire by Olivman — 23 août 2010 - 11:14 - #

  17. Tu as testé le 10-10 ?
    Parce que commencer les détails, ça revient à mon article « commencer par la fin ».
    J’suis pas sûr que ça soit une meilleure approche 🙂

    Commentaire by Dam's — 1 septembre 2010 - 16:57 - #

  18. Coucou,

    Olivman > Ta méthode m’intrigue. J’avais assisté à une belle conférence, organisé par Prélude, sur l’extrem programming … Je me demande si ta technique 10% – 10% – 10% n’en fais pas partie ^^.

    De notre côté, nous avons pas mal avancé depuis juillet 2010. 2 modules sont finalisés d’un point de vu code. Il manque des images, mais ça fait partie de notre lot commun, car depuis 7 ans, nous n’avions pas réussi à attirer des graphistes. C’est chose faite maintenant : 2 jeunes (et jolie) graphiste nous assisterons bénévolement pendant quelques temps. Elles ont été émues par notre projet, lorsque nous l’avons présenté au festival du jeu vidéo.
    Donc, les deux modules : Distinction, et 2D isométrique … c’est fini ^^. Le reste fait parti du débuggage maintenant.

    Par ailleurs Gurney a mis en place le module économique sur lequel il travaillait depuis près d’un an. Je vais prochainement faire un petit point avec lui pour maitriser les impacts, les fichiers modifier (nous n’utilisons pas de CSV car trop lourd à mettre en place et à maintenir pour une modification aussi ponctuelle.) Nous avons l’habitude de faire un point mensuel sur nos dev en cours … mais comme il s’agissait d’un dev assez précis et très prise de tête, nous avions naturellement espacé ces réunions.

    Normalement, notre développeur DV va nous amener un lot de correction de code concernant l’accessibilité avant la fin de l’année.

    Un nouveau développeur devrait aussi renforcer les équipes au mois de novembre/décembre.

    Bref, c’est difficile de gérer tout le monde, sans se marcher dessus … en étant actif de 7h à 19h du lundi-> Vendredi, et en ayant 2 petites filles de 1 et 3 ans ^^.
    Mais bon, c’est comme tout … avec de l’organisation, de la bonne humeur, et en faisant une croix sur un bon nombre de choses, on arrive à tout.

    kéké

    Commentaire by kéké — 8 octobre 2010 - 21:33 - #

  19. Je me sens tellement concerné par ces erreurs classiques ! J’en ai effectué une bonne partie ! Pour ma part ce qui plante mes projets, étant donné que je suis tout seul, c’est le « momentum » et les 90-90. Ca me démotive tellement.

    Ma solution c’est de laisser reposer un moment, de recharger les batteries et de retrouver la volonté de voir tout ceci fini et publié.

    Commentaire by darkbsurd — 5 novembre 2013 - 2:17 - #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Copyright © par Conquerirlemonde.com. Tous droits réservés.