Conseils généraux pour apprendre le processus de programmation solo d'un jeu,

Un tutoriel de Yahiko

Avant-Propos

Ce qui suit est une traduction de mon cru qui était restée dans un fond de tiroir d'un article de Macoy Madson qui avait eu la gentillesse d'accorder son autorisation : General Tips on the Process of Solo Game Development

Conseils généraux sur le processus de développement solo d'un jeu

En tant que développeur de jeu solo, il est important d'apprendre autant que possible sur tout ce que vous pouvez, y compris le processus que vous suivez en faisant des jeux. Le processus, je vais en parler comprend les étapes suivantes :

• l'Idée ;
• le Prototype ;
• l'Itération ;
• le Test ;
• la Finalisation.

J'espère vous fournir des conseils utiles sur chaque étape de ce processus de sorte que vous pourrez améliorer la vitesse de développement et la qualité de vos jeux.

Le processus, étape par étape

Tout d'abord, il est important de noter que ce n'est pas un processus en « cascade » linéaire. Il est très organique. Alors que vous commencez toujours avec une idée, les étapes suivantes de prototypage, d'itération, et de test se passeront de façon désordonnée. C'est une bonne chose, car il encourage l'expérimentation et va à l'encontre de la rigidité de la conception d'un jeu, et ce qui permet l'évolution positive de l'ensemble. Au fil du temps, vous aurez une meilleure idée sur la façon dont vous suivez habituellement ce processus et comment vous pouvez l'améliorer.

Première étape : l'Idée

Les développeurs de jeux débutants pensent parfois que c'est l'étape la plus importante dans le processus, et que tout développement doit être à l'arrêt tant qu'une idée n'est pas explorée à fond. Suite à cela, ils ont tendance à surconcevoir (eg. d'indigestes documents de game design), voir trop grand par rapport à leurs compétences, et à surestimer la valeur des idées. Cela fait également une conception beaucoup plus rigide, qui finit par affecter négativement le jeu sur le long terme.

Bien que l'idée soit importante, il est plus important de comprendre la fragilité de vos connaissances tant que vous n'aurez pas fait un prototype et tester cette idée. Vous verrez que les idées qui sont dans votre tête peuvent paraître sympa, mais que jouer à un prototype de cette idée finit par être vraiment ennuyeux. Vous verrez également qu'une idée « terne » peut donner un prototype vraiment amusant !

Au cours de cette étape, assurez-vous que votre objectif et vos contraintes soient bien définis. Par exemple, « faire un jeu fun » n'est pas un objectif très clair, tandis que « faire un jeu dans un mois qui utilise le thème du jeu Flowers et utilise de préférence le nouveau système COM » l'est. Le deuxième exemple montre également de bonnes contraintes. Certaines contraintes très immédiates qui s'appliquent à la plupart des gens qui font un jeu dans un certain laps de temps (« avant la mort », même) et de rester à l'intérieur (voire très légèrement au-dessus) de votre gamme de compétences. Les contraintes peuvent vous aider à penser à d'autres idées, mais il est souvent bon de faire varier le niveau de degrés de liberté que vous avez sur chaque projet de jeu.

L'inspiration est un mot qui revient souvent quand on parle des idées. N'oubliez pas que l'inspiration vient de partout, telle que de votre vie, d'autres médias, la théorie sur la conception de jeux, ou même la génération aléatoire ! La chose la plus importante que vous devez savoir sur « l'inspiration » est de ne pas sauter sur la première idée venue ! Lorsque vous êtes « inspiré », votre cerveau pompe ces substances chimiques associées à la récompense suite à cette production heureuse d'idée, ce qui vous rend très peu objectif sur les défauts de cette idée ! Tout ce que vous avez à faire est de vous donner du temps. Peu importe à quel point l'idée vous semble bonne sur le coup, donnez-vous au moins trois ou quatre jours avant de faire davantage que d'y penser et d'écrire à son sujet.

