Je viens de choisir d'abandonner la production de mon jeu après un an de travail entièrement vain, et la tradition veut qu'à la fin d'un "projet", on rédige un post-mortem dessus.
Plus précisément le jeu n'est pas mort, mais l'aventure est finie pour moi. Je ne m'attarderai pas sur les trucs factuels qui ont fait de cette année ce qu'elle a été, ni sur mes motivations initiales. Mon but ici est de tirer des généralités et de servir de contre-exemple à des gens innocents et peut-être trop ambitieux pour leur propre bien (c'est-à-dire moi dans cinq ans).
Mais attention, tout ceci n'a absolument aucune optique dissuasive, juste de mise en garde. Après m'avoir lu, si vous déprimez, allez plutôt regarder des démarches indépendantes qui ont réussi et méritent qu'on s'en inspire, parce que ça existe.
Bref, c'est parti.
 |
| Je voulais aérer/légender mon texte avec une image un peu pertinente et inspirante, genre un type qui écrit une lettre commençant par "Dear myself...", et sur Google j'ai juste trouvé des scans de manga yaoi. Alors contentez-vous d'un bébé ornithorynque. |
Un plan typique pour ce genre d'article serait :
• What went wrong
• What went right
• What we learned
Le truc, c'est que je n'ai pas l'hypocrisie nécessaire pour couvrir ces deux derniers axes et commencer à dire que j'en retire quelque chose de positif.
Amertume mise à part, on va essayer malgré tout, parce qu'il y a des guidelines intéressantes qui doivent ressortir de tout ça. Allons-y !*
*Ce point d'exclamation est une méthode d'autopersuasion pour me faire croire que je suis motivé. Si vous lisez actuellement cet article, ça signifie que je l'ai terminé, donc que ça a marché. Yaaaay !
Alors, quelles sont les raisons potentielles pour lesquelles mener une telle production pendant un an peut s'avérer être une très, très mauvaise idée ?
Sommaire :
Intro : Présentation du projet
Chapitre 1 : Questions financières
Chapitre 2 : Les erreurs techniques et professionnelles
Chapitre 3 : Cohésion et stabilité d'équipe
Chapitre 4 : Facteurs motivationnels
Epilogue : Savoir dire non
Sommaire :
Intro : Présentation du projet
Chapitre 1 : Questions financières
Chapitre 2 : Les erreurs techniques et professionnelles
Chapitre 3 : Cohésion et stabilité d'équipe
Chapitre 4 : Facteurs motivationnels
Epilogue : Savoir dire non
____
Ça s'appelle Kawiteros et c'est un jeu en 2D où on joue un shaman au coeur d'une storyline poétique dans un monde inspiré d'une culture mexicaine, les contrôles sont plutôt platforming, quand on clique sur des objets il se passe des trucs, et graphiquement c'est beau.
VOILÀ
La manière dont je me vois contraint de torcher l'explication de la mécanique de jeu principale est déjà bien révélatrice des nombreuses coupes qu'on a dû effectuer dans le design avant d'atterrir sur quelque chose de franchement simpliste.
Non que ça ne marche pas ni que ce soit mauvais, au contraire, mais le process qui a abouti à ça est aussi épuisant que frustrant, et le résultat, c'est que la préproduction a duré un an et demi, et qu'il est fort probable que ceux qui en ont entendu parler au début finissent partiellement déçus. D'autant qu'ils croient en ce jeu et en son avenir. On a aussi deux autres circonstances aggravantes : le fait qu'on ait été une équipe de huit (c'est beaucoup !) et qu'il y ait eu un éditeur derrière nous, avec qui on a signé.
C'est cette étape de longue galère qu'on appelle couramment le development hell. Même en en étant sorti, le principe vicieux est là : à partir du moment où ta préprod a tellement consommé de ressources que tu n'entames le vrai travail que quand il devrait être fini, et en étant déjà épuisé, tu as intérêt à vraiment vraiment croire en ton projet pour continuer à le porter comme ton gamin. Ce qui n'a pas été mon cas. Et surtout, souvent les circonstances matérielles rendent ceci simplement impossible :
[...]
En fait non, je ne les publierai pas !
Après l'avoir écrit en entier, je réalise que les détails du development hell, avec toute la pression et les échecs qui vont avec, ça n'a même pas sa place dans un post-mortem. C'est beaucoup trop factuel, personnel et sans intérêt. Alors je n'en parlerai pas.
Annuler des choses, en ce moment, c'est mon hobby, ahahahaha
Mais les guidelines que j'en retire n'en demeurent pas moins intéressantes, alors je les partage quand même. Pour comprendre le message, pas besoin d'en faire dix pages, ni même que je détaille la production où j'ai été. Le but de cet article est d'apprendre des choses et non se plaindre inutilement.
Calimero facts :
Intro - Présentation du projet, recontextualisation
Ça s'appelle Kawiteros et c'est un jeu en 2D où on joue un shaman au coeur d'une storyline poétique dans un monde inspiré d'une culture mexicaine, les contrôles sont plutôt platforming, quand on clique sur des objets il se passe des trucs, et graphiquement c'est beau.
VOILÀ
La manière dont je me vois contraint de torcher l'explication de la mécanique de jeu principale est déjà bien révélatrice des nombreuses coupes qu'on a dû effectuer dans le design avant d'atterrir sur quelque chose de franchement simpliste.
Non que ça ne marche pas ni que ce soit mauvais, au contraire, mais le process qui a abouti à ça est aussi épuisant que frustrant, et le résultat, c'est que la préproduction a duré un an et demi, et qu'il est fort probable que ceux qui en ont entendu parler au début finissent partiellement déçus. D'autant qu'ils croient en ce jeu et en son avenir. On a aussi deux autres circonstances aggravantes : le fait qu'on ait été une équipe de huit (c'est beaucoup !) et qu'il y ait eu un éditeur derrière nous, avec qui on a signé.
C'est cette étape de longue galère qu'on appelle couramment le development hell. Même en en étant sorti, le principe vicieux est là : à partir du moment où ta préprod a tellement consommé de ressources que tu n'entames le vrai travail que quand il devrait être fini, et en étant déjà épuisé, tu as intérêt à vraiment vraiment croire en ton projet pour continuer à le porter comme ton gamin. Ce qui n'a pas été mon cas. Et surtout, souvent les circonstances matérielles rendent ceci simplement impossible :
Chapitres 1 à 4 - Questions financières, erreurs techniques et professionnelles, stabilité de la team, facteurs motivationnels
[...]
En fait non, je ne les publierai pas !
Après l'avoir écrit en entier, je réalise que les détails du development hell, avec toute la pression et les échecs qui vont avec, ça n'a même pas sa place dans un post-mortem. C'est beaucoup trop factuel, personnel et sans intérêt. Alors je n'en parlerai pas.
Annuler des choses, en ce moment, c'est mon hobby, ahahahaha
Mais les guidelines que j'en retire n'en demeurent pas moins intéressantes, alors je les partage quand même. Pour comprendre le message, pas besoin d'en faire dix pages, ni même que je détaille la production où j'ai été. Le but de cet article est d'apprendre des choses et non se plaindre inutilement.
1) La thune :
• J'ai bossé un an sans salaire. :'(
• Le jeu coûte trop cher à produire donc les ventes ne nous rapporteront rien non plus. :'(
• Le jeu coûte trop cher à produire donc les ventes ne nous rapporteront rien non plus. :'(
Ce qu'il y a à apprendre :
Ne commencez pas un projet sans être dans la situation préalable financière qui vous permet de le faire. Autrement, la spirale du besoin d'argent s'installe, et freine la production de plus en plus. Il faut partir du principe qu'un jeu indépendant ne sera jamais rentable, et si quelqu'un vous dit l'inverse, ne travaillez jamais avec.
Calimero facts :
2) Les erreurs techniques :
Calimero facts :
• Le design a changé trop souvent. :'(
• On a passé bien trop de temps à développer de mauvaises idées. :'(
• On a mobilisé deux graphistes pendant trois mois sur de la communication et non sur le jeu lui-même. :'(
• On a passé bien trop de temps à développer de mauvaises idées. :'(
• On a mobilisé deux graphistes pendant trois mois sur de la communication et non sur le jeu lui-même. :'(
Ce qu'il y a à apprendre :
Vous avez décidé de commencer votre prod. Great ! Bon courage. Et surtout, maintenant, faites les choses dans l'ordre. Par exemple, se préparer à faire du teasing ou à builder une communauté autour d'un jeu dont le design n'est pas finalisé, ça sonne comme une mauvaise idée de façon stupidement évidente ; et pourtant dans le feu de l'action, ce sont des écueils dans lesquels on peut plonger. Le point le plus important ici est :
• Lorsqu'une idée ou un élément (design, gameplay, code, visuels) paraît douteux, soulève des questions, etc, débarrassez-vous-en tout simplement. Dans ce contexte, on n'a pas le droit à l'erreur.
Calimero facts :
|
| On est à mi-chemin, ça doit être encore plus gênant à lire qu'à écrire, reprenez donc un peu d'ornithorynque |
3) Cohésion et stabilité d'équipe :
Calimero facts :
• Ça traînait parce que personne n'était disponible sur les 8 premiers mois. :'(
• Ensuite la moitié de la team n'aimait pas l'outil principal de workflow et perdait du temps avec. :'(
• Ensuite la moitié de la team n'aimait pas l'outil principal de workflow et perdait du temps avec. :'(
Ce qu'il y a à apprendre :
Travailler en équipe réduite, c'est être handicapé d'un tas de circonstances qui surviennent du fait qu'on est pas tout seul. Une équipe de X personnes qui n'a pas un workflow basique fonctionnel, ce sera simplement X poids morts mis les uns à côté des autres.
• Chaque personne doit connaître ses outils de travail convenablement. Ou avoir les moyens de s'y former très vite.
• Les gens doivent être présents les uns pour les autres. Une équipe splitée à travers la France, dont 70% a autre chose à faire de son quotidien, ça ne marchera pas.
Calimero facts :
4) Facteurs motivationnels :
Calimero facts :
• 80% de mon travail sur ces 10 mois ont dû être supprimés. :'(
• Ça se passait mal humainement au sein de la team. :'(
• Ça se passait mal humainement au sein de la team. :'(
Ce qu'il y a à apprendre :
• Il faut ne pas tomber dans la théorie de l'engagement, c'est-à-dire le "quelque chose ne va pas ? Pas grave, c'est bientôt fini, et après y avoir passé tout ce temps ce serait dommage d'abandonner".
• De même, il est impossible que les visions que chacun a du projet, et du professionnalisme en général, divergent. Chercher à étouffer ça pour le bien du projet, c'est faire une grosse bêtise pour cacher la petite.
• Comme dit précédemment, si un point précis soulève une interrogation ou un doute, il faut le détruire. Sans quoi, on en paye les conséquences plus tard, et on arrive au stade où les soucis motivationnels et humains entravent le projet.
Le chapitre #4 s'applique aussi à l'entièreté du projet. Dans mon cas, en premier lieu, l'accepter était une erreur, et je dois ma situation actuelle à mon incapacité (passée) à rejeter à temps quelque chose de complètement aberrant.
Autant dire que ça ne se produira pas deux fois, et que ce genre d'expérience te booste ta capacité à évaluer des besoins physiques et temporels, et surtout à réagir à ces évaluations en conséquence et éviter ceci :
Alors, est-ce que je devrais regretter tous ces choix l'an dernier qui ont abouti à ce que j'aille me casser les dents tout seul sans rien en retirer ? D'abord, cette question soulève d'autres soucis d'ordre éditorialvoire juridique et éthique dont il serait mal venu de parler dans un truc public. Ensuite, à l'époque dans ma tête, il y avait cette licorne rose sur fond arc-en-ciel clignotant qui répétait sans cesse "FOLLOW YUR DREAAAAAAMZ" et au fond je le pense toujours : si je ne l'avais pas fait, j'aurais aussi eu des regrets dus à la curiosité. Bref, le passé étant le passé, c'est une question qui n'a pas lieu d'être. (CECI DIT MAINTENANT J'AI UNE VIE DE MERDE et je vais beaucoup m'amuser à reconstruire tout ça)
_____
Voilà. Je vais juste finir sur une note optimiste et me dire que je vais rebondir là-dessus, et que mon prochain projet ne pourra pas être pire. Et non, cette dernière phrase n'est pas un défi lancé à mon karma !
Epilogue - Savoir dire non :
Le chapitre #4 s'applique aussi à l'entièreté du projet. Dans mon cas, en premier lieu, l'accepter était une erreur, et je dois ma situation actuelle à mon incapacité (passée) à rejeter à temps quelque chose de complètement aberrant.
Autant dire que ça ne se produira pas deux fois, et que ce genre d'expérience te booste ta capacité à évaluer des besoins physiques et temporels, et surtout à réagir à ces évaluations en conséquence et éviter ceci :
 |
| Refaire tout le moteur physique et la scène complète ? Avec tous les événements pas encore scriptés ? Avant vendredi ? OUI JE PEUX FAIRE ÇA, AMÈNE-MOI UN DIX-SEPTIÈME CAFÉ |
Alors, est-ce que je devrais regretter tous ces choix l'an dernier qui ont abouti à ce que j'aille me casser les dents tout seul sans rien en retirer ? D'abord, cette question soulève d'autres soucis d'ordre éditorial
_____
Voilà. Je vais juste finir sur une note optimiste et me dire que je vais rebondir là-dessus, et que mon prochain projet ne pourra pas être pire. Et non, cette dernière phrase n'est pas un défi lancé à mon karma !
