rewind a écrit 3416 commentaires

J'ai essayé mais en fait, ça ne résout rien, parce que ça vient de ce qui est déjà compilé par Mingw-w64, donc il faudrait tout recompiler Ming-w64 et vérifier que ça fonctionne. Parce que je pense que le bug est corrigé dans le trunk.

Je confirme que c'est assez naturel. Par exemple, pour SFML qui n'est pas dans le dépôt, j'ai décompressé les sources de SFML-2.1, j'ai installé les dépendances nécessaires à SFML :

crossroad install freetype-devel
crossroad install glew-devel
crossroad install libjpeg-devel
crossroad install openal-soft
crossroad install libsndfile-devel

Et ensuite, j'ai essayé de compiler. Bon, j'ai eu le bug cité ci-dessus mais je suis sûr que sinon, ça marche !

Est-ce que ce ne serait pas lié à ce bug aussi ?

T'utilises quelle version de MinGW-w64?

La 3.0.0 donc plutôt récente.

J'ai testé un peu et j'ai trouvé ce que je pense être un bug. Le répertoire .cache/crossroad/prefix n'est pas créé et à un moment, ça pose problème, ça finit en exception.

Sinon, pour le reste, j'ai installé ming-w64 sur ma Debian (unstable) et j'ai pu compilé quelques trucs, sans souci. J'ai installé des paquets depuis les dépôts Fedora, sans problème. Mais à un moment, il y a qqch qui a dû mal se passer et je n'arrive plus à compiler, je me retrouve avec une erreur :

/usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/lib/crt2.o:
dans la fonction « __tmainCRTStartup »:


/tmp/buildd/mingw-w64-3.0.0/build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/../../mingw-w64-crt/crt/crtexe.c:285:
référence indéfinie vers « _set_invalid_parameter_handler »

Et même les trucs que j'avais réussi à compiler, ça ne marche plus. Je ne comprends rien. Si quelqu'un a eu le même genre de blague, ça m'intéresserait de comprendre.

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.

C'est beaucoup dire. Il faut pondérer tout ça, ça n'a pas le même poids.

On ne la retrouve pas dans tes "généralités", là où elle devrait être.

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.

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

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.

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.

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.

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.

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.

Troisièmement ça sonne plus comme une histoire à lire que comme un jeu où l'on va être surpris par la chute scénaristique.

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.

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 ?

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.

Et au final le protagoniste (et le joueur) se retrouve berné et… fin ?!

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.

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 ?

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.

C'est vraiment plus un journal de bord et ta progression risque d'être très intéressante à suivre.

Voilà, c'est ça. C'est comme un blog sauf que c'est au milieu de tout le reste de linuxfr.

À ce sujet, tu as déjà tous tes épisodes de prévu ou tu carbures davantage au feedback des linuxfriens ?

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

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.

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.

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.

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.

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

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.

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.

Pas de problème ;) J'avais surtout l'impression qu'on ne se comprenait pas bien sur les finalités de ce projet.

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.