Erreur classique n°5: avoir une grande équipe

Cette erreur est souvent en relation avec les erreurs déjà citées et est généralement un signe que le projet part en sucette. Il n’est pas rare de voir des équipes d’amateurs composées de 10 jusqu’à 30 membres, voir plus dans certains cas.
Je ne parle bien entendu que des projets amateurs réalisés bénévolement pendant le temps libre et par Internet, un studio pro à plein temps n’ayant pas les mêmes contraintes.

Voici les différentes raisons de ne pas avoir une grande équipe pour un projet :

РGrande ̩quipe = grand projet
On ne recrute pas 20 personnes pour faire un Tetris, mais plutôt pour se lancer dans un grand jeu (MMO, RPG, FPS…). Avoir un projet trop long ou trop complexe est déjà une erreur comme indiqué dans les précédents articles, le fait de recruter une grande équipe pour pallier à ce problème n’améliorera pas la situation.

– Cela prend du temps
Recruter, valider les membres, leur faire passer des tests, demander leur avis, les relancer, chercher quoi faire quand ils ne répondent plus, gérer les conflits, rédiger les documents pour qu’ils comprennent bien l’objectif, organiser des réunions, etc… Cela prend du temps qui n’est pas passé à développer sur votre jeu. Ce temps augmente avec le nombre de membres de votre équipe. Passé la dizaine, cela devient ingérable.
Cela serait encore utile si tout ce travail était rentabilisé mais malheureusement… :

РLa majeure partie de votre ̩quipe sera bidon
Ca peut paraître méprisant annoncé comme ça, mais c’est souvent le cas d’une façon ou d’une autre.
On peut citer:

• ceux n’ayant pas le niveau
• ceux qui doivent apprendre quelque chose pour être utiles mais ne le font pas
• ceux qui ne feront rien tout en faisant croire qu’ils bossent
• ceux qui abandonneront
• ceux qui n’auront jamais le temps
• ceux qui n’ont pas la même la vision du projet que vous
• ceux qui se barrent avec la moitié de l’équipe pour faire à peu près la même chose mais sans vous
• ceux qui vont mettre le boxon et s’engueuler avec le reste de l’équipe
• etc…

Ce n’est pas forcément entièrement de leur faute, la façon de les gérer compte pour beaucoup. Mais un membre bidon restera bidon même avec la meilleure organisation possible.

Tout cela se traduira par du temps perdu. N’oubliez pas que généralement les personnes compétentes et motivées sont déjà sur un projet. Si vous recrutez beaucoup de monde, ce sera sûrement des débutants à la motivation éphémère, même s’ils diront le contraire.

– Le recrutement aveugle
Comme déjà expliqué dans l’article sur l’organigrammite, beaucoup d’amateurs recrutent des équipes entières sans avoir vraiment besoin de tout le monde au départ. Recruter des testeurs dès le début ne servira à rien.

РDifficult̩s de m̩langer les diff̩rents niveaux
Qui dit grande équipe dit nombreux caractères, talents, expériences et styles différents. Avoir une cohérence dans le code, les graphismes et la musique entre personnes de niveaux différents n’est pas aisé.

Cela augmente également les problèmes de logiciels, de version (« bah ça compile pas chez moi ! »), d’organisation (« c’est quoi svn ? »), etc… Tout un tas de problème que l’on aurait jamais eu tout seul !

– On ne s’improvise pas manager
Les professionnels ont déjà du mal avec cette partie (cf: cet article chez Jeremy Chatelaine), chez les amateurs c’est encore plus compliqué. Donc quand le premier adolescent venu veut gérer 30 personnes, cela pose souvent des problèmes.

– Le « Leader Scénariste »

Dans les grandes équipes, il s’avère de temps en temps que le leader ne sait rien faire du tout donc s’improvise « chef » et « scénariste » et recrute donc beaucoup de monde pour faire le travail à sa place. Le resultat est sans suprise.

– Ca ne marche pas !
Argument subjectif par excellence, mais je n’ai jamais vu de grande équipe réussir quelquechose.

– Quelle solution ?

Il n’y a pas de méthode miracle. Mais voici quelques conseils en vrac:

