Erreur classique n°8: commencer par la fin

12 août 2007 - 23:31 | Dans Erreurs classiques | 10 commentaires

Cette erreur est un grand classique très présent chez les équipes ne sachant pas du tout comment s’y prendre, mais je l’ai déjà observée chez des équipes semi-pros également.

La cause généralement vient du fait de l’incompétence de l’équipe qui ne travaille que sur ce qu’elle sait faire ou sur ce qu’elle pense être le plus important, mais cela peut être juste un problème d’organisation.

Voici les erreurs les plus courantes:

– On en a rien à faire du nom !

Apparemment, l’étape la plus importante pour un projet qui débute, c’est d’avoir de grandes discussions pour décider du nom du jeu. Faut faire ça tout de suite pour pouvoir bien le montrer partout.
Bon clairement, ça ne sert pas à grand chose… D’ailleurs les noms de code de projets sont faits pour éviter ce problème. Il vaut mieux nommer le jeu sur la fin ou quand on a un prototype très avancé et que l’on sait exactement à quoi ressemblera le jeu plutôt qu’au tout début où il risque de changer de nombreuses fois.

C’est ainsi que Windows Vista s’appelait Longhorn, que la Wii était la Revolution et la GameCube était la Dolphin.

Bon bien sûr si vous avez trouvé un nom cool dès le début, autant le garder, mais ce que je veux dire c’est que c’est loin d’être une priorité.

Note perso: je trouve aussi que de nombreux noms de jeux présentés sur les forums d’amateurs sont affligeants de banalité et sans aucune originalité. Je ne compte plus les noms de RPG qui se contentent juste de repomper des noms existants de RPG japonais en mélangeant les mots… vous savez, les tales of aeternia trucs ou symphonies of bidules machins qui sont censés faire « cool »… un peu d’originalité que diable ! 🙂

NB: Cela est valable aussi pour le nom de l’équipe (merci Klaim !)

– On en a rien à faire des détails du scénario

Bon, il y a sûrement des fanatiques du game design qui vont pas être contents, mais je trouve que commencer par faire un pavé relatant tout le scénario en détail et débattre de la couleur des yeux du héros est une énorme perte de temps, pour la simple et bonne raison que les projets amateurs ne se plantent pas par manque de détails sur le scénario mais par une incapacité à créer le jeu en lui même.

Quel intérêt d’avoir rédigé 200 pages de scénario si vous n’arrivez pas à faire un prototype convenable ? La couleur des yeux du héros ou son passé n’aura aucune incidence sur le reste du jeu, concentrez vous sur la création du jeu, pas sur les détails.

РAnnoncer la date de sortie d̬s le d̩part

Pour commencer, vous allez forcément la rater. Ensuite, si votre jeu est attendu, vous allez provoquer la colère de vos fans ou passer pour des rigolos. Rappelez vous du lancement totalement raté d’Half Life 2 qui avait été annoncé « promis juré » un an avant sa date de sortie effective.

РFaire un site web de pr̩sentation

Faudrait qu’on m’explique l’intérêt de passer énormément de temps à faire (et refaire) un site de présentation « public » pour un jeu au tout début de sa conception… « Oh, regardez le jeu auquel vous ne pourrez pas jouer, on a des screenshots tout moches car issus d’une alpha instable ». Franchement, quel intérêt ? 🙂
Faîtes un blog ou un site statique, mais pas besoin de passer une éternité à coder un site communautaire en php ou à faire une interface magnifique, concentrez vous sur le jeu.

– Faire la jaquette du jeu (avec le logo « PC DVD ROM » et tout…) avant de démarrer le développement pour paraître « pro »

Exemple extrême, mais déjà vu… Voir plus bas.

РFaire de la promo pour un jeu en d̩veloppement

Ne faire de la promo (interviews, previews, etc…) que lorsqu’on est sûr que le projet sera fini. Sinon c’est du temps perdu. J’ai en tête trois projets qui ont fait beaucoup de pub avant leur sortie: Matrix HL (mod pour HL1, jamais sorti), un mod qui s’était transformé en standalone et qui avait un journal de bord sur Gamekult (annulé) et enfin un mod HL2 (voir ci dessous).

La promo n’assure donc pas le succès, assurez vous de pouvoir sortir votre jeu avant !

3 exemples de projets où cette erreur est visible:

Je n’explique que ce que j’ai vu en tant qu’observateur extérieur.