À un niveau inférieur, il est important de se concentrer sur la/les mécanique/s de votre idée. Rappelez-vous, vous écrivez un jeu, pas une histoire, donc vous avez besoin d'un gameplay ! Si vous ne pouvez pas penser à bon gameplay pour cette histoire, peut-être que cette histoire serait mieux véhiculée sous une autre forme de média.

Lorsque vous avez une idée et que vous avez patienté un laps de temps suffisant (et qu'elle sonne toujours bien), la prochaine chose que vous devez faire est de la réduire à sa plus simple expression. Cherchez ce qui vous fait vraiment aimer cette idée. Vous devez trouver le(s) élément(s) noyau(x) le(s) plus fondamenta(ux) qui font que cette idée est si attirante pour vous. C'est la première chose dont vous avez besoin pour faire le prototype puisque l'intégralité de votre jeu reposera sur ces éléments de base !

Sur une note plus sombre, rappelez-vous que vous allez mourir. Gardez cela à l'esprit, et faites votre jeu comme si c'était le dernier.

Deuxième étape : Prototype

Si le chapitre Idée n'a pas été suffisamment explicite, je vais le répéter : vous ne pouvez pas voir le potentiel (positif ou négatif) d'une idée tant que vous ne l'avez pas prototypée ! Heureusement, c'est souvent l'étape la plus amusante dans le développement d'un jeu parce vous voyez votre idée prendre vie. Cependant, il est aussi important de prototyper correctement afin d'exploiter le résultat le plus efficacement possible.

Lorsque vous prototypez, vous devez être ouvert à l'échec. Si vous craignez un échec, vous ne pourrez jamais sortir ce jeu. J'aime bien conserver mes prototypes hors de mon dossier de sources vérifiés et sur le bureau Windows (ou équivalent), juste parce que cela met l'accent sur l'aspect ludique et temporaire que cette phase de prototypage a besoin pour réussir. Si vous vous plantez sur un prototype, c'est important de vous dire que c'était attendu et absolument normal !

Du fait de cette tolérance à l'échec, vous devez également développer vos prototypes rapidement, parce que les chances sont que vous ferez l'expérience que l'échec de nombreuses fois avant de créer un prototype gagnant. Un gain important de vitesse peut être obtenu par l'optimisation de votre code. Je ne veux pas dire l'optimisation de sa performance, mais l'optimisation de son usage. Vous souhaitez concevoir votre code pour une réutilisation et une simplicité maximale, ce qui implique la création d'une bibliothèque complète de codes réutilisables et pertinents, et de faire un modèle de jeu que vous pouvez copier et réutiliser. Ce modèle de jeu devrait inclure une fenêtre ouverte avec l'affichage d'un sprite, la gestion des entrées et un makefile de travail, etc. Recherchez le confort !

En outre, vous devriez éviter d'utiliser des outils soi-disant « plus faciles » pour le prototypage, mais plutôt tenez-vous-en à ce que vous savez et ce avec quoi vous avez le plus d'expérience, parce que cela donnera le plus rapide des prototypes (et le plus utile). J'écris la plupart de mes prototypes en C++ parce que j'ai quatre ans d'expérience avec ce langage et sa bibliothèque.

Avant de rédiger la moindre ligne de code, assurez-vous que vous avez une question bien définie à laquelle vous souhaitez que votre prototype réponde. Cette question devrait être très simple et devrait impliquer en priorité les parties les plus importantes et/ou « à risque » de votre idée de jeu. Idéalement, vous devriez écrire la question quelque part clairement et de façon visible et ainsi vous ne devriez pas faire de hors-piste. Dès que le prototype répond à cette question et débroussaille un peu le terrain, vous devriez passer à un autre.

Une fois que vous avez fait le(s) prototype(s) qui démontre la puissance de votre idée, trouvez l'élément de base qui le démontre et laissez de côté tout le reste. La simplicité est la clé d'une conception élégante !

Troisième étape : Itération

À ce stade, vous avez fait suffisamment de prototypes pour démontrer le potentiel positif de votre idée. Vous avez également démontré la faisabilité technique de l'idée et la façon dont vous pourriez aborder sa mise en œuvre dans le code de production. Vous avez aussi cerné ce que vous aimez le plus de cette l'idée et avez retiré ce qui n'était pas nécessaire à l'expérience du joueur. Si vous n'avez pas tout cela, revenez en arrière et faites plus de prototypes !

Quand je dis ici itération, je veux parler du développement et de l'amélioration du produit final. Vous devriez éviter d'utiliser un prototype pour votre code de production parce que ce prototype était du sur-mesure pour répondre à une question donnée, et pas pour devenir un jeu complet. À ce stade du développement, vous utilisez vos pratiques de codage les plus pérennes pour construire la version finale du jeu. Il y a beaucoup d'articles qui traitent de ces pratiques, c'est donc désormais le moment d'utiliser ce que vous avez appris sur le codage de haute qualité. Le prototypage n'était pas le moment d'utiliser ces pratiques, car les prototypes vont être jetés de toute façon !

Les itérations doivent passer en revue les éléments du plus important au moins important (tout comme les prototypes). Si vous codez un menu principal ou des fantaisies graphiques avant que vous n'ayez votre mécanique principale d'opérationnel, vous faites quelque chose de très, très mal ! Personne ne se soucie de vos détails graphiques ou de vos menus, ils se soucient du gameplay ! Faites le « jouet » d'abord, et gardez les menus et le fignolage pour la fin.

Bien que vous travailliez maintenant sur le code « final », vous devriez toujours continuer à expérimenter. Soyez très prudent avec de telles expériences, car elles peuvent vous faire perdre votre vision de cet élément de base sur lequel vous vous concentriez avant. Assurez-vous que vous savez pourquoi votre jeu est intéressant. Neuf fois sur dix, ce n'est pas parce que vous avez une physique réaliste pour un PNJ ou que vous pouvez extraire les métaux sous terre ! Vos expériences devraient être séparées de la production (si vous utilisez un gestionnaire de code source, c'est là où la « ramification » devient utile) et facilement annulables. Vous devriez vous concentrer sur de telles expériences pour l'amélioration de l'élément de base uniquement ! Si l'expérience est trop divergente de l'élément de base, vous devriez la spécifier et la prototyper plus tard.