• être très bon dans son domaine. Ne recrutez personne si vous êtes vous même « bidon »
• commencez par des projets simples tout seul ou avec peu de monde. Vous ferez mumuse avec une grande équipe quand vous serez à plein temps dessus dans votre propre studio, en attendant, il n’y a pas d’intérêt de se compliquer la vie.
• essayez de ne pas avoir plus de 5 personnes dans votre équipe, 1 ou 2 par domaine au max.
• consolidez une base d’équipe solide sur un projet simple et faite le évoluer sur des projets plus complexes par la suite, quand l’équipe est solide et se connaît bien

Erreur classique n°4: l’organigrammite

(oui, j’invente des mots si j’veux…)
Par « organigrammite », je désigne deux problèmes touchant les projets amateurs, le premier étant plus anecdotique que le deuxième.

« Lead Machin »

En règle général, l’être humain aime bien avoir un titre pour se sentir important et pour avoir l’immense satisfaction d’être plus gradé que le voisin. On a les titres militaires, religieux, nobles et ceux propres à l’entreprise (avec des pdg, des directeurs et des responsables partout).

Dans un projet amateur, on retrouve parfois (ça reste une minorité heureusement) des personnes ayant ce besoin d’avoir un titre pour paraître important, « professionnel » et avoir sa place dans l’organigramme du projet. On voit donc de temps à autres ce genre d’attitude sur les forums amateurs.

Ca reste mon avis personnel, mais quand une équipe d’amateurs sans réelle expérience se présente sous la forme d’un panel de directeurs de tel ou tel aspect, ça me semble juste ridicule et ça leur fait perdre toute crédibilité.
Ne cherchez pas à paraître pro à tout prix et à être « lead machin », « chargé de recrutement » ou « lead cela », si vous étiez vraiment pros, vous ne seriez pas en train de recruter des bénévoles sur un forum mais plutôt à envoyer des offres d’emplois sur l’afjv.

Et, sans citer de nom, une team semi-pro qui vient recruter pour un projet même pas au stade d’alpha et qui a dans son équipe un « responsable communauté », ça me laisse perplexe. 🙂

Bref, restez humbles…
(et c’est un gars qui a un blog intitulé « Conquérir le monde » qui vous le dit !)

Faire son marché pour remplir l’organigramme

Autre problème, plus important et plus fréquent, concerne les chefs de projet qui viennent recruter tout une équipe sur un forum.
On sent qu’ils ont regardé de quoi était composée une équipe classique de développement de jeux vidéo, et ils viennent donc remplir leurs organigrammes pour être sûrs qu’ils ont tout ce qu’il faut.

Vous avez sûrement déjà vu ça, un gars présente son projet et recherche des programmeurs, des graphistes, des concepts artists, des scénaristes, des musiciens, un webmaster pour le site et des béta testeurs.

Il n’y a rien qui vous choque ? (autre que le fait que recruter une grande équipe est une mauvaise chose, ce que l’on verra plus tard)

Ce qui coince, c’est qu’il essaie de réunir une équipe dont certains membres sont axés sur la préproduction (scénaristes, concept artists), d’autres sur la production (programmeurs, graphistes, musiciens) et enfin les derniers sur la post-production (webmaster, béta testeurs).
C’est comme si pour construire une maison, on appelait l’architecte, le maçon et le couvreur pour commencer à bosser le même jour… ça serait n’importe quoi.

Il faut donc garder une équipe réduite et ne recruter que des membres qui ont une utilité immédiate et qui auront une mission bien définie, sinon ils quitteront vite le navire à force d’attendre ou de travailler à vide.

De plus, faire bosser votre équipe sans base définie augmente le risque de devoir leur faire refaire leur travail (« ah, ben on est passé de la 3D à la 2D pour finir, on veut plus de tes modèles, fais nous des sprites ») , ce qui les fera très certainement quitter le projet.

Rappelez vous, vous n’êtes pas « pro ».

Erreur classique n°3: faire un jeu nécessitant trop de contenu