– une équipe de collégiens (une 50aine) qui voulait construire une console de A à Z (hardware, software et jeux) qui devait être plus puissante que la Xbox360 (c’était avant sa sortie). Bien sûr ils ont commencé par trouver le nom (un truc bidon mais ils en étaient fiers) et (mal) dessiner la manette.

– une équipe qui voulait faire un système d’exploitation de A à Z étant mieux que Windows et Linux réunis. Le gars expliquait sur un forum comment il voyait le jour du lancement de son OS (avec les équipes de télé et tout) et son équipe avait commencé par trouver le nom et faire un design d’interface graphique qui se résumait à une repompe de celle de Windows, mais faite sous paint… et à la souris… (sisi…)

– un mod pour Half Life 2 commencé avant la sortie de ce dernier (beaucoup de pré-production donc), solo et multi, avec une grande équipe, 200 pages de scénar, des concepts arts, la fameuse jaquette « PC DVD » et plusieurs interviews du leader du projet qui expliquait qu’aujourd’hui les jeux étaient nuls mais que son équipe allait sortir un mod qui allait tout déchirer avec 40h de jeu en solo et un multi innovant. HL2 est sorti, et on a plus entendu parler du mod.

Conclusion :
– Il est forcément plus sexy de vouloir travailler sur les détails « visibles » qui font la grandeur d’un jeu (scénario, ambiance, etc…) que de se prendre la tête sur des éléments dont l’utilisateur final n’aura aucune connaissance (architecture de code, etc…). Mais quand on veut construire une voiture soit même, on commence par apprendre la mécanique et on construit un kart… on s’attaque pas direct à vouloir faire une Lamborghini en la dessinant et en se prenant la tête sur la couleur du volant.
– Il faut s’occuper en priorité des éléments qui auront une importance capitale dans la suite du développement (architecture du code, principe du jeu…), et ne pas se prendre la tête sur ce qui peut être changé sans conséquence à la dernière minute (nom du jeu, look du héros, etc…)

10 Comments »

