Jump to content

  • Log In with Google      Sign In   
  • Create Account

Le Journal de Yahiko



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

Posted by , in Développement 19 July 2013 - - - - - - · 491 views

Cet article est la traduction de la cinquième partie de celui ci : General Tips on the Process of Solo Game Development (Macoy Madson)
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)

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 "lisezmoi" (une fois mon caractère de nouvelle ligne était de type Unix et cela ne fonctionnait pas sur les ordinateurs Windows Posted Image) !

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, corriger 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 au 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 abandonnez ou renoncez à un projet à ce niveau !
Tests
  • Testez tôt, testez souvent
  • Diversifiez vos les origines de nos 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é !



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

Posted by , in Développement 19 July 2013 - - - - - - · 357 views

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

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 abouti à 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 bugs 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êts ! 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és 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 aient 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.

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


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

Posted by , in Développement 19 July 2013 - - - - - - · 395 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