Outre la complexité d’un jeu vidéo, l’autre élément principal conduisant souvent à un abandon est la somme des « Ã©léments » (ou « contenu ») à produire pour ce jeu (et j’en fais les frais en ce moment sur un de mes projets, si quelqu’un connaît un graphiste… faire offre 🙂 ).
Par élément, j’entends tout ce qui est graphisme, interface, modèles, textures, niveaux, quêtes, dialogues, scénario, etc…

Ce n’est pas spécialement complexe à réaliser une fois que l’on a appris à le faire, mais cela prend du temps.

Prenons un exemple simple: faire un mod solo pour un quake like n’est pas vraiment compliqué une fois que l’on a appris à se servir de l’éditeur de niveaux. Cela n’empêche pas le fait que la majorité des mods solos échouent tout comme les projets de mmorpg. La raison est simple, faire du contenu à la chaîne est vite ennuyeux et 10 amateurs faisant cela dans leur temps libre auront toujours plus tendance à abandonner qu’une équipe pro étant rémunérée pour faire cela à temps plein.

Autre exemple: faire un rpg 3d. Passé l’euphorie d’avoir mis en place Ogre 3D et d’avoir un prototype fonctionnel, vient le moment où il faut créer tout les décors, les personnages, les musiques, les quêtes, les combats, etc… Ce n’est pas impossible, mais c’est très long, pour un résultat qui restera amateur au final pour la plupart des cas.
Pendant le temps que vous passerez sur ce projet, vous auriez pu développer au moins 5 fois un jeu comme Defcon, qui s’est vendu et qui a eu du succès.

Solutions possibles:
– choisir un jeu n’ayant pas besoin de beaucoup de contenu (Tetris, Sudoku…)
– jouer sur le style graphique pour avoir moins de contenu à produire. Ex: Defcon et Darwinia, Geometry Wars.
Рprivil̩gier le multijoueurs pour rentabiliser au maximum le contenu produit (Bomberman)
Рfournir le minimum de contenu et laisser la communaut̩ produire le reste (Mugen)
– mettre en place un système de création procédurale qui génère le contenu tout seul mais augmente la complexité du jeu (Niveaux de Diablo, Elite) Voir cette news chez AntiPattern à ce sujet.

Voici en résumé (bon, j’ai évalué au pif… c’est juste pour avoir une idée, passez pas votre temps à vous plaindre que tel truc est pas placé comme il faut), une représentation de la complexité et de la somme de contenu à produire pour un jeu.
En gros, plus votre style de jeu est proche de l’origine, plus il ira vite à faire. Plus il est en haut à droite, plus il sera compliqué.

Le paradoxe est donc que beaucoup de débutants tentent directement le mmorpg ou le rpg 3d, ce qui représente les projets les plus compliqués et longs à faire.
De l’autre côté, les petites équipes qui réussissent ne font pas de mmo ou de grands jeux 3D. On a par exemple Popcap qui est l’un des ténors des jeux pour casual gamers avec Bejeweled (= Diamants dans MSN) et Zuma ou Introversion qui a son propre style (Darwinia, Defcon).

En tant qu’amateur ou indie, il vaut mieux donc choisir un projet qui soit bon tout en minimisant tant que possible la complexité et la somme des contenus à produire.

Erreur classique n°2: faire un jeu trop complexe

Disclaimer: article principalement destiné aux débutants.

Vouloir faire un jeu trop complexe est l’erreur la plus fréquente et la plus visible que l’on peut lire sur les forums de développeurs de jeux vidéo.

Cela concerne principalement les débutants inexpérimentés qui veulent refaire dans leur coin le hit du moment « mais en mieux ». Le phénomène n’est pas nouveau: en 2000 tout le monde voulait refaire Quake 3, maintenant c’est plutôt refaire World of Warcraft.

Le mythe du « je suis motivé et j’ai le temps »

C’est la réponse que l’on obtient généralement quand on tente de décourager quelqu’un d’inexpérimenté de se lancer dans un tel projet en faveur de quelque chose de plus simple.
Sauf que généralement, vu que le projet se révèle au final infaisable (oui, aussi bizarre que cela puisse paraître, peu d’ados de 14 ans réussissent à faire un MMORPG en 3D de A à Z), la motivation s’envole au fil du temps et le projet coule.

