Jump to content

  • Log In with Google      Sign In   
  • Create Account






Conseils généraux sur le processus de développement solo d'un jeu (3/5)

Posted by yahiko00, in Développement 19 July 2013 · 188 views

Cet article est la traduction de la troisième partie de celui ci : General Tips on the Process of Solo Game Development (Macoy Madson)
La seconde partie en français est disponible ici : Conseils généraux sur le processus de développement solo d'un jeu (2/5)

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. A 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érationel, 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 travaillez 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 est extrêmement utile 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 ...

La quatrième partie en français est disponible ici : Conseils généraux sur le processus de développement solo d'un jeu (4/5)




PARTNERS