URL: https://linuxfr.org/news/je-cree-mon-jeu-video-e03-la-version-zero Title: Je crée mon jeu vidéo E03 : la version zéro ! Authors: rewind NeoX, Benoît Sibaud, claudex, Nÿco et palm123 Date: 2013年10月12日T02:11:50+02:00 License: CC By-SA Tags: gamedev et création_jeu Score: 49 «Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au [tag gamedev](http://linuxfr.org/tags/gamedev/public). Dans l'[épisode 02](http://linuxfr.org/news/je-cree-mon-jeu-video-e02-le-jeu-et-ses-challenges), on a vu le principe du jeu et ses principaux challenges. Beaucoup de commentaires fort pertinents sont venus agrémenter cette première description. Je vais en reprendre une partie avec quelques liens fort utiles à lire quand on commence un jeu (et que c'est le premier). ---- [Akagoria, la revanche de Kalista](https://gitorious.org/akagoria) [libtmx, une bibliothèque pour lire les fichiers TMX](https://github.com/jube/libtmx) [Le tag gamedev](http://linuxfr.org/tags/gamedev/public) ---- # Premier jeu Quand on commence un premier jeu, il y a quelques conseils à retenir. J'ai lu beaucoup de choses avant de me lancer et ça a été très instructif, j'ai retrouvé ces conseils dans les commentaires du dernier épisode et il me paraît intéressant d'en faire un résumé. Je vous conseille donc l'excellent site [GamedevTuts+](http://gamedev.tutsplus.com/) qui contient beaucoup de choses intéressantes, dont deux articles indispensables. ## Making Your First Game: A Walkthrough for Game Developers Dans l'article [Making Your First Game: A Walkthrough for Game Developers](http://gamedev.tutsplus.com/articles/business-articles/making-your-first-game-a-walkthrough-for-game-developers/), Steven Lambert explique quelles sont les quatre étapes nécessaires pour créer un jeu. ###Premièrement, il faut planifier. Il faut écrire tout ce qui passe par la tête et se poser des questions et y répondre. Et il faut évaluer la quantité de travail global nécessaire au développement complet du jeu avant de commencer à coder. L'auteur cite d'ailleurs une phrase assez marrante mais tellement réaliste (et qui pourrait s'appliquer à d'autres projets) : «Souvenez-vous, les premiers 90% de votre jeu prennent 90% de votre temps ; les derniers 10% prennent les 90% restant de votre temps. Planifier en conséquence.» ###Deuxièmement, il faut prototyper. Il est nécessaire de savoir si les mécaniques du jeu vont fonctionner avant de se lancer définitivement dans le code. Et donc, il faut avoir des bouts de code (crades) pour tester des fonctionnalités vite fait et se rendre compte si elles seront utiles et amusantes ou pas. Cette phase est importante car une fois terminée, tout ce qui sera dans le jeu sera déterminé, avec un bout de code qui marche à peu près à intégrer. ###Troisièmement, il faut développer. Et c'est long, mais si on a bien réussi les deux premières étapes, ça va. Il faut passer les coups de mou mais pour ça, il y a des techniques dont on va parler après. Et puis il ne faut pas hésiter à ré-utiliser tout ce qui existe déjà : bibliothèques, sprites, sons, musiques ! Et il ne faut pas hésiter à tailler dans le lard : «Avant de commencer à coder, enlevez 90% des fonctionnalités attendues» ###Quatrièmement, il faut sortir le jeu. À un moment, il faut montrer ce qu'on a fait et affronter la critique. Le jeu ne sera pas parfait, il faut l'admettre, mais il sera fini. ## How to Succeed at Making One Game a Month Dans l'article [How to Succeed at Making One Game a Month](http://gamedev.tutsplus.com/articles/business-articles/1gam-how-to-succeed-at-making-one-game-a-month/), Christer Kaitila donne quelques astuces pour réussir à finir un jeu, après avoir réalisé douze jeux en douze mois en 2012. 1. Le brainstorm. C'est la phase pendant laquelle on couche sur papier toutes les idées saugrenues qu'on a. Il s'agit de faire dans la quantité, pas dans la qualité. Et ensuite, il faut en enlever 99%. 2. Faire deux listes : ce dont on a besoin et ce qu'on veut. Il s'agit de réduire la liste pour parvenir au produit viable minimum, celui duquel on ne peut plus rien enlever. Le reste doit disparaître pour le moment. 3. Écrire le pitch. Il faut pouvoir décrire le jeu en deux phrases, comme si c'était la description derrière la boîte dans le magasin. 4. Dessiner un brouillon du jeu en action. Une douzaine de dessins grossiers doivent permettre de voir à quoi le jeu ressemblera à la fin. Ça permet de savoir où placer quoi une fois le code venu. 5. Faire une première version jouable sans art. C'est le premier point de sauvegarde. Faire une version sans art permet de se concentrer sur l'essence du jeu. 6. Commencer à rendre le produit viable minimum joli. À partir de ce moment, on peut améliorer le jeu petit à petit, tout en faisant attention aux performances. 7. Première version. C'est le deuxième point de sauvegarde, il n'y a qu'un seul niveau, mais c'est à peu près jouable et testable. 8. Travailler sur une fonctionnalité à la fois. Il ne faut pas commencer 36 choses à la fois, il faut prendre les tâches les unes après les autres pour toujours avoir une version qui marche. 9. Continuer à atteindre des points de sauvegarde. En travaillant de manière incrémentale, on a en permanence une version jouable qu'on peut éventuellement abandonner telle quelle. 10. Atteindre la ligne d'arrivée. À un moment, il faut décider que le jeu est terminé. Le reste des fonctionnalités de départ sera dans une version 2.0 ! ## Conclusion [Finir un jeu, c'est une qualité](http://makegames.tumblr.com/post/1136623767/finishing-a-game) ! Et même s'il y a des techniques, ça reste difficile. Là, j'en suis plutôt au début, donc ça ne pose pas encore de problèmes. Mais je me dis qu'il faudra que je relise tout ça quand je serai en panne. Voici quelques autres sites dignes d'intérêt (pour des débutants ou des confirmés) : - [gamedev.net](http://www.gamedev.net/page/resources) - [The Game Programming Wiki](http://content.gpwiki.org/index.php/Main_Page) # Version 0 ! La version 0 du jeu est donc sortie. Pour l'instant, on peut bouger un sprite représentant un personnage sur un fond de carte, rien de plus. C'est donc bien une version 0. Ha si, le jeu a désormais un nom : « _Akagoria, la revanche de Kalista_ ». Et un [dépôt sur gitorious](https://gitorious.org/akagoria) ! Et voici une toute première capture d'écran. ![Akagoria version 0.0](http://www.akagoria.org/screenshots/0.0.0/akagoria-0.png) Maintenant, place au making-of the cette version 0. ## La définition du jeu Comme conseillé, notamment par [Julien Jorge](http://linuxfr.org/users/julien_jorge), j'ai écrit une sorte de [guide du jeu](https://gitorious.org/akagoria/akagoria/source/HEAD:doc/game.fr.md) qui contient le scénario assez détaillé, des indications sur l'univers du jeu, quelques quêtes annexes, la description de l'héroïne, les premiers personnages secondaires, les systèmes d'évolution et de progression, la liste des sorts, des objets et des créatures. Le tout en français pour me faciliter le travail. C'est un travail en cours, mais je pense qu'il est essentiel car il permet de se fixer des objectifs, de se rendre compte du nombre de choses à développer, et donc de pouvoir planifier. Du coup, j'ai commencé à écrire [une petite roadmap](https://gitorious.org/akagoria/akagoria/source/HEAD:doc/roadmap.md) avec cette liste. Il n'y a pas encore de dates, j'attends d'avoir fini d'écrire à peu près la description complète pour fixer les itérations successives, en essayant de mêler à chaque fois du code et du graphisme. ## Le sprite militaire Puisqu'on en parle, il faut parler de ce sprite. Le sprite militaire n'est évidemment pas le sprite de l'héroïne, vous l'aurez remarqué. C'est mon premier essai pour fabriquer moi-même mes sprites. Et pour ceux qui se poseraient des questions, je ne suis pas doué, j'ai juste suivi pas à pas [un excellent tutoriel sur la création d'un sprite en vue de haut](http://2dgameartforprogrammers.blogspot.fr/2012/04/top-down-view-soldier.html) avec le logiciel [Inkscape](http://inkscape.org/?lang=fr). D'ailleurs, mon militaire est beaucoup moins joli que dans le tutoriel mais c'est bien suffisant pour l'instant. Du coup, j'en ai profité pour essayer de créer un sprite plus simple, un puits vu de haut (qu'on distingue sur la capture d'écran). Et je dois dire que je suis plutôt satisfait du résultat. Je ne maîtrise pas Inkscape, mais je me dis qu'à l'usage, je vais m'améliorer. Et puis, vu la quantité de sprites à créer, j'ai plutôt intérêt à m'améliorer. J'en profite pour refaire de la pub pour le blog [2D Game Art For Programmers](http://2dgameartforprogrammers.blogspot.fr/) qui est une mine d'or. Il ne faut pas hésiter à remonter assez loin pour voir quelques techniques de base. ## La carte Pour réaliser la carte, j'ai utilisé l'excellent [Tiled](http://www.mapeditor.org/) qui permet de créer des cartes à base de tuiles. J'ai utilisé un [tileset de base](https://gitorious.org/akagoria/akagoria/source/HEAD:src/share/akagoria/maps/basic.png) que j'ai bricolé vite fait. Cette petite île sera mon terrain expérimental pour tester les fonctionnalités dans les premières versions du jeu. Pour lire le [format TMX](https://github.com/bjorn/tiled/wiki/TMX-Map-Format) (qui est le dialecte XML utilisé par Tiled), j'ai concocté une [petite bibliothèque de lecture de fichier TMX](https://github.com/jube/libtmx). Il en existait plusieurs mais aucune qui ne me plaisait et aucune maintenue. Pour tester ma bibliothèque, j'ai écrit un petit programme de rendu de carte avec SFML et j'ai utilisé les [cartes de Newton Adventure](http://devnewton.bci.im/projects/newton_adventure/dir?name=game/data/quests) qui utilise une version Java de Tiled, légèrement différente. En tout cas, c'est un peu lent mais ça fonctionne ! Une des limites est que le rendu se fait dans une texture et donc, ne peut pas dépasser 8192x8192 pixels (soit 256x256 tuiles de 32x32). Je chercherai plus tard une autre bibliothèque de rendu pour enlever cette limite. Comme j'aimerais avoir un très grand terrain de jeu, la carte finale sera certainement générée procéduralement. Du moins le fond de carte. Ensuite, j'y placerai les lieux et les items dont j'ai besoin. J'ai actuellement deux étudiants qui travaillent sur cet aspect de [génération procédurale de carte](http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/), je pense qu'ils sont capables de produire un bon résultat. ## Le système à entités Évidemment, j'ai utilisé le système à entités présenté lors de l'épisode 01. En plus, j'ai écrit une petite [gem Ruby pour générer automatiquement tout un tas de fichiers](https://gitorious.org/akagoria/akagoria/source/HEAD:tools/es_generator) à partir de [simples descriptions](https://gitorious.org/akagoria/akagoria/source/HEAD:src/data/es) en [YAML](http://yaml.org/). Ce n'est pas encore parfait, il manque une validation des fichiers (genre ne pas référencer un composant qui n'existe pas) mais ça fait le boulot de base. J'ai inclus les fichiers générés dans le dépôt pour éviter d'avoir Ruby comme prérequis pour contruire le jeu. En revanche, pour un développeur, c'est obligatoire. Ces fichiers sont clairement marqués comme générés. ## Pour ceux qui veulent tester Pour ceux qui parviennent à compiler et qui vont tester le jeu en l'état, voici quelques conseils. Il faut utiliser les flèches directionnelles pour bouger. Par défaut, la vue est fixe, c'est-à-dire que le personnage pivote et le cadre reste avec la même orientation. En appuyant sur la touche `V`, on change de vue et on passe en vue mobile, le personnage est fixe et tout pivote autour de lui. Je ne sais pas quelle vue est la meilleure, j'aime bien les deux. Si vous voulez zoomer et dézoomer, vous pouvez utiliser `PageUp` et `PageDown`. Cette fonctionnalité sera supprimée dans la version finale, mais elle permet actuellement de voir la carte en entier. La touche `Echap` permet d'arrêter le jeu. ## Moyen de communication Comme certains l'ont demandé au dernier épisode, il existe désormais un canal IRC #akagoria sur le réseau freenode. # La prochaine fois... Pour le prochain épisode, on parlera de collisions et normalement, le héros ne rentrera plus dans le puits. J'essaierai aussi d'ajouter quelques sprites de différentes formes et différentes tailles pour tester les collisions. Si vous voulez que j'approfondisse un des aspects évoqués dans cet épisode, n'hésitez pas à le demander dans les commentaires.

AltStyle によって変換されたページ (->オリジナル) /