De toute façon, même si la motivation restait et que l’équipe débutante travaillait sans s’arrêter sur le projet (ce qui reste improbable), la qualité du travail fourni serait soit trop mauvaise, soit trop hétérogène entre un stade avancé et le début du projet (tout codeur jetant un oeil sur ses premiers projets comprendra, pareil pour les graphistes…) et il faudrait recommencer plusieurs fois les mêmes choses pour avoir un ensemble homogène. Bref, une perte de temps.

La création de jeu vidéo, ce domaine magique…

…où les débutants veulent faire mieux que les pros.
C’est en effet le seul domaine où l’on voit des débutants complets essayer de surpasser des professionnels ayant des années d’expérience sans que cela ne leur semble bizarre.
Pourtant, un débutant en Tennis n’aura jamais l’idée de s’inscrire au tournoi de Roland Garros, un enfant apprenant à écrire n’aura pas l’idée de commencer un livre pour le prix Goncourt.

Pourquoi cela serait différent pour la création de jeux vidéo ?
Un projet n’est généralement pas irréalisable en lui même, il faut juste de « l’entraînement » et de l’expérience. Essayer de griller les étapes en voulant atteindre le sommet de ce domaine immédiatement ne sert à rien.

Visez grand …
… commencez petit !

Cela ne veut pas dire qu’il faut abandonner ses rêves, juste qu’il faut y aller progressivement. Il est impossible de lancer un mmorpg commercial réalisé par des débutants. Par contre, il est possible de s’entraîner, de créer des jeux indépendants, de créer une société, de la faire grandir, de devenir un vrai studio de développement et alors il est possible de réaliser le jeu de ses rêves.

Le premier conseil qui est donné à quelqu’un voulant se lancer dans le développement de jeu vidéo (d’un point de vue programmation) est: « Fais un morpion ! ». La plupart de ceux qui ne suivent pas ce conseil vont généralement dans le mur car ils ne comprennent pas l’intérêt de l’apprentissage et veulent juste faire « leur » jeu et « maintenant ».
Faire un morpion n’est pas une fin en soi, c’est juste que si on est pas capable de faire un morpion, on ne sera pas capable de faire le super mmorpg-next gen.
Et comme la première fois que l’on fait un morpion ce n’est pas si évident que ça en avait l’air, cela montre que c’est un apprentissage utile. L’idée est donc par la suite d’augmenter progressivement selon son niveau de départ, de passer à un tétris, un mario, un bomberman, un mario kart, un jeu 3D, etc…
Il faut d’abord obtenir les compétences et l’expérience nécessaires avant de faire des projets plus importants.

Pour les non-programmeurs, c’est une situation différente mais un apprentissage progressif est également nécessaire. Vous ne trouverez pas de programmeurs expérimentés et sérieux pour votre projet si vous n’êtes pas non plus expérimenté dans votre domaine.

Erreur classique n°1: essayer de faire comme les pros

Cela va sembler évident pour la plupart des lecteurs, mais il arrive régulièrement de voir certains amateurs essayer de faire un jeu « comme des pros » après avoir vu ou lu comment se fabrique un jeu dans un studio professionnel.

Si certains aspects sont intéressants, cela reste quand même une erreur d’essayer de copier leurs méthodes car ce n’est pas du tout le même monde.
Bien entendu, la situation varie selon si on est un débutant complet ou un indépendant semi-pro.

Pour commencer, il faut avoir en tête qu’être amateur implique des contraintes supplémentaires:

– le travail se fait pendant le temps libre. Les pros sont à temps complet.
Рon est g̩n̩ralement inexp̩riment̩ et la cr̩ation n̩cessite un apprentissage. Les pros sont exp̩riment̩s.
– les équipes d’amateurs voient énormément de changements parmi leurs membres, il est difficile de compter réellement sur quelqu’un sur la durée. Les studios sont plus stables de ce côté là grâce aux salaires (entre autres).
Рun projet amateur signifie surtout t̩l̩travail, et donc motivation et initiative. Les pros travaillent en studio et sont manag̩s.
Рpas ou peu de ressources, ce qui implique des difficult̩s pour sous-traiter, louer des serveurs et acheter du mat̩riel et des logiciels
– dans le cas des indies vendant sur Internet, il faut faire également le marketing, la communication, la gestion des ventes, etc… alors que pour un jeu vendu en boîte c’est l’éditeur qui s’en charge.

