rewind a écrit 3434 commentaires

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.

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.

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é.

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.

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.

Ç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 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".

Je n'ai jamais prétendu être game designer et je ne compte pas le devenir.

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.

Pourquoi ?

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.

La première solution est évidemment complètement exclu. Et je ne comprend pas bien la deuxième.

Mais surtout je te conseille L'Art du game design, de Jesse Schell, enfin traduit.

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.

Je me souviens d' un temps lointain ou linuxfr etait plus un bande de potache a rigoler tous ensemble, certe a troller mais gentiment, sans insulte.

Ensuite, Zenitram est arrivé…

Quand on est le dernier, on est forcement le plus vieux.

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.

Ou un demi-dieux, ou une sorcière, au choix. Je n'ai pas d'autre exemple qui le viennent spontanément.

Oui, le grand boss de fin méchant, mais là du coup, ça va pas marcher ;)

Oui, je n'ai pu regarder mes mails sur cette adresse hier. Et du coup, je t'ai répondu !

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…

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.

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 !

Oui, oui, ça va être ça, mais ça doit rester aussi un peu humoristique. Du coup, ça va foirer souvent.

Pis franchement, moi j'aide le nécroment contre quelques services !

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 !

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 ?

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.

Sinon, un détail : Tokiann est la dernière héritière ou la doyenne seulement ? Le paragraphe à son sujet semble se contredire.

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 !

En tout cas, ça c'est de la bible scénaristique !

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).

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 :)

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 !

ç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)

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.

Il manque le nécessaire dans ta roadmap :)

Lister les éléments c'est bien, mais tu les implémentes quand ?

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.

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.

Oui, je vais mettre ça en place rapidement.

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.

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.

Si le tmx change tout le temps

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.

C'est d'ailleurs ce que rewind fait avec son script es_make pour générer le système d'entités

Tout à fait ! Mais là, c'est pour éviter d'écrire du code redondant.

Peut être que le fork est la seule solution!

Oui, mais je suis un peu comme toi, pas trop le temps de maintenir un fork. Donc, pour l'instant, on garde ça :)

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.

Oui, évidemment. C'est juste un oubli, les SVG seront dans le prochain push.

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).

Oui, c'est d'ailleurs à ça que sert l'Académie de Magie !

Enfin c'est du détail tout ça.

Tous les détails comptent.

Pour l'éditeur, Tiled permets d'avoir des objets avec ces différentes formes.

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'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 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.

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).

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.

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) ?

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 !

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 ;)

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.

Donc tu affiche TOUTE ta carte à chaque fois ? c'est bien cela ?

Oui, 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.

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.

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.

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.

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.

Après c'est sur, ça fait un peu syndrome nih…

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é.

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.

Tu gères uniquement les objets là (ce qui est dans ObjectGroup dans TMX), c'est ça ?

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).

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.

C’est même répertorié dans les dictionnaires.

Non, ce n'est répertorié dans aucun dictionnaire.

En français, décryptage existe et signifie déchiffrer sans la clef. Cryptage, s'il existait, signifierait chiffrer sans la clef, ce qui n'a aucun sens.