RSS feed for comments on this post.
TrackBack URI

  1. Une fois de plus, tout à fait d’accord… 🙂
    Que dire de plus ?
    Si tu pouvais rentrer plus dans le vif du sujet, c-à-d expliquer par où il faut commencer et comment, expliquer comment concevoir l’architecture du code…

    Parce que montrer ce qui est mal est certainement plus facile de montrer ce qui est bien, ça te donnerai plus de crédibilité.

    Commentaire by wetneb — 13 août 2007 - 9:36 - #

  2. Très bon article, comme d’hab 🙂

    J’ajouterais pour le premier point que c’est aussi valable pour le nom de l’équipe : je me suis fais avoir une fois avec ça et j’ai perdu beaucoup de temps a voter avec l’équipe pour chercher un nom qui plaise a tout le monde. Comme personne s’est vraiment décidé au bout d’un mois, j’ai décidé de prendre le premier nom qui m’était venu a l’esprit et de l’imposer pourqu’on passe a autre chose. :/
    Heureusement ça n’avais géné personne a l’époque.

    Commentaire by klaim — 13 août 2007 - 14:04 - #

  3. Merci à vous.
    Wetneb> le problème de ta proposition, c’est qu’il n’y a pas « UNE » méthode, et qu’expliquer comment concevoir une architecture de code n’aura rien à voir selon le type de jeu et la plateforme choisie (et donc n’intéressera qu’une petite partie du lectorat qui n’est déjà pas énorme 😉 )… Je préfère donc me limiter pour l’instant aux aspects globaux et non techniques (pas de tutos sur le code). Je verrais par la suite pour le reste.

    J’avais commencé aussi une série sur la méthode à appliquer (voir index) mais je ne l’avais pas fini car l’article suivant qui devait tout résumer devenait monstrueux avec toutes les possibilités des articles d’avant… J’essaierais de le finir qd j’aurais fait le tour des erreurs classiques.

    klaim> j’ai rajouté le pb du nom de l’équipe dans l’article, merci.

    Commentaire by Dam's — 13 août 2007 - 19:42 - #

  4. Ok, je comprends mieux. Merci !

    Commentaire by wetneb — 14 août 2007 - 8:21 - #

  5. Je suis entré dans un projet il y a quelques mois… et pourtant ce projet cumulait un grand nombre des différentes erreurs que tu soulignes (fautes, vague, dev non commencé, scénar inégal, forum bordélique, aucun résumé..)

    En fait, suite à la réception d’une demande de recrutement de ce projet sur une mailing liste, j’ai eu mal pour le recruteur, et je lui ai répondu pour démonter point par point son mail. Et bah figurez-vous qu’il m’a répondu, calmement, et ça m’a motivé à rejoindre l’équipe (dont la moitié des membres sont ‘disparus’).

    Et ce projet va être mené à bien, ça n’a pas été facile, mais on va le faire..

    Tout ça pour dire qu’on peut nuancer tes propos : il est possible de conquérir le monde en commettant toutes les erreurs possibles… il faut juste une vrai persévérance, et un peu de chance 😉 .

    Commentaire by Piwaï — 14 août 2007 - 15:46 - #

  6. Ah mais je n’ai jamais dit que si on faisait des erreurs le projet était foutu… Les erreurs sont la meilleure façon de progresser. J’essaie juste de faire gagner du temps à tout le monde en les expliquant pour éviter de les faire ou pour aider à les rectifier en cours de route.

    Commentaire by Dam's — 14 août 2007 - 18:20 - #

  7. Une fois de plus en plein dans le mille, combien en gardes-tu encore sous le coude ?

    ps: on peut faire de tres belles choses a la souris… 😉

    Commentaire by MMoi — 16 août 2007 - 0:24 - #

  8. MMoi> j’en ai encore qqs uns en magasin, faut le temps de les préparer… 🙂

    Commentaire by Dam's — 16 août 2007 - 12:32 - #

  9. Tu dis qu’il vaut mieux utiliser des noms de code, ce que je comprends tout à fait.

    J’ai commencé mon premier projet (un logiciel de crypto) il y a deux ans et j’ai du lui trouver un nom. Il a été baptisé Cryptall, ce que je regrette un peu puisque ce nom « Ã  l’anglaise » ne fait pas tellement preuve d’originalité, qu’il est souvent mal prononcé (« Cryptal ») et surtout qu’il a déjà été utilisé par d’autres gens que moi (donc j’espère que ça ne me retombera pas sur les doigts :/ ). Aujourd’hui j’estime qu’il aurait été préférable de l’appeller « Cryptol », pour toutes ces raisons et aussi parce que ça a un côté médicament plutôt curieux pour un logiciel de crypto orienté accessibilité et que ça m’amuse. 😀

    Voilà donc la preuve éclatante (à mes yeux) que choisir un nom de code au leiu d’un nom définitif peut être bien utile.

    Sauf que, si un projet se fait connaitre sous son nom de code (au moins par l’intermédiaire des forums de recrutement, ce qui touche un public bien précis certes, mais à ne pas négliger 😀 ), ne sera-t-il pas difficile de changer de nom avant la première beta, alors que les documents, wikis et sites seront tous basés sur le nom de code ?

    Aussi, comment choisir un bon nom de code ? :p

    Commentaire by wetneb — 23 août 2007 - 21:57 - #

  10. Tout à fait d’accord également. Ne jamais voir trop gros, éviter les lieux communs ou la bête copie de projets existant. Personnellement, mon projet est né de rien ou pas grand chose, je voulaius simplement faire des petites choses ludiques et amusantes, le nom n’était qu’un areuh-areuh qui en fait convient parafitement (!), le scénario est quasi inexistant car il se fera au fur et à mesure et rien n’est mis sur papier (bien que j’aie mes petites idées).

    J’ai simplement commencé quelques mini-jeux, un par un, en prenant mon temps, en restant seul surtout,chaque mini-jeu présentant son intérêt en en amenant d’autres, donnant naissance à un semblant d’intrigue. Les choses se lient ensuite d’elles-mêmes (ou pas du tout et là le projet s’arrête ou bien est terminé) et « gonflent » au fil du temps. Un site public ? Oui, juste un wiki pour mettre mes propres élucubrations et garder une cohérence, voire avoir quelques commentaires.

    Le résultat ? Le projet est encore tout petit au bout d’un an mais n’est pas vide ou mort pour autant, le wiki est presque plus riche que le jeu lui-même ! So what ? Eh bien je continue tranquillement, à mon rythme, une passion étant avant tout un hobby – quand ça n’est pas votre métier – et non une torture mentale ou une corvée avec des délais et des contraintes qui peuvent étouffer à terme le feu de l’enthousiasme.

    Commentaire by appzer0 — 8 octobre 2007 - 15:19 - #

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.