«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.
Dans l'épisode 02, 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).
Sommaire
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+ 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, 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, Christer Kaitila donne quelques astuces pour réussir à finir un jeu, après avoir réalisé douze jeux en douze mois en 2012.
- 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%.
- 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.
- É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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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é ! 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) :
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 ! Et voici une toute première capture d'écran.
Maintenant, place au making-of the cette version 0.
La définition du jeu
Comme conseillé, notamment par Julien Jorge, j'ai écrit une sorte de guide du jeu 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 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 avec le logiciel Inkscape. 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 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 qui permet de créer des cartes à base de tuiles. J'ai utilisé un tileset de base 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 (qui est le dialecte XML utilisé par Tiled), j'ai concocté une petite bibliothèque de lecture de fichier TMX. 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 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, 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 à partir de simples descriptions en YAML. 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.
Aller plus loin
- Akagoria, la revanche de Kalista (267 clics)
- libtmx, une bibliothèque pour lire les fichiers TMX (124 clics)
- Le tag gamedev (255 clics)
# Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 14 octobre 2013 à 08:53.
Elle est même très différente:
Le format de fichier, tmx, a une DTD obsolète et à chaque nouvelle version, Tiled apporte de subtils changements au format tmx et aucune bibliothèque n'est vraiment en phase avec le logiciel, même celle en java développé par l'auteur lui même. J'ai contacté ce dernier et apparemment il n'a ni le temps, ni l'envie de maintenir quelque-chose de stable et de bien défini.
J'ai cherché des alternatives, sans succès, la plupart des autres logiciels d'édition de niveaux 2d sont soit pwivateurs, soit abandonnés…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Personnellement, je considère que la version qui va bien, c'est la version qui se trouve sur le github à la page indiquée en lien. Elle contient tout je pense, y compris les différences que tu mentionnes. Après, j'ai aussi regardé ce que générait Tiled-Qt pour me faire une idée plus précise et à l'avenir, je pense que je vais me concentrer sur ce sous-ensemble.
J'attends avec impatience la prochaine version qui devrait permettre de tourner les images parce que je vais en avoir besoin. Mon puits, par exemple, je l'ai défini en dur dans le code, et j'ai pu le tourner. Je n'aurais pas pu faire la même chose avec Tiled pour l'instant mais je pourrai le faire dans la prochaine version.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 14 octobre 2013 à 09:22.
Le message, c'était surtout "attention, tu peux à tout moment te retrouver avec une nouvelle version incompatible avec tes données et ton code". Je pense qu'il faut considérer les fichiers tmx créés par Tiled comme les xcf de gimp: non fiable comme format de stockage.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Oui, c'est pour ça que je préfère maintenir ma bibliothèque de lecture de TMX. Au moins, une fois le jeu fini, je pourrai livrer des cartes que je saurai lire moi-même (avec l'inconvénient que si le format évolue, elles ne seront plus lisible dans l'outil Tiled). De toute façon, à moins de réinventer la roue, comme tu l'as dit, il n'y a pas beaucoup d'alternatives (voire aucune).
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Faire des formats de fichiers stables et maintenir la rétrocompatibilité, ça n'est malheureusement pas courant en IT :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'avais envisagé plusieurs fois de faire un format basé sur protobuf pour gérer ce problème. Ca pourrait ressembler à:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Tu gères uniquement les objets là (ce qui est dans ObjectGroup dans TMX), c'est ça ?
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Dans le moteur physique de Newton, le monde n'est pas tuilé, donc tout est "objet" avec une forme! Je me sers des tuiles parce que c'est plus facile d'en dessiner une vingtaine et de les combiner pour faire des niveaux que de tout redessiner à chaque fois.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Oui, je procède de la même manière, seul mon fond de carte est à base de tuiles. Tout le reste (comme mon puits) est défini sans s'aligner sur les tuiles. Ça permet d'être plus flexible et d'avoir un univers moins carré, plus bancal.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Voilà les remarques qui me viennent à l'esprit en voyant ce format.
L'ellipse est défini comme un rectangle plutôt que comme un cercle (c'est-à-dire qu'on pourrait définir ses rayons plutôt que ses diamètres). Je ne sais pas lequel est le mieux mais j'ai une préférence pour les rayons.
À quoi correspond la position : est-ce le «centre» de chaque forme ?
Il n'y a pas la définition du Polygon. Et il n'y a pas de Polyline. La question précédente devient alors nettement plus compliquée à répondre.
Il n'y a pas d'angle. Si on devait ajouter un angle, je le mettrais dans Position. Comme ça, on sait par rapport à quel point on fait la rotation.
Après, il faut fabriquer l'éditeur qui va avec ;)
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
C'est juste un essai vite fait!
Pour l'éditeur, Tiled permets d'avoir des objets avec ces différentes formes. J'avais même fait un patch pour pouvoir texturer ces formes, mais il a été refusé: je ne tombe jamais d'accord avec l'auteur de ce soft :-( J'ai hésité plusieurs fois à faire un fork bien sauvage, mais je n'ai pas le temps de maintenir un logiciel libre de plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 1.
Oui, je pense que j'ai le même besoin que toi sur cet aspect : pouvoir définir des formes qui correspondent à des formes de collisions directement dans le fichier. Pour l'instant, ça va aller pour les objets qu'on peut placer sur la carte. Mais pour les objets qui bougent, ça va être un peu plus difficile mais j'aimerais avoir le même format ou du moins un format proche pour les deux types (parce que derrière, ça va s'initialiser de la même manière).
J'ai l'impression qu'il n'acceptent pas beaucoup de patchs et que tu n'es pas le seul à ne pas tomber d'accord avec lui.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le logiciel est populaire, donc beaucoup de gens proposent des patchs qui correspondent à leurs besoins qui ne sont pas forcément ceux de l'auteur. Peut être que le fork est la seule solution!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Oui, mais je suis un peu comme toi, pas trop le temps de maintenir un fork. Donc, pour l'instant, on garde ça :)
[^] # Re: Tiled
Posté par GaMa (site web personnel) . Évalué à 2.
Je suis tout à fais d'accord.
Beaucoup de jeux (estimation pifaumetre) utilisent des formats spécialisés voir personnalisés :
Quand je bossais dans le monde du jeu vidéo, on chargeait des assets directement au format utilisé par le moteur. Les graphistes travaillaient dans leurs formats et la conversion se faisait en même temps que la compilation. D’ailleurs ça faisait complètement partie de la compilation, les scripts généraient des fichiers c qui indexaient les assets (à coup d'enum et de tableau). (il faut aussi dire que l'on avait pas de système de fichier et qu'on précharger les assets par paquet pour éviter les io).
Si le tmx change tout le temps, je pense que vous gagnerait à définir votre propre format qui colle à votre moteur et d'avoir un script de conversion qui transforme du tmx:
La contrepartie, c'est que c'est moins hackable mais vu que c'est du libre, c'est pas si contraignant.
(C'est d'ailleurs ce que rewind fait avec son script es_make pour générer le système d'entités)
(Ça vaut aussi pour la compilation svg/xcf => png)
Matthieu Gautier|irc:starmad
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 2.
Il ne change pas du tout au tout. Disons qu'à chaque version, il peut y avoir quelques petites modifications qui peuvent devenir chiantes à maintenir. De toute façon, ça ne change pas le reste de ton raisonnement. Mais il faut du coup créer et documenter les formats internes. On peut utiliser protobuf comme le fait devnewton, ce qui permet d'avoir un fichier lisible et compréhensible du contenu des fichiers.
Tout à fait ! Mais là, c'est pour éviter d'écrire du code redondant.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ah je viens de voir que la prochaine version permettra de gérer des scripts d'import/export en python \o/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par moi1392 . Évalué à 2.
J'ai comme l'auteur, écrit moin petit moteur de rpg quand j'étais encore étudiant (mais moi, je ne l'ai pas fini, même s'il était très avancé)
Et du coup, je me suis écrit mon éditeur en Qt.
En fait, c'est pas si dur que ça, le premier avantage, est qu'il peut utiliser le même code que ton jeu pour attaquer les fichiers, donc tu es sûr d'avoir
les même boguesle même résultat.Ensuite, une fois une base qui marche, tu peux ajouter les fonctionnalités dont tu as besoin au fur et à mesure, et là, c'est très rapide du coup, car tu ne codes que la feature qui t'intéresse juste après l'avoir implémenté dans le jeu.
Après c'est sur, ça fait un peu syndrome nih…
[^] # Re: Tiled
Posté par rewind (Mastodon) . Évalué à 3.
Oui, et puis au final, tu passes plus de temps à développer des outils plutôt que ton jeu. Je veux éviter ça au maximum. Le seul cas où ça peut valoir le coup, c'est si le développement est mutualisé.
[^] # Re: Tiled
Posté par reynum (site web personnel) . Évalué à 2.
Je vais peut être dire un bêtise mais je crois que "Battle for Wesnoth" en propose une.
kentoc'h mervel eget bezan saotred
[^] # Re: Tiled
Posté par reynum (site web personnel) . Évalué à 2.
Je suis tombé là dessus par hasard (en regardant des trucs à base de sfml sur youtube) je me suis dis que ça pourrait peut être intéresser.
http://www.youtube.com/watch?v=E1KGlngYJ9E
kentoc'h mervel eget bezan saotred
# petite erreur
Posté par moi1392 . Évalué à 1.
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.
Je pense que tu voulais dire : "les premiers 90% de votre jeu prennent 10% de votre temps"
En fait dans le domaine du management en général, mais je l'ai aussi beaucoup entendu en développement informatique, on parle plutôt de la règle des 80/20 connue aussi sous le nom de principe de pareto [[http://fr.wikipedia.org/wiki/Principe_de_Pareto]]
[^] # Re: petite erreur
Posté par rewind (Mastodon) . Évalué à 6.
Non, ce n'est pas une erreur, c'est voulu. Je pense que c'est un détournement humoristique de cette règle de 80/20.
[^] # Re: petite erreur
Posté par moi1392 . Évalué à 2.
Je ne l'avais pas compris comme cela, mais effectivement, avec mon mode humour en marche, je comprends ce qu'il a voulu dire et ça me fait sourrire :)
[^] # Re: petite erreur
Posté par djano . Évalué à 2.
C'est référencé et sourcé sur Wikipedia en anglais: 90-90 rule
[^] # Re: petite erreur
Posté par claudex . Évalué à 4.
C'est aussi sourcé dans la dépêche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Map
Posté par dactar (site web personnel) . Évalué à 2.
Hello,
J'ai également créé un jeu de ce style il y a bien longtemps sur Atari ST en GFA Basic. Pour la carte, j'avais créé une image bitmap avec un logiciel de dessin et assigné chaque couleur à un style de tuile. Pour l'affichage une petite routine analysait les pixels de l'image et affichait les tuiles en fonction de leurs couleurs. J'étais à l'époque limité à 16 couleurs soit à 16 tuiles, donc si tu utilises le même principe avec 16 millions de couleurs tu auras ton équivalent en tuiles.
Concernant la map énorme que tu désires, il n'y a pas de limite, soit tu crées une très grande image, soit tu découpes ta map par secteur, chaque secteur ayant sa propre image et tu colles le tout en mémoire dans un tableau de secteurs.
Bonne chance pour la suite :)
[^] # Re: Map
Posté par rewind (Mastodon) . Évalué à 2.
En fait, avec la première solution, ça rame sévèrement. Là, la carte fait 250x250 tuiles, ça se passe bien. Mais à 1000x1000 tuiles, ça ralentit sur mon laptop de développement. Et c'est juste l'affichage des tuiles, il n'y a rien sur la carte. Du coup, je me dis qu'il faudra à coup sûr passer par la deuxième solution (ce que j'ai appelé multimap dans la roadmap). Et là encore, deux solutions s'offrent à moi : soit je découpe directement la grosse carte en plusieurs fichiers TMX (ça peut éventuellement se faire via un script) et je charge uniquement la carte courante et les cartes adjacentes ; soit je garde ma grosse carte et je n'affiche que les tuiles et les objets visibles (et quelques autres pour être certains de ne pas avoir de problèmes sur les bords). Je me dis que la première solution sera sans doute moins optimisée et peut-être plus simple, mais je n'en ai aucune certitude. Bref, la réflexion continue.
[^] # Re: Map
Posté par moi1392 . Évalué à 3.
ça m'étonne tout de même.
1000x1000, même en supposant que tu as besoin de 16 bytes par tuile (ce qui me semble beaucoup)
ça fait quelqueche proche des 16 Mb en mémoire.
Après, je comprends que tu n'as pas forcément envie de consommer autant pour une carte d'un jeu (surtout que la lecture sur disque va prendre du temps) ou que tu compte peut-être passer à une échelle au dessus.
Sais-tu quelle partie fait ramer dans ton cas ?
[^] # Re: Map
Posté par moi1392 . Évalué à 4.
ok, ça m'apprendra à ne pas lire jusqu'au bout…
Donc tu affiche TOUTE ta carte à chaque fois ? c'est bien cela ?
Je pense que c'est une mauvaise idée, c'est très simple de n'afficher que la partie visible, avec un tout petit peu d'algorithmique bien encapsulé, une fois écrit, tu n'as plus besoin d'y toucher et tu as un rendu au poil.
[^] # Re: Map
Posté par rewind (Mastodon) . Évalué à 2.
Oui, c'est bien cela :)
Oui, en y réfléchissant en marchant à midi pour rentrer chez moi, je me suis dit que c'était pas si dur que ça. Du coup, je me garde ça au chaud pour plus tard.
[^] # Re: Map
Posté par moi1392 . Évalué à 2. Dernière modification le 14 octobre 2013 à 15:08.
Dans mon moteur, le rendu était fait à l'aide d'OpenGL (avec une projection orthogonale)
Donc il me suffisant de dessiner les tuiles visibles (même partiellement) et le moteur OpenGL s'occupait du clipping pour moi.
Si tu dois le faire à la main, un simple clipping sur les coordonnées à l'écran de chaque rectangle de tuile visible avant rendu est suffisant et ça n'est vraiment pas très long en terme de calcul.
Par contre, le gros de l'élagage doit être déjà fait (tu ne dois itérer que sur tes tuiles visibles), mais c'est très simple aussi à coup de division et modulo d'avoir les bornes en i et en j de la grille à dessiner.
[^] # Re: Map
Posté par GaMa (site web personnel) . Évalué à 3.
C'est même une très mauvaise idée de faire le rendu de tout le monde.
Sur une map2d c'est extrêmement simple de faire une règle de trois (ok, c'est un peu plus :) ) pour savoir quelle partie afficher. Ne t'en prive pas surtout si tu veux faire des maps infinies après.
De la même façons, il n'est pas obligatoirement nécessaire de mettre à jour toutes les entités du jeu. Si un garde fait les cent pas pour garder une porte, ça ne sert à rien de mettre à jour sa position si il est à deux écrans du joueur.
Matthieu Gautier|irc:starmad
[^] # Re: Map
Posté par rewind (Mastodon) . Évalué à 2.
Oui, je vais mettre ça en place rapidement.
Là, ça me paraît moins simple de prime abord. Notamment parce que ça veut dire que tous les systèmes qui font des mises à jour d'entités doivent avoir accès à la position de l'entité. Il faut que j'y réfléchisse pour voir comment mettre en œuvre ça de manière à peu près propre.
[^] # Re: Map
Posté par GaMa (site web personnel) . Évalué à 3.
J'ai pas dis que ça serait simple :) Mais si tu dois mettre à jour la position de tous les chats/lapin/vache de la map à chaque frame, c'est ton moteur de jeu qui va pas trouver ça simple :)
Hum… Ça va plus loin que ça, si tu parcours toutes tes entités autant continuer à faire un "pos+=dt*v;" ça coûtera moins cher que de faire des calculs de distance avec le joueur. Ce qu'il faut c'est un moyen de les "exclure" du système quand elles sont trop loin (et plus dur, les ré-inclure quand on se rapproche)
Matthieu Gautier|irc:starmad
[^] # Re: Map
Posté par rewind (Mastodon) . Évalué à 5.
Oui, ça j'ai bien compris la problématique ;) Et je comprends le principe de la solution et je partage entièrement l'analyse. Yapluka implémenter !
Calculer la distance avec le joueur peut se faire assez simplement, avec la Distance de Manhattan, norme 1 pour les matheux, ou avec la norme infinie. Une autre solution, c'est de partitionner l'espace et de ne se concentrer que sur la portion actuelle, genre avec un Quadtree.
[^] # Re: Map
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu fais plein d'io disque pendant le jeu, tu risques d'avoir des mauvaises surprises comme des latences aléatoires.
"La première sécurité est la liberté"
[^] # Re: Map
Posté par rewind (Mastodon) . Évalué à 2.
Ce n'est pas les I/O du disque, la carte est entièrement en mémoire. C'est plutôt que je m'y prend comme un bourrin pour afficher la carte entière à chaque fois.
# Scénario
Posté par Naha (site web personnel) . Évalué à 3.
J'imagine que tu as une idée sur la question, mais à la lecture du scénario on se demande ce qui fait penser à Kalista que le roi voudra l'aider, surtout si elle se présente comme la vilaine sorcière qu'elle est (était). Même chose par la suite avec l'académie de magie (on comprend par contre pourquoi la doyenne de l'académie accepte de l'aider).
Autre question, qu'est-ce qui explique le fait qu'elle retrouve ses pouvoirs petit à petit avant de trouver la source de puissance ? Est-ce qu'il y aura une autre quête plus tôt dans le jeu à ce sujet (avec un mini-source de puissance ou autre) ?
[^] # Re: Scénario
Posté par rewind (Mastodon) . Évalué à 3.
Dans l'idée que j'avais, elle ne dit pas qu'elle est une ancienne puissante sorcière (elle va sans doute se ridiculiser au début sur ce sujet, ce qui va la refroidir), donc en fait, elle dit qu'elle cherche à se perfectionner en magie (ce qui est plausible), elle ment éhontément pour arriver à ses fins.
Pour l'Académie de Magie, idem, elle ne dit pas directement qu'elle veut récupérer son pouvoir, elle ruse pour savoir. Mais la doyenne la reconnaît et donc, accepte de «l'aider» sans lui dire.
Elle repart de zéro mais apprend quelques sorts, comme n'importe qui pourrait le faire (en lisant des parchemins de sort). Bon, évidemment, ça se trouve pas sous le sabot d'un cheval un parchemin, donc elle va les trouver petit à petit. La Source de Puissance est unique !
[^] # Re: Scénario
Posté par Naha (site web personnel) . Évalué à 2.
Ah oui pour les parchemins j'avais raté ça dans ton document. Le « comme n'importe qui pourrait le faire » est peut-être une précision intéressante à mettre dans le guide, ça positionne ton univers dans la catégorie « magie en tant que compétence » (par opposition aux univers où la capacité magique est un don). Enfin c'est du détail tout ça.
[^] # Re: Scénario
Posté par rewind (Mastodon) . Évalué à 5.
Oui, c'est d'ailleurs à ça que sert l'Académie de Magie !
Tous les détails comptent.
[^] # Re: Scénario
Posté par Gabbro . Évalué à 3.
Ce qui me gène dans le scenario, c'est qu'on pourrait remplacer "sorcière" par "fée clochette" sans changer grand chose. Les "beurk" peut-être…
Si je contrôle une sorcière, je veux empoisonner l'eau du puits, négocier avec les esprits et les démons, pas aider des villageois !
Pis franchement, moi j'aide le nécroment contre quelques services !
Sur l'univers justement, tu vois ça comment ? Merveilleux nordiques avec trolls, elfes et gobelins ? Médiéval avec korrigan et chevalier ? Antique avec muses et mânes ? Autre ?
Sinon, un détail : Tokiann est la dernière héritière ou la doyenne seulement ? Le paragraphe à son sujet semble se contredire.
En tout cas, ça c'est de la bible scénaristique !
[^] # Re: Scénario
Posté par rewind (Mastodon) . Évalué à 3.
Justement, aider les villageois, ça va être un passage obligé au début et ça va être déplaisant pour elle (d'où les beurk). D'ailleurs, ça va aussi se voir dans les contacts avec les animaux, dans le sens où les animaux présumés méchants ne vont pas l'attaquer tandis que les animaux présumés sympas vont l'attaquer systématiquement. Donc, très vite, on va voir que ce n'est pas une héroïne comme les autres.
Oui, oui, ça va être ça, mais ça doit rester aussi un peu humoristique. Du coup, ça va foirer souvent.
En fait, ça dépend. Tu as le choix entre l'aider mais derrière, tu n'auras pas l'information que tu cherches, ou ne pas l'aider (ce n'est qu'un obstacle sur la route). Et puis potentiellement, le nécroment, il est plus fort que toi, donc tu vas plutôt chercher à l'éliminer après lui avoir soutiré toutes les informations (et un petit parchemin magique), ça fera un concurrent de moins. Elle est méchante mais elle est égocentrique aussi !
Plutôt ultra caricatural mais détourné pour que ce soit drôle. Genre le dragon à la fin (parce qu'à la fin il y a toujours un dragon, non ?), il est juste blasé d'être là, il est énervé qu'on le dérange. Genre la princesse Mikith, elle est complètement naïve et elle plane à 10000m dans sa tête. J'hésite à mettre des elfes et des nains parce qu'en vue de haut, ça ne va pas rendre des masses.
Les deux ! C'est la doyenne de l'Académie de Magie mais aussi la dernière héritière de la Guilde des Mages, c'est une sale cumularde !
C'est la trame grossière, il manque encore pas mal de détails (d'où tes questions et d'autres avant). Il manque encore pas mal de quêtes annexes qui vont colorer encore l'univers (et où il y a moyen de pratiquer la caricature à outrance).
[^] # Re: Scénario
Posté par Gabbro . Évalué à 1.
Je cerne nettement mieux, merci.
Quand on est le dernier, on est forcement le plus vieux.
Ou un demi-dieux, ou une sorcière, au choix. Je n'ai pas d'autre exemple qui le viennent spontanément.
Je teste dès que j'ai accès à un PC avec CMake. ;)
[^] # Re: Scénario
Posté par reynum (site web personnel) . Évalué à 3.
Et le plus jeune aussi du coup !
Un gateau ?
The cake is a lie !! The cake is a lie !!kentoc'h mervel eget bezan saotred
[^] # Re: Scénario
Posté par rewind (Mastodon) . Évalué à 2.
C'est la dernière en date, pas l'ultime. Qu'elle soit vieille, ça lui permet de passer pour inoffensive, et ça permet qu'elle ne se batte pas contre Kalista.
Oui, le grand boss de fin méchant, mais là du coup, ça va pas marcher ;)
# Fichiers sources des sprites
Posté par Naha (site web personnel) . Évalué à 1.
Autre question, comptes-tu distribuer les fichiers source de tes sprites ? J'y aurais bien jeté un œil mais il n'y a que les PNG dans le dépôt.
[^] # Re: Fichiers sources des sprites
Posté par rewind (Mastodon) . Évalué à 3.
Oui, évidemment. C'est juste un oubli, les SVG seront dans le prochain push.
[^] # Re: Fichiers sources des sprites
Posté par Naha (site web personnel) . Évalué à 1.
Dis je vois que tu commentes sur DLFP, t'as pas reçu mon mail d'hier soir avec mes sprites de sorcière ?
[^] # Re: Fichiers sources des sprites
Posté par rewind (Mastodon) . Évalué à 2.
Oui, je n'ai pu regarder mes mails sur cette adresse hier. Et du coup, je t'ai répondu !
# Typo dans la dépêche
Posté par djano . Évalué à 4.
indispenables => indispensables
[^] # Re: Typo dans la dépêche
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Roadmap
Posté par GaMa (site web personnel) . Évalué à 2.
Il manque le nécessaire dans ta roadmap :)
Lister les éléments c'est bien, mais tu les implémentes quand ?
Je sais c'est chiant à faire mais justement c'est le but :)
Il faut que tu divises ton développement en N étapes et que tu places tes features dans les N cases.
Et tu priorises les taches en fonction des dépendances (techniques et fonctionnelles)
C'est en ça que c'est ta bible : à chaque moment, tu sais quoi faire, pourquoi et comment.
Matthieu Gautier|irc:starmad
[^] # Re: Roadmap
Posté par rewind (Mastodon) . Évalué à 2.
Je préfère lister tous les éléments avant de faire les étapes. J'avais commencé à faire les étapes mais en fait, j'avais oublié des éléments, et du coup, j'étais obligé de modifier les étapes. Conclusion : je liste d'abord les éléments (je pense qu'il m'en manque quelques unes) et ensuite, je fais les étapes.
# expérience
Posté par jymistriel . Évalué à 2.
Je ne saisis pas ce que tu proposes via Akagoria.
Est-ce juste une excuse pour appliquer le système à entités ou c'est vraiment censé aider à concevoir un jeu vidéo ?
Dans ce dernier cas il semble manquer une étape vitale, que j'ai peut-être loupé dans tes deux premier épisodes mais je ne me souviens pas avoir lue.
Je m'excuse de me manifester si tardivement d'ailleurs et j'espère que tu vas saisir où je veux en venir.
Avant de citer les quatre étapes de S. Lambert, peut-être faudrait-il savoir ce que tu veux offrir au joueur. C'est ce dernier le plus important, alors que tu justifies ton concept de jeu dans l'épisode 2 par trois raisons qui sont grandement rapportées à toi.
Tu es tout à fait en droit d'aimer et préférer le RPG - bien que ce choix de design ne soit pas non plus justifié de ce fait - cependant ton projet ne semble pas avoir d'intérêt qui le distinguerait d'un autre.
Ce n'est pas ton cas, mais évite à ton projet d'obtenir une telle image. Parce que professionnellement parlant il ne semble pas sérieux, et perd donc en crédibilité.
Dans la bible que tu as écrite d'après conseil - je salue au passage Julien Jorge pour sa participation à ta série, qui mérite qu'on s'attarde dessus pour les réflexions qu'on y apporte justement - ça se sent encore plus.
Dans les généralités je ne relève que des mots-clés pour moteur de recherche. Tu attaques le scénario direct après !
On ne peut même pas parler d'Argument Clé de Vente puisqu'il n'y a rien qui indique que l'utilisateur va vivre une certaine expérience.
Je ne te demande pas de devenir du jour au lendemain un game designer pour le bien de cette série, mais il faudrait peut-être aussi parler de l'importance étymologique du nom de ce "métier".
Qu'est-ce que c'est que ce mot là ? "design". On le retrouve aussi dans le domaine du textile, de l'automobile et j'en passe.
Qu'apporte t-il donc dans le cadre du jeu vidéo ? En tout cas je peux te dire qu'un bon game designer ne se lance pas dans un projet comme tu le fais, même pour une commande.
La réponse ? Elle est dans le titre.
Le design c'est comment tu vas la mettre en forme, la servir. Et du coup c'est là qu'on se rend compte de l'importance d'une équipe, d'une part pour aider le game designer à prendre du recul sur sa conception, mais aussi pour avoir des experts qui pourront mettre en place les différents éléments graphiques et techniques qui auront été élus. Ces derniers ne sont donc pas choisis au hasard, tous servent l'expérience.
D'ailleurs ça me fait penser que c'est probablement pour cela que tu as perçu Ned et les maki comme étant "complètement ficelé". Parce que l'expérience a déjà été triturée.
Alors certes tu n'es pas game designer, me diras-tu. Or il va falloir essayer d'en être un, ou d'en trouver dans le cadre de cette série.
Deux défis se proposent à toi : jeter ton projet (c'est connu, les GD suppriment leurs "dix premiers projets" ') ou, plus ardu, conserver le genre et tes idées (y'en a des sympathiques je trouve) tout en y accolant une expérience qui les justifie - du moins le genre.
Voilà, j'espère avoir été clair. Sinon je serai ravi de continuer à en discuter, surtout si quelqu'un n'est pas d'accord, surtout si j'avais tort. =)
Mais surtout je te conseille L'Art du game design, de Jesse Schell, enfin traduit.
À mon sens ce livre est au game design ce que La dramaturgie de Lavandier est au scénario.
[^] # Re: expérience
Posté par rewind (Mastodon) . Évalué à 3. Dernière modification le 18 octobre 2013 à 12:06.
J'ai raisonné de la manière suivante : 1 j'ai envie de faire un jeu, 2 les systèmes à entités, ça a l'air rigolo pour faire des jeux, 3 et si j'utilisais ça pour faire un jeu ? Rien de plus.
Non, mais je ne compte pas en vivre de ce projet. J'ai un métier qui me satisfait complètement. Je fais ce projet pour m'amuser et en même temps, je partage cette expérience ici (et apparemment, ça a l'air de plaire aux usagers de linuxfr). Effectivement, mon jeu n'est pas révolutionnaire, et il n'a pas l'ambition de l'être, ni dans son thème, ni dans sa réalisation, ni dans rien en fait. Oui, les trois raisons se rapportent à moi, parce que je fais ce jeu pour moi avant tout. Si d'autres y jouent, très bien, sinon, c'est pas bien grave, ça ne va pas m'empêcher de dormir. C'est juste un passe-temps, ça n'a pas vocation à devenir autre chose, notamment un projet professionnel. C'est peut-être de là que vient ton incompréhension.
Ça tombe bien, je ne veux pas le vendre. Donc, pas besoin d'argument de vente. J'essaie d'avoir une organisation efficace (parce que le temps est une denrée rare donc autant ne pas le gâcher) et donc je prend tous les conseils qui me sont donnés par ceux qui ont déjà fait des jeux (et c'est bien à ça que sert cette série d'article, partager l'expérience) et j'essaie de les appliquer. Si je le fais mal, et bien on me le fera remarquer et j'essaierai de corriger.
Je n'ai jamais prétendu être game designer et je ne compte pas le devenir.
Pourquoi ?
La première solution est évidemment complètement exclu. Et je ne comprend pas bien la deuxième.
Je me l'achèterai peut-être, on verra, mais ça sera plus pour ma culture que pour l'appliquer dans le cadre de ce jeu.
[^] # Re: expérience
Posté par jymistriel . Évalué à 1.
Que tu ne comptais pas le vendre ou changer de métier, ça je l'avais déjà deviné.
Le problème est que, sans traiter l'expérience, tu risques de mettre tes lecteurs désireux de concevoir un jeu sur la mauvaise voie.
Quelqu'un de mal avisé se dira après lecture qu'en fait oui, on peut concevoir comme ça, pour le trip - ce qui rejoins les développeurs qui se dispensent de graphistes ou leurs imposent leur projet. Pour l'entraînement d'accord.
Si tu viens à en parler dans ta série, déjà ça rendra ton projet moins ambigu mais en plus le point vital et indispensable de ce qu'est un jeu sera présent. Sans ça ta série est lacunaire, du moins elle part d'une motivation qui peut induire en erreur les gens.
C'est comme l'ACV. Elle découle en majeure partie de l'expérience que l'on compte offrir.
C'est le genre de choses que l'on trouve dans la bible d'un projet.
Les professionnels disent que finalement c'est un épais document que seul son auteur lit (surtout relis) vraiment, mais ça reste une étape essentielle.
Julien Jorge t'a poussé subtilement (même si ce n'est pas voulu) à en rédiger un en te parlant de l'inconvénient qu'il a vécu sans, et ce que tu en fais pour le moment c'est y déposer tout ton scénario et tes personnages, ton univers.
Il est bien question de techno à la fin, mais je ne vois pas vraiment de mécaniques.
C'est donc bien TON jeu vidéo que tu conçois. Et la démarche est intéressante vraiment, mais il y a des choses vraiment importantes à poser pour compléter ta série. =)
Donc si tu lis ou acquiers ce livre, ne l'applique pas forcément à ton projet, mais partage ici ce que tu appris, ce que tu trouves intéressant. Probablement que tu regarderas ton projet d'un autre œil.
J'ai souvent du mal à m'exprimer et je pars dans pas mal de longueurs, je tiens dons à m'excuser si le ton peut parfois paraître trop accusateur.
[^] # Re: expérience
Posté par rewind (Mastodon) . Évalué à 2.
Je pense au contraire que ça ne pose aucun problème. Tout le monde fait la différence entre un jeu développé tout seul, en amateur, et un jeu vidéo à destinée commerciale, développé par une équipe de manière professionnel. C'est un peu comme si tu disais à un gars qui fait un soft dans son coin en amateur qu'en fait, il s'y prend mal parce que les pros en entreprises ne font pas comme ça. Là, ça s'applique à un jeu vidéo mais peu importe, le principe ne tient pas. Ça ne peut pas se comparer. Je pense que je ne m'y prend pas si mal que ça pour un premier jeu, j'écoute les conseils et je les applique à mon échelle.
Ce document n'est pas définitif, je travaille encore dessus. Donc qu'il manque des choses, c'est plutôt normal. Ça va se résoudre petit à petit.
Justement, j'attends les commentaires pour compléter ce qu'il y a à faire. Après, ça prend du temps et je vais lentement. Ce qui a un avantage, c'est que je peux corriger assez tôt dans le processus.
Pas de problème ;) J'avais surtout l'impression qu'on ne se comprenait pas bien sur les finalités de ce projet.
[^] # Re: expérience
Posté par jymistriel . Évalué à 3.
On s'éparpille probablement en pensant à la destinée commerciale, qui n'est pas nécessaire au travail pro d'une seule personne sur un concept de jeu.
Si tu ne voulais que faire un jeu quelconque du moment que ça te permet de combler ton envie de faire un jeu et de le faire grâce au système à entités, tu ne chercherais pas à (je te cite) "changer des habitudes" de jeu.
Le pire c'est que tu as déjà une expérience à proposer, mais tu ne la mets pas en avant. On ne la retrouve pas dans tes "généralités", là où elle devrait être.
Peut-être parce que tu n'es pas certain de ce que ça va donner.
Certainement parce que c'est du "déjà joué". Il manque un plus.
En lisant donc pour la première fois ce que tu considères comme étant un "thème" j'ai été agréablement surpris, mais me suis vite rappelé que ça avait déjà été proposé : incarner un "méchant".
La réelle expérience ça pourrait « être dans la peau de quelqu'un qui veut retrouver les pouvoirs qu'il a perdu ».
Le premier problème c'est que ça ressemblera bien vite à l'atroce levelling qu'on connaît tant dans les mmorpg : on progresse pour débloquer de nouveaux sorts, qu'il faudra ensuite arranger à sa guise, utiliser intelligemment pour espérer évoluer dans les strates de difficulté ultime. Bref, ça peut faire fuir, voire attirer un public que tu ne vises pas du tout.
Le second c'est comment faire en sorte que le joueur se sente vraiment dans la peau de quelqu'un qui avait des pouvoirs costauds et de ce fait naisse vraiment en lui le désir de les retrouver.
Donc il faudrait peut-être que tu évites tout ce qui pourrait amener le joueur à se sentir passif.
Proposer au joueur de vivre brièvement ces grands pouvoirs avant leur perte en guise d'intro pourrait aussi pousser le joueur à les convoiter ardemment tout au long de l'aventure.
Troisièmement ça sonne plus comme une histoire à lire que comme un jeu où l'on va être surpris par la chute scénaristique.
Un joueur qui lit ton pitch aura probablement envie d'être un méchant.
Pourtant d'office on se retrouve à en faire l'opposé (aider des villageois), ça risque de déboussoler, au pire frustrer d'emblée. Qui plus est le joueur y est contraint pour progresser.
Ensuite les autres personnages lui indiquent presque gentiment (c'est ce qui ressort de tes grandes lignes de scénario) une source de pouvoir à emmagasiner. Y'a pas un moment où la vieille se dit que y'a anguille sous roche ?
Et au final le protagoniste (et le joueur) se retrouve berné et… fin ?!
L'histoire est intéressante, mais beaucoup de joueurs risquent d'être définitivement déçus par l'expérience qui n'a pas été celle qu'ils attendaient.
Pourquoi ne pas amener ça plutôt dans le jeu ? Et proposer quelque-chose de différent à faire ensuite ?
Tu peux aussi te demander ce qu'il se passerait si la sorcière retrouvait ses pouvoirs normalement. Ne ferait-elle pas alors ce qu'attend aussi le joueur : les utiliser à sa guise - se venger, passer son temps (de jeu) à torturer des innocents de façons diverses et variées =D
Bref.
Voir des démarches de conception différentes me laisse souvent perplexe, donc je suis rassuré d'apprendre - au bout du troisième épisode, la honte - que c'est vraiment à visée technique, "passe-temps personnel" et que ça ne se veut pas devenir une école en game design. C'est vraiment plus un journal de bord et ta progression risque d'être très intéressante à suivre.
À ce sujet, tu as déjà tous tes épisodes de prévu ou tu carbures davantage au feedback des linuxfriens ?
(encore désolé pour la longueur)
[^] # Re: expérience
Posté par rewind (Mastodon) . Évalué à 3.
C'est beaucoup dire. Il faut pondérer tout ça, ça n'a pas le même poids.
C'est parce que j'ai pas encore pushé. Je me suis rendu compte via la discussion au dessus qu'il n'y avait pas de description globale, ou plutôt qu'elle était incomplète. Du coup, je l'ai complété, exactement de la manière dont tu dis.
C'est en ça que ce n'est pas original. Jouer un méchant, j'ai fait ça dans Dungeon Keeper il y a 15 ans, donc non ce n'est pas nouveau. Dans les RPG, c'est plus rare. Maintenant, je n'en fais pas un truc vraiment différenciant par rapport au reste. Disons que ça donne un peu de sel et que ça permet d'imaginer d'autres choses que ce qu'on voit habituellement. Mais au final, ça va sans doute être très classique.
C'est pas un peu la mécanique de base de tout RPG ? Avec plus ou moins d'insistance mais globalement, dans tout RPG, tu as un système de levelling où tu progresses. Je ne dis pas que c'est le centre du jeu, et ça ne l'est pas d'ailleurs.
Oui ! Je vais faire une cinématique en 3D de 15 minutes pour décrire ça ! Non, je rigole :P Plus sérieusement, je ne me fixe pas ce genre d'objectif qui me semble trop haut. Faire un jeu jouable et plaisant, ça sera déjà bien. Et pour cette partie, quelques monologues en début de jeu devraient faire l'affaire dans un premier temps.
C'est plutôt normal. C'est un scénario. Et je pense que ça va transparaître dans le jeu, il y a une certaine linéarité. Mais je veux aussi éviter le tube scénaristique (façon FF13). Si je peux faire un truc à la FF12 (tu es assez libre de te balader mais il y a un gros fil conducteur), ça m'ira. Mon fil conducteur, c'est qu'elle veut retrouver ses pouvoirs.
Bon, ok, je peux sans doute changer cette partie trop gnangnan. Mais après, ça sert aussi à mettre l'ambiance (l'héroïne montre qu'elle déteste ça). Au départ, elle est vulnérable donc elle n'a pas trop le choix : si elle fait de la merde, elle va se faire attraper.
Bah oui. Déjà là, je vais devoir écrire pas mal de lignes de dialogues pour ce que j'ai prévu. Donc, pour l'instant, ça ira comme ça.
Parce que sinon, qu'est-ce que je vais faire pour la version 2.0 ? :P Non mais sérieusement, je veux rester dans le simple, donc bon.
Voilà, c'est ça. C'est comme un blog sauf que c'est au milieu de tout le reste de linuxfr.
Tous non. Quelques uns oui. J'ai déjà quasiment les deux suivants qui sont bien délimités. Je me dis qu'un épisode toutes les deux semaines, c'est un bon rythme. Ensuite, j'ai des idées et des liens à proposer pour des épisodes plus lointain. Et après, je prend en compte l'avis des linuxfriens, évidemment, sinon ça ne servirait à rien d'écrire ici. Le tien m'intéresse parce qu'il semble être très critique (mais je le prends bien hein).
# Retour de tests
Posté par Gabbro . Évalué à 1.
Bonjour, j'ai téléchargé et essayé de compiler.
Ça n'a pas marché. Pour box2D et libes, pas de problèmes. Pour libtmx, on me demande d'installer tinyxml2. Fait via le git du projet, mais n'est pas reconnu.
Quatre dépendances dont la plupart ne sont pas dans les grandes distributions. Tu vas t'amuser lors de l'empaquetage.
(Note : Je ne sais pas pourquoi la bibliothèque s'appelle tinyxml2 alors qu'il existe déjà tinyxml en version 2.6. Je m'étais planté dans un premier temps.)
[^] # Re: Retour de tests
Posté par rewind (Mastodon) . Évalué à 2.
D'après ce que je vois, pkg-config n'a pas réussi à trouver le .pc de tinyxml2. Je pense que tu as dû utiliser autre chose que CMake pour contruire et installer tinyxml2, parce qu'il y a bien un .pc dans les sources.
M'en parle pas :D Mais de manière générale, je trouve qu'il y a assez peu de jeu dans les distributions. Dans Debian, par exemple, il n'y a aucun paquet qui dépendait de SFML 1.6 !! Et je ne parle pas de Box2D qui est packagé comme un goret. Donc, je me dis qu'il faudra que je trouve un moyen de fournir un binaire.
[^] # Re: Retour de tests
Posté par Gabbro . Évalué à 1.
Pourtant si. J'ai résolu le problème : j'ai déplacé le .pc dont tu parles depuis /usr/local/lib64/pkgconfig vers /usr/lib64/pkgconfig. Et maintenant ça marche, mais il me semble que ce genre d'opération n'est pas très très propre.
La suite : avec gcc 4.7, j'ai compilé libtmx (cmake, make…). Résultat:
Résolu en commentant les lignes :
vers
ce qui rentre encore dans le pas très propre. :)
Et pour finir :
Là, j'ai pas compris. Le fichier TMX.cc compile bien, donc trouve TMX.h, mais pas tmx_render.cc.
Je n'aurais pas accès à mon PC dans la semaine, donc je verrais ça vendredi prochain.
Voilà voilà.
[^] # Re: Retour de tests
Posté par rewind (Mastodon) . Évalué à 3.
Dans ce cas, il me semble que c'est pkg-config qui fait mal son boulot. Dans ma manpage de pkg-config, tu as une liste des répertoires qui sont visités à la recherche de .pc.
Je pense que la libstdc++ qui est avec gcc ne devait pas être tout à fait complète. Je crois que je vais mettre une dépendance gcc >= 4.8. Le ifdef marche avec gcc 4.6 cependant.
Celui-là, on me l'a signalé par ailleurs. Je vais regarder ça.
[^] # Re: Retour de tests
Posté par Gabbro . Évalué à 1.
Arf… Confirmé.
Bonne nuit.
(Note : pensez à rapporter le truc aux mainteneurs de ma distribution).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.