Ne jamais, en aucune circonstance, optimiser prématurément ! En tant que programmeur, vous avez probablement entendu parler de KISS, qui signifie « Keep It Simple, Stupid ! » (NdT : Restez simple et stupide). Suivez ce principe autant que vous le pouvez ! Jonathan Blow parle d'algorithmes et de structures de données et comment elles sont optimisées pour des performances ou la mémoire, mais ne sont pas « optimisées pour l'usage ». Il est plus important de finir un jeu dans un mois qui tourne à 20 FPS que de finir dans un an pour 60 FPS !

Concernant le codage pendant le cycle itératif, vous souhaitez identifier des composants qui peuvent facilement être réutilisés dans de futurs jeux et les ajouter à votre bibliothèque plutôt que de les rendre spécifiques à votre jeu. Cela permettra non seulement d'améliorer votre bibliothèque, mais aussi de rendre chaque jeu suivant (et prototypes) plus rapide à développer. N'essayez pas de réutiliser des composants qui sont trop spécifiques cependant !

Pendant que vous enrichissez par itération votre bibliothèque de composants, concentrez-vous sur les fonctionnalités qui a) sont utiles non pour leur performance, mais pour ce qu'elles accomplissent et b) d'encourager la réutilisation du code et ainsi raccourcir les temps de développement. Par exemple, la détection et la résolution des collisions sont extrêmement utiles et cela vaut la peine de prendre son temps à les implémenter, mais la mise en œuvre d'une routine de collision « optimisée » n'en vaut pas la peine. Rappelez-vous, ne faites pas quelque chose, sauf si vous en avez besoin ! Comme exemple de fonctionnalités (b), j'ai récemment mis en œuvre mon propre système COM (ou CES) parce que j'ai vu combien la réutilisation du code devenait plus facile avec elle. Bien sûr, cela impacte négativement les performances, mais l'idée de composants dynamiques, portables et réutilisables compense cet impact par l'optimisation de l'usage !