Mais cela à aussi des avantages:

– pas besoin de communiquer à tout va car vous n’avez pas un éditeur aux fesses, pas besoin donc de commencer à faire de la pub ou des sites internet de présentation. Concentrez vous sur le fait de faire le jeu.
– plus grande liberté pour le jeu, on ne peut pas brider votre créativité. Si vous avez le niveau, vous pouvez vous permettre d’innover. Si vous êtes vraiment débutant, il vaut mieux commencer par cloner des grands classiques (pong, bomberman…) histoire de se faire la main
– pas de milestones obligatoires (et le projet n’est pas annulé s’il est en retard)
– pas trop de risques financiers (sauf indie qui prend des risques « raisonnables »)

Prenons un exemple d’une technique à ne pas reproduire :

La gestion de projet dans un projet pro est très important. Il faut savoir gérer l’emploi du temps des membres de l’équipe et s’assurer que chacun avance correctement car un trop grand retard peut mener à l’annulation du projet. Certains projets amateurs essaient de s’en inspirer et mettent même en place des diagrammes de Gantt et autres joyeusetés.
Sauf que, tout cela ne sert à rien généralement… pour la simple raison qu’un projet amateur est réalisé pendant le temps libre d’une personne, et que ce temps est généralement très variable (pouvez vous en vouloir à quelqu’un de ne pas travailler au projet parce qu’il a des examens ou des problèmes familliaux ?). De plus, rien n’empêche un membre de l’équipe de partir sans qu’il puisse être remplacé, et dans ce cas votre joli diagramme devient inutile.

En conclusion

Si j’ai mis cette erreur en premier c’est parce que beaucoup d’autres en dépendent.

La solution consiste simplement à admettre qu’on ne peut faire faire un jeu comme le font les pros pour la simple et bonne raison que les conditions ne sont pas les mêmes. Il faut agir en fonction et choisir un projet et une méthodologie qui permettent de réduire ces inconvénients supplémentaires et d’augmenter les effets des avantages.

Erreur classique n°0: présentation

J’entame ici une série d’articles sur les erreurs classiques que font les créateurs de jeux vidéo amateurs et indépendants.

L’intérêt de la chose est simple: tout le monde fait des erreurs et tout le monde DOIT apprendre de ses erreurs. On gagne simplement du temps en apprenant des erreurs des autres pour ne pas les refaire à son tour.

Histoire de ne pas me faire incendier par la suite, je tiens à préciser quelques aspects:

• ce sont des erreurs constatées sur des projets amateurs ou indépendants et cela ne concerne donc pas les pros. Cela ne sert à rien de me dire que chez les pros ça ne fonctionne pas comme ça, je le sais. Ici, il est plutôt question de projets réalisés pendant le temps libre, sur Internet et sans avoir forcément toutes les compétences nécessaires.
• les erreurs sont principalement tirées de projets que j’ai vu sur des forums et plus rarement que j’ai connues directement ou indirectement.
• je privilégie la pratique à la théorie.
• il y a beaucoup de jeunes qui souhaitent faire des jeux vidéo et s’y prennent très mal, ne soyez pas étonnés si certains articles traitent d’éléments qui vous semblent évidents. Cela n’empêche pas des semi-pros de faire ces erreurs également.
• la plupart des articles seront objectifs mais certains seront fatalement subjectifs et pourront être totalement réfutés par d’autres personnes. Je pense particulièrement aux conflits du genre « faut-il avoir un game design document complet avant de commencer » et autres joyeusetés du même genre. Je donne mon avis en tant que programmeur et qu’observateur de nombreux projets qui se sont plantés sur des forums, rien de plus.

A bientôt pour le début. Les premiers articles couvriront les bases, n’attendez pas de grandes révélations.