1) Voir trop large

C'est peut être l'erreur la plus fréquente et la plus naturelle des projets étudiants ou indépendants. On a une "idée révolutionnaire" (ou pas) et on commence à avoir des étoiles plein les yeux. "5 mondes, 10 niveaux par monde, 8 classes différentes, en 3D stéréoscopique utilisant Kinect et un siège amovible". "Ouais mais le gameplay sera révolutionnaire aussi!".

Avoir des idées nouvelles en tête, c'est louable, mais tout le monde en a. Les concrétiser, c'est ce qui fait la différence. Et la réalité est que les équipes de jeux étudiants vont en général de 1 à 10 membres (plus, c'est le chaos assuré). Il faut donc adapter son projet à ses ressources, en prenant en compte les capacités de chacun et anticiper un maximum de risques.

L'anecdote: Je travaille en marge du jeu Mamacocha sur un platformer peu conventionnel où un seul joueur contrôle 2 personnages à la fois. Soit l'un , soit l'autre, soit les deux qui se tiennent la main. Notre contrainte auto-imposée était de pouvoir voir les deux personnages sur le même écran à tout moment. Le tout, dans une version revisitée et sombre de l'univers de contes de Grimm...

L'idée était alléchante, mais nous n'avions pas anticipé tous les problèmes que cela pouvait poser en termes de gameplay. Comment gérer la caméra? La fixer sur un personnage plutôt que l'autre? Jusqu'au où pourraient se séparer les personnages? Que se passe-t-il quand l'un meurt...game over? Restart au dernier checkpoint? (activé par l'un, lautre ou les 2 personnages?) . Autant de questions qui parfois nous amenaient à la conclusion : "c'est peut être pour ça que ce genre de jeu n'existe pas".

 

2) "Ce sera comme tel-jeu-génial...en mieux"

On dit parfois dans le jeu vidéo qu'on n'invente rien mais que tout est une dérivation de quelque chose qui existe déjà...Mais cette erreur là est peut être la plus stupide de toutes. Dans un développement de jeu étudiant, on a une liberté énorme: celle de pouvoir innover. Pas d'éditeur sur le dos, son couteau sur la gorge, pas d'IP (propriété intellectuelle) forcée à utiliser ...pas de budget à respecter (ou dans une moindre mesure).

Dans ce cas pourquoi se cantonner à faire une redite d'un jeu existant, même "en mieux"? Autant tester quelque chose de nouveau, il y aura toujours des gens pour faire des liens farfelus avec d'autres jeux, mais au moins l'intention initiale n'était pas de copier un titre existant. Pas la peine de tomber dans les travers du 1), concentrez-vous sur une mécanique simple mais solide et itérez dessus pour que votre jeu se démarque.

De toutes façons, vous n'aurez pas l'argent pour "faire mieux". Faites donc différent. Et si vous ne me croyez pas, allez faire joujou sur ce calculateur de budget de développement, ça monte très vite.

 

3) Avoir un objectif flou

Pas d'objectif précis = jeu qui ne sera pas terminé. Point. Le jeu suivra sans cesse de nouvelles voies en plein développement, subira de grosses modifications de ci de là, il n'y aura pas d'échéance ni de planning, et donc globalement: "on sait pas où on va".

L'anecdote: Sur Mamacocha, nous avons défini 3 versions pour le jeu: minimale, médiane et maximale. "On vise la maxi...mais vraisemblablement on finira la médiane". Cela nous permet de bien savoir quelles sont nos features les plus importantes, celles qui définissent le jeu et qui doivent être présentes (la physique du vent légère et fluide, la direction artistique "poétique"...). On peut grâce à cela faire un planning qui s'adapte...mais qui a surtout une date de fin.


4) Se noyer dans la documentation

"J'ai fait un google doc de 100 pages, c'est parti on fait le jeu." Au début d'un développement dans une équipe réduite, il faut définir les éléments du jeu...mais les tester est encore plus important. Inutile de rentrer dans les détails microscopiques du game design si la mécanique principale n'est tout simplement...pas intéressante. On ne peut savoir ça qu'en la testant au préalable. D'ailleurs, secret de polichinelle, personne ne lit la doc dans un jeu étudiant, juste celui qui l'a écrite et qui l'a accrochée sur le mur de sa chambre. A côté de ses auto-portraits...dans des cadres en or.

L'anecdote: La durée limitée des projets auxquels j'ai participés (à cause de rendus à telle ou telle date) a fait que nous avons moins eu le temps de documenter en détail les jeux. Nous nous sommes basés sur des prototypes que nous faisions tester rapidement, itération par itération. La méthode a bien fonctionné, mais évidemment, il faut un minimum de documentation ne serait-ce que pour communiquer aisément sur une feature ou une autre.

 

5) "Pas de soucis, je m'occupe de la prog, des artworks, de la musique, etc"

Dans un jeu étudiant, les équipes sont petites. Au point qu'il est fréquent d'avoir plusieurs casquettes, mais en abuser c'est aller droit dans le mur. Oui, il y a des exceptions (créateurs de Braid ou Minecraft), mais pour le commun des mortels c'est trop de travail et au final rien de réalisé. Pire, l'overdose fait que soit tout est bâclé...soit le projet meurt.

L'anecdote: Sur mon premier projet en équipe, j'étais avec 2 autres étudiants, une graphiste et un programmeur. Nous avions littéralement deux semaines pour faire un jeu pour un concours. Ayant proposé le pitch de départ avec un gameplay en tête, je m'étais également proposé pour aider en programmation. Sauf...qu'il fallait formaliser le gameplay, créer les niveaux, ajouter du son, assurer les démarches administratives, etc. Au final, le jeu est sorti mais avec un petit manque de "polish" et surtout, une nuit de rush de folie avant la remise où sans l'aide d'une 4e personne (et une 5e avant dans le développement pour la musique) nous n'aurions pas pu terminer. A H-1, le jeu n'était pas fini.

 

6) Résumer son jeu...en 10 lignes

Si le jeu ne peut pas être résumé en 2 lignes, c'est que la mécanique principale est mauvaise ou trop complexe. Or, la simplicité doit être la feature majeure d'un jeu étudiant. Il faut déterminer où est le fun du jeu et aller à l'essentiel, épurer et simplifier au maximum pour ne garder que l'essence même de la mécanique...et itérer mille fois dessus pour l'améliorer.

L'anecdote: Dans le cadre d'une collaboration avec un gros éditeur, j'avais proposé un pitch. Le gameplay avait déjà ses règles particulières mais pour l'ancrer dans l'univers de l'éditeur, j'ai "forcé" certains éléments en les ajoutant par dessus. Le pitch est devenu une sorte de "truc compliqué" avec clairement deux parties distinctes. Sans surprise, les retours de quelques amis étudiants et de l'éditeur ont été de privilégier la suppression des parties forcées du pitch, qui s'était complexifié artificiellement. Faire simple. Et efficace.

 

7) Avoir un seul cerveau-source d'idées

L'autre gros avantage de cette génération est d'avoir baigné dans les jeux vidéo, la technologie et l'accès à l'information en grandissant. On pourrait considérer ça comme un acquis évident, mais ce n'est pas le cas de beaucoup de gens de l'industrie. De fait, les sources d'inspiration sont multipliées et cette absence de "hiérarchie propre" dans le dev d'un jeu étudiant rend l'échange et l'implication créative dans le projet encore plus simples!

Des studios à succès, gros (ex: Valve) ou petits (ex: thatgamecompany) favorisent ce genre de brainstorm commun et c'est comme ça que les idées les plus novatrices émergent. Ne serait-ce que pour avoir un point de vue différent sur une feature.


8) Ré-inventer la roue, "parce que je préfère fait maison"

Cette erreur là, c'est un peu l'erreur du programmeur. Partir de zéro et vouloir tout monter lui-même. Dans un projet étudiant, il y a une bonne raison pour laquelle c'est une mauvaise idée: pas le temps. Comme dit précédemment, il vaut mieux tester au plus vite ses mécanismes et tout reprendre du début, c'est perdre du temps sur des choses qui sont déjà disponibles ailleurs. Et surtout, c'est risquer de refaire les mêmes erreurs que tous ceux qui sont passés par là avant vous.

L'anecdote: Quand j'ai voulu créer un jeu la toute première fois, je suis parti du bas de l'échelle. J'ai suivi quelques tutoriaux de base pour "faire bouger son joueur", "créer de la gravité", ou sauter. Beaucoup trop de temps passé sur des broutilles, et pas assez sur l'essentiel...créer un jeu. C'est bien plus tard que j'ai découvert des moteurs qui faisaient déjà tout ça, où il fallait simplement manipuler des paramètres ajustables. Leçon: si vous pouvez utiliser des outils existants, FAITES LE.


9) Tester le jeu à la fin

Après les autres points, mettre celui-là semble être redondant mais c'est peut-être LE plus important une fois qu'on a commencé à mettre les mains dans le cambouis. Il faut sans cesse tester son jeu. Pas de NDA à signer, donc demandez à vos amis, à votre famille, à un inconnu dans la rue (quoique). Et même sans prototype, il est touours possible de playtester son jeu sur papier. Toute la documentation et les hypothèses optimistes du monde ne remplaceront pas le regard blasé/frustré/coincé d'un joueur qui essaie votre jeu, en pointant directement vers "ce qui ne va pas". "On n'a pas vécu tant qu'on n'a pas fait playtesté son propre jeu."

L'anecdote: Pour Lost in Grimm's, nous avons profité d'un événement pour faire tester le prototype du jeu à quelques personnes, certaines non-joueurs. Quelques éléments de gameplay entre les 2 personnages et de contrôles qui nous semblaient évidents ont vite montré leurs limites. Nous avions trop la tête dans le guidon pour le remarquer. Un avis extérieur permet de mettre le doigt dessus directement.


10) Lâcher son jeu à cause de <insérer raison>

La réalité de la plupart des jeux "amateurs". Au départ, toute l'équipe a une motivation et une créativité débordantes. Les idées fusent, le temps de travail passe sur les heures de sommeil...c'est la phase de passion pixellisée. Ou plutôt... la lune de miel avant les premières crises de couple. La motivation aura des hauts et surtout des bas. Faute de bâton derrière (ex: se faire virer), il sera difficile de rameuter l'équipe sur le projet quand d'autres obligations arriveront. Et pourtant, il faut terminer ses jeux!

L'anecdote: Participer à des concours de jeux étudiants est un bon moyen d'au moins mettre "une carotte" au bout du parcours. The cake is not always a lie. L'idée de devoir rendre ou présenter un jeu pour une date précise galvanise les troupes pour le faire. On n'obtient pas forcément le résultat escompté au tout départ, mais au moins, le jeu est fini. Rappelez-vous, l'atout majeur d'un "créateur de jeux" n'est pas d'avoir des idées, mais de les concrétiser.


Voilà donc un (long) top 10 d'erreurs à ne pas faire quand on se lance dans la création de jeux étudiants ou indépendants. N'hésitez pas à rajouter vos propres conseils d'erreurs à éviter et à me contredire sur celles-là. Vous pouvez également suivre d'autres articles, making-of et interviews sur mon blog.