Si vous en êtes à ce point, il n'y a aucune raison d'abandonner le projet ! Bien sûr, vous avez beaucoup appris de vos erreurs de codage et un recodage complet rendrait probablement le projet meilleur, mais ne perdez pas votre temps ! Beaucoup de développeurs débutants de jeux abandonnent sans cesse des projets en plein milieu du développement. C'est la principale raison pour laquelle ils sont encore des développeurs débutants ! Vous avez touché ce qui est communément connu comme « le Mur », le point où vous ne voulez plus continuer le développement d'un projet. Il suffit de l'abattre et de persister, sinon tout le travail que vous avez réalisé ne vaudra plus rien (pour les joueurs, au moins) ! J'ai publié sept jeux, et deux d'entre eux se sont avérés être un enfer vers la fin. J'ai persisté, et j'ai appris de mes erreurs. Vous devez terminer complètement vos projets ! N'abandonnez pas !

Cette étape de l'itération sera fortement influencée par l'étape suivante, qui est...

Quatrième étape : Tests

Je dois admettre, j'ai beaucoup de mal avec les tests. Il est assez difficile de les faire correctement, mais lorsque c'est fait correctement, cela aboutit à améliorer votre jeu considérablement. La phase de tests est assez simple, donc je vais vous présenter quelques règles de base que vous pourrez utiliser pour les faire plus efficacement.

Tout d'abord, testez tôt, testez souvent ! Vous ne pouvez jamais trop tester ! Testez dès le stade du prototypage, et pas plus tard que la publication. Vous verrez que certaines parties de votre jeu qui sont parfaitement claires pour vous seront complètement confuses pour d'autres, par conséquent, ne développez pas dans le vide !

Ensuite, diversifiez ! Cela inclut les personnes et la technologie. Exécuter votre jeu sur autant d'appareils et de systèmes d'exploitation que vous le pouvez. Un de mes jeux fonctionnait bien sur mes deux ordinateurs (avec des configurations très différentes) et des systèmes d'exploitation virtuels, mais avait des bogues de déplacement qui ruinaient mon jeu sur la plupart des autres ordinateurs ! Quand il s'agit de personnes, n'écartez aucune catégorie de gens. Laissez quiconque jouer à votre jeu, peu importe son sexe, son âge, ou ses centres d'intérêt ! Plus vos testeurs seront divers, plus votre public sera divers, et moins votre jeu sera subjectif.

Ne gaspillez pas vos testeurs. Après un certain temps, ils deviendront très partiaux, notamment parce qu'ils auront vu les versions précédentes du jeu. Il est préférable que vos testeurs n'aient aucun préjugé et un esprit ouvert, alors assurez-vous de changer les gens souvent.

L'observation est la chose la plus importante que vous devez apprendre à faire lors d'une session de tests. Regardez quand les gens parlent, quand les gens arrêtent de parler, quand leur personnage meurt, quand ils réussissent, et quand ils arrêtent de jouer. Les probabilités sont que la plupart des gens vont faire la même chose, malgré l'influence de votre simple présence. L'observation est aussi la seule chose que vous devez faire pendant une session de tests. Ne leur indiquez pas le contexte, ou expliquer quelque chose, ou les aider, ou quoi que ce soit. Il suffit de regarder et de prendre des notes.

Après qu'ils ont fini de jouer, vous devriez leur poser les trois questions suivantes :

• Qu'avez-vous aimé ?
• Qu'est-ce que vous détestez ?
• Qu'est-ce qui vous a dérouté ?

Cela vous donnera des retours très précis sur ce dont vous avez besoin de mettre l'accent et ce que vous devez changer. Aussi, lorsque le joueur vous fait des suggestions pour améliorer le jeu, ne vous focalisez pas sur la suggestion, mais sur les causes qui ont fait qu'il vous a fait cette suggestion.

Cinquième étape : Finalisation !

Si vous en êtes rendu à ce point, vous êtes prêt à terminer votre jeu ! Les derniers 10 % de développement ressemblent souvent à 90 %, mais il ne faut pas abandonner ! N'oubliez pas que même un jeu à « 90 % terminé » est un jeu qui ne vaut rien ! La finition c'est avant tout vous pousser à travers le Mur et faire en sorte que tous ces bouts épars soient rattachés entre eux. Rappelez-vous jusqu'où vous êtes parvenu, et regardez la distance qu'il vous reste à parcourir. Ce n'est pas si loin que ça !

Pendant que vous apportez la touche finale et packagez le tout pour la première fois, testez sur autant de plateformes que possible. Vous devez tout tester, même vos fichiers « lisez-moi » (une fois mon caractère de nouvelle ligne était de type Unix et cela ne fonctionnait pas sur les ordinateurs Windows  ) !

Il est recommandé que le cheminement qu'un joueur emprunte pour découvrir votre jeu et pour ensuite y jouer soit le plus court et le plus direct possible. Abaissez toutes les barrières que vous pouvez, et faites en sorte que votre jeu soit facile à juger. La praticité est essentielle à ce stade.

Si vous vous demandez pourquoi votre jeu ressemble toujours à un projet « amateur », c'est parce qu'il n'est pas assez fignolé. De très petites choses, comme les menus ou les écrans de chargement, peuvent faire une grande différence sur les impressions du joueur envers votre jeu. Rappelez-vous, la première chose que le joueur verra sera l'une de ces choses, il est donc très important de bien les faire. Étudiez les jeux « professionnels » et les raisons pour lesquelles ils ont l'air plus « professionnels ». Le fignolage est en grande partie une question de feeling, ce qui fait qu'il est juste nécessaire de pratiquer pour y arriver, mais le temps supplémentaire en vaut la peine.

Si vous êtes extrêmement gêné par la « qualité » de votre jeu ou si vous savez qu'elle a de sérieuses lacunes, corrigez autant que vous le pouvez et publiez-le quand même. Terminez votre projet, apprenez de vos erreurs et faites mieux pour le prochain jeu.

Conclusion

Vous venez de faire un jeu ! Félicitations ! Maintenant, faites-en à nouveau, évitez seulement les erreurs qui ont causé du tort à la qualité de votre dernier jeu.

J'ai couvert beaucoup d'aspects, donc je vais juste faire un bref rappel de chaque étape :

Idée

• le prototypage reste essentiel ;
• fixez-vous un objectif et des contraintes bien définies ;
• donnez-vous un peu de temps ;
• trouvez l'élément central sur lequel repose votre idée ;
• vous allez mourir, alors faites en sorte qu'elle ait de l'importance !

Prototypage

• soyez ouvert à l'échec ;
• faites-le aussi rapidement que possible, et rendez votre code le plus pratique possible ;
• utilisez les outils que vous connaissez déjà ;
• ayez une question bien définie à résoudre.

Itération

• faites du code de haute qualité ;
• allez des éléments les plus importants aux moins importants ;
• expérimentez, mais ne perdez pas de vue l'élément de base ;
• KISS / Optimisez l'usage / PAS d’optimisation prématurée ;
• ajoutez le code réutilisable à votre bibliothèque ;
• n'ajoutez que les fonctionnalités à votre bibliothèque qui rendent le développement plus rapide ou qui ajoutent des possibilités (ne codez pas quelque chose pour améliorer la vitesse, sauf si vous en avez besoin) ;
• ne pas abandonner ou renoncer à un projet à ce niveau !

Tests

• testez tôt, testez souvent ;
• diversifiez les origines de vos testeurs ;
• remplacez vos testeurs trop utilisés ;
• posez des questions.

Finalisation

• persistez ;
• testez, testez, testez !
• rendez facile la découverte de votre jeu
• fignolez ;
• publiez-le et apprenez de vos erreurs

Merci d'avoir pris le temps de lire ça ! J'espère que je vous ai aidé !