Je crée mon jeu vidéo E14 : formats de données

Posté par . Édité par Nils Ratusznik, Benoît Sibaud et palm123. Modéré par NeoX. Licence CC by-sa
Tags :
34
2
jan.
2015
Jeu

«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 13, on a fait le bilan d'une année de développement. Un des constats était que le temps manquait, et au vu de la durée entre cet épisode-là et celui-ci, on peut dire que c'est toujours le cas. Dans ce nouvel épisode, on va discuter non seulement de formats de données, mais aussi de compilation croisée.

Sommaire

Formats de données

État des lieux

Actuellement, dans Akagoria, trois formats de données sont gérés directement ou indirectement : XML, Protobuf et YAML. Le terme format de sérialisation de données serait probablement plus approprié, puisque pour chacun de ces formats, il peut y avoir plusieurs dialectes.

Concrètement :

  • XML est utilisé pour la carte à travers le dialecte TMX, défini par Tiled. J'utilise ma propre bibliothèque, libtmx, pour avoir une vue de la carte indépendante du XML. La bibliothèque utilise elle-même TinyXML-2.
  • Protocol Buffers est utilisé par le format Nanim de devnewton. Dans les dernières versions, Nanimstudio peut exporter les données en JSON plutôt qu'en Protocol Buffers. Actuellement, j'utilise protobuf couplée avec l'analyseur lexical généré depuis nanim.proto.
  • YAML est utilisé pour les autres données du jeu, dans des formats que j'ai défini moi-même. J'utilise yaml-cpp qui est relativement simple à utiliser. Je l'avais déjà utilisé dans MapMaker avec satisfaction et je préfère ce format à XML car moins verbeux.

Et pour le futur, il y aura sans doute d'autres données à gérer. Par exemple, les dialogues. Dans Andor's Trail, ils sont gérés en JSON. Comme on peut le voir sur un exemple, le format gère aussi les récompenses et l'enchaînement des quêtes. On peut aussi penser au format des sauvegardes, au format de la configuration du joueur, etc.

Solution

La solution serait de n'avoir qu'un seul format de sérialisation, ce qui réduirait le nombre de bilbiothèques utilisées à une seule. Et on voit bien le problème :

  • soit il faut choisir XML puisque c'est celui utilisé par Tiled, ce qui veut dire qu'il faut transformer les autres données en XML. J'imagine déjà la tête de devnewton si je lui dis qu'il me faut un export XML dans NanimStudio.
  • soit il faut coder un convertisseur depuis les différents formats vers celui choisi, mettons YAML. Dans cette deuxième hypothèse, pour Nanim, on peut utiliser l'export JSON qui est à peu près un sous-ensemble de YAML.

La deuxième hypothèse a d'énormes avantages : pas de dépendance forte à un format externe, facilité de lecture puisque tout se ressemble. Mais elle a aussi quelques inconvénients notables : obligation de redéfinir des dialectes dans le format unique, obligation de réécrire des analyseurs sémantiques pour ces dialectes. Ces inconvénients sont une variante de la réinvention de roue.

Quelle réponse au problème global ?

En fait, il y a une question à laquelle nous n'avons pas répondu : pourquoi s'emmerder avec des formats de fichiers ? Pourquoi ne pas tout coder en dur ? Bonne question. La réponse usuelle est que des données à part permettent de faire des changements sans avoir à recompiler le jeu. En particulier, les données dans des fichiers permettent à des non-informaticiens de pouvoir les manipuler assez facilement. Bon, ça c'est quand on développe un jeu avec des non-informaticiens. Quand on développe un jeu à peu près tout seul, la non-recompilation est un avantage en soi.

Mais surtout quand on fait du libre, on aime les formats ouverts, mais aussi les formats standardisés, parce qu'ils permettent par la suite de créer des outils génériques pour les manipuler. Et ce qui manque le plus dans les jeux libres, ce sont ces formats standardisés. Au final, chacun refait la même chose dans son coin et on n'avance pas. On ne peut pas capitaliser sur un ensemble de formats communs. Et surtout, on n'a aucun outil pour les manipuler.

L'exemple de Tiled est parlant. Le format TMX est à peu près le seul format sur lequel tout le monde s'appuie dans pas mal de jeux libres. Certes il n'est pas parfait, mais son système de propriétés fait qu'on peut lui ajouter des fonctionnalités à peu de frais, tout en restant compatible avec le seul éditeur du format connu jusqu'à présent. Mais est-ce bien suffisant ? La communauté du libre a toujours trouvé les ressources pour pallier ce genre de problème mais dans le cas des jeux vidéos, elle reste assez inerte.

Les grands studios ne développent pas que des jeux, ils développent aussi beaucoup d'outils. Certains moteurs libres de jeux proposent également des éditeurs, mais le problème des formats est toujours posé. Choisir un moteur de jeu, c'est choisir les formats qui vont avec et donc se lier à une technologie en particulier. Ce que je dis sonne un peu comme un yakafokon, parce que standardiser des formats de ce genre relève du parcours du combattant et nécessite une expérience que je suis sans doute très loin d'avoir.

En attendant une solution globale, je peux au moins éliminer Protobuf et utiliser l'export JSON de NanimStudio.

Compilation croisée pour Windows

Après des premiers essais infructueux dûs à des bugs dans les outils de compilation, j'avais mis de côté cet aspect des choses, à savoir fournir un binaire pour Windows. Mais il y a eu des mises à jour, notamment de Ming, et j'ai retenté. J'utilise l'excellent crossroad qui a été présenté ici-même il y a quelques temps (et qui a changé un peu donc lisez la doc si vous l'utilisez).

Première chose à dire, il faut vraiment s'armer de patience quand on tente ce genre de compilation. Parce qu'on tombe sur des erreurs de compilation qu'on ne trouve pas ailleurs. Alors bon, des fois, c'est tellement cryptique que la seule solution, c'est petit patch en mode « la Rache ». Et dans d'autres cas, c'est tout à fait légitime. Par exemple, le compilateur a l'air plus strict sur les standards. Saviez-vous qu'il n'y avait pas les constantes genre M_PI dans <cmath> ? En fait, elles sont dans les spécifications Unix et du coup, quand on les utilise et qu'on veut compiler pour un système non-Unix, ça provoque une erreur de compilation parce que la constante n'existe pas.

Autre chose à prendre en compte, on compile beaucoup de choses. Parce que même s'il y a déjà des paquets disponibles (grâce à OpenSuse), il manque beaucoup de choses. Pour cet essai, j'ai dû recompiler SFML, Box2D, protobuf, tinyxml2 et yaml-cpp. Sans compter mes propres bibliothèques. Il faut faire attention à plein de choses, il faut compiler le strict minimum pour que ça se passe au mieux. Et surtout, on a plein d'avertissements sur des pages et des pages ! Bref, on serre les fesses à chaque commande.

Au final, on se retrouve avec un joli zip de 40 Mio qui contient tous les binaires et les fichiers de développement. Et… Kaboum ! Ça ne marche toujours pas. Bon ben, faute de temps, je retenterai une prochaine fois. Mais je suis assez content de crossroad. Il fait exactement ce qu'on attend de lui et il aide juste ce qu'il faut pour la compilation croisée.

D'ici à la prochaine fois

N'oubliez pas que le week-end du 23 au 25 janvier 2015 a lieu la Global Game Jam. C'est un exercice amusant, et il y a de plus en plus de sites partout en France, n'hésitez pas à y faire un tour. Personnellement, je serai à Besançon, avec mes étudiants qui organisent le site.

  • # formats de données?

    Posté par (page perso) . Évalué à 0.

    Il manque plein d'infos, seront t'elles traités aprés? Stockage sur le hdd, transfére pour les jeux en ligne (et delta), … image: png rasterization + zopfli, compression, minimification des xml, … format audio, meta données, …

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: formats de données?

      Posté par . Évalué à 1.

      Je ne comprends pas tes questions. Il s'agit juste de données qui sont lues au démarrage ou dynamiquement pour récupérer des informations. Et ce n'est pas un jeu en ligne, c'est juste un jeu solo.

  • # catégorie

    Posté par . Évalué à 1.

    Je pense qu'il y a erreur de catégorie

  • # Non a YAML !

    Posté par . Évalué à 1. Dernière modification le 03/01/15 à 08:56.

    YAML n'a aucun intérêt pour des données manipulées par un programme.

    YAML est un format de donnée excessivement complexe, affreux à implémenter, dont la définition n'est pas assez précise.

    JSON est un format très simple, dont la spec est limpide et tient en une demi page. Il est d'autant plus facile à implémenter (et bien mieux répandu que YAML).
    YAML étant un super set de JSON, je suis assez convaincu que la plupart des gens qui émettent du YAML émettent 90% de JSON (évidement, il y a 10% qui font foirer …).

    S'il vous plait, utilisez JSON.

    Si vous voulez un truc plus éditable par des humains (pour les fichiers de confs), utilisez toml.

    • [^] # Re: Non a YAML !

      Posté par (page perso) . Évalué à 2.

      Le JSON c'est juste relou a écrire

      Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

      • [^] # Re: Non a YAML !

        Posté par . Évalué à 0.

        C'est une question de "trade off" je dirai ; difficile en effet d'allier lecture/ecriture facile et permettre de gérer des cas complexes.

        • [^] # Re: Non a YAML !

          Posté par (page perso) . Évalué à 4.

          C'est une question de "trade off"

          → tradeoff = compromis :)

          Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Non a YAML !

        Posté par . Évalué à -1.

        Je répond en m'auto-citant (et c'est valable pour la plupart des autres commentaires aussi) :

        Si vous voulez un truc plus éditable par des humains (pour les fichiers de confs), utilisez toml.

        • [^] # Re: Non a YAML !

          Posté par . Évalué à 5.

          Tu parles sans doute de ça (mais ça va mieux avec un lien). Et ça ne me paraît pas plus lisible que du YAML. C'est une espèce de mix entre du JSON et de l'INI. Super ! Et puis ce n'est même pas packagé dans Debian, ça veut dire qu'il faut se farcir la compilation à la main. Bref, je vais garder mon baril de YAML pour l'instant.

    • [^] # Re: Non a YAML !

      Posté par . Évalué à 3.

      JSON est un format très simple, dont la spec est limpide et tient en une demi page.

      La RFC 7159 fait plus d’une demi-page, ou alors tu as des putains de grandes pages…

      • [^] # Re: Non a YAML !

        Posté par . Évalué à 0.

        Effectivement, la spec complète est un peu plus longue, car il y a beaucoup de bruit typique des RFC dedans.

        Je pensais a la grammaire quand j'ai dit ça et elle est, pour le coup, excessivement courte.

        • [^] # Re: Non a YAML !

          Posté par . Évalué à 1.

          Je pensais a la grammaire quand j'ai dit ça et elle est, pour le coup, excessivement courte.

          Elle est courte mais plus d’une demi-page : elle fait quand 4 pages (page 4-7)

    • [^] # Re: Non a YAML !

      Posté par (page perso) . Évalué à 7.

      La spec JSON ne prévoit pas de commentaire ni de retour à la ligne, ce sont deux point très bloquant pour des fichiers que l'utilisateur doit manipuler. JSON est juste bon pour l'échange d'information pas trop complexe entre machines.

      « 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

      • [^] # Re: Non a YAML !

        Posté par (page perso) . Évalué à 1.

        C'est mineur comme défauts.

        Je n'ai vu aucune implémentation qui foire si on mets des sauts de ligne et les commentaires peuvent être mis dans un champ "comments" (ce qui est très bien puisque cela permets facilement de conserver les commentaires quand on charge/modifie/sauvegarde un fichier).

        http://devnewton.bci.im

        • [^] # Re: Non a YAML !

          Posté par (page perso) . Évalué à 3.

          Je n'ai vu aucune implémentation qui foire si on mets des sauts de ligne

          Pourtant, je n'arrive pas à faire passer

          {
              "value": "plop",
              "desc": "uaiodufo sjfofjue oifjiof hdofhof sjfohssfohd fodhdso fhjsfhuosjhsdkjfhsdjkfh
              oweiruweoiruweour iow",
          }

          dans un parser (testé avec celui par défaut de Python). Et les retours à la ligne, c'est bien pour la lisibilité mais aussi le formatage (si c'est un message qui sera afficher dans le programme).

          es commentaires peuvent être mis dans un champ "comments"

          Ça ne marche que pour un sous ensemble des commentaires. Par exemple, si je veux commenter une ligne dans un fichier de conf (pour la garder pour plus tard ou pour faire des exemple pour les utilisateur), il faut s'amuser à échapper tous les ", c'est loin d'être pratique.

          ce qui est très bien puisque cela permets facilement de conserver les commentaires quand on charge/modifie/sauvegarde un fichier

          Ça marche en XML, par exemple, avec des vrais commentaires (même s'ils loin d'être pratique à utiliser), ça montre bien que c'est possible avec des formats/parser bien fait.

          « 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

          • [^] # Re: Non a YAML !

            Posté par (page perso) . Évalué à 1.

            dans un parser (testé avec celui par défaut de Python)

            Ça passe avec le JSON.parse de javascript, jackson en Java et Boost.PropertyTree en C++.

            Après si ça marche mal avec certains toylanguages…

            Ça marche en XML, par exemple, avec des vrais commentaires (même s'ils loin d'être pratique à utiliser), ça montre bien que c'est possible avec des formats/parser bien fait.

            Oui, mais je ne vois pas d'avantage significatif aux "vrais" commentaires.

            http://devnewton.bci.im

            • [^] # Re: Non a YAML !

              Posté par (page perso) . Évalué à 4.

              Oui, mais je ne vois pas d'avantage significatif aux "vrais" commentaires.

              Par exemple, si je veux commenter une ligne dans un fichier de conf (pour la garder pour plus tard ou pour faire des exemple pour les utilisateur)

              « 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

              • [^] # Re: Non a YAML !

                Posté par (page perso) . Évalué à 2. Dernière modification le 09/01/15 à 10:08.

                Il suffit de faire:

                    {
                    "doc" : {
                        "what": "this is a video conf",
                        "sample": {
                               "video": {
                                    "w": 640,
                                    "h": 480
                                }
                        }
                    },
                    "video": {
                       "w": 640,
                       "h": 480
                    }
                    }

                http://devnewton.bci.im

          • [^] # Re: Non a YAML !

            Posté par . Évalué à 2.

            Avec des triples quotes ça fonctionne correctement, ou alors je n'ai pas compris le problème.

            import json
            a={
                "value": "plop",
                "desc": """uaiodufo sjfofjue oifjiof hdofhof sjfohssfohd fodhdso fhjsfhuosjhsdkjfhsdjkfh
                oweiruweoiruweour iow""",
            }
            b=json.dumps(a)

            me renvoie bien

            {"desc": "uaiodufo sjfofjue oifjiof hdofhof sjfohssfohd fodhdso fhjsfhuosjhsdkjfhsdjkfh\n    oweiruweoiruweour iow", "value": "plop"}
            • [^] # Re: Non a YAML !

              Posté par (page perso) . Évalué à 2.

              Non, ça marche pas, parce que tu ne lis pas un fichier JSON avec un retour à la ligne.

              Soit /tmp/test.json

              {
                  "test": "plop",
                  "retest": "siqoufo ufsosdjkfh uiofjsdk fhsdjkfhhdsfksajfh sakfdhsakjfhhskfdd 
                  wioruowieru iowe"
              }
              import json
              >>> with open('/tmp/test.json') as f:
              ...     json.load(f)
              ... 
              Traceback (most recent call last):
                File "<stdin>", line 2, in <module>
                File "/usr/lib/python2.7/json/__init__.py", line 290, in load
                  **kw)
                File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
                  return _default_decoder.decode(s)
                File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
                  obj, end = self.raw_decode(s, idx=_w(s, 0).end())
                File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
                  obj, end = self.scan_once(s, idx)
              ValueError: Invalid control character at: line 3 column 79 (char 97)

              « 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

              • [^] # Re: Non a YAML !

                Posté par . Évalué à 1.

                Au temps pour moi, je n'avais pas vu le problème sous ce jour là. Effectivement cela nécessite de tripatouiller un peu le contenu du fichier avant. Même si c'est pas la mort, c'est pas idéal je le reconnais…

                • [^] # Re: Non a YAML !

                  Posté par . Évalué à 4.

                  Bon, je me réponds à moi même, car je n'ai pas assez lu la doc on dirait
                  Python doc

                  If strict is False (True is the default), then control characters will be allowed inside strings. Control characters in this context are those with character codes in the 0-31 range, including '\t' (tab), '\n', '\r' and '\0'.

                  Donc il suffit de faire

                  json.load(f,strict=False)

                  et ça marche comme il faut.

    • [^] # Re: Non a YAML !

      Posté par . Évalué à 3.

      YAML étant un super set de JSON, je suis assez convaincu que la plupart des gens qui émettent du YAML émettent 90% de JSON (évidement, il y a 10% qui font foirer …).

      Je ne crois pas. Parce qu'en YAML, on a plutôt l'habitude d'écrire des trucs comme ça :

      foo:
          bar: 1
          baz:
              - 'toto'
              - 'tata'
          qux: true

      Et ce simple morceau n'est pas du tout du JSON. Le morceau de JSON équivalent serait :

      {
          "foo": {
              "bar": 1,
              "baz": [ "toto", "tata" ],
              "qux": true
          }
      }
      • [^] # Re: Non a YAML !

        Posté par . Évalué à 5.

        Je pense qu'il faut comprendre que YAML n'apporte fonctionnellement rien par rapport a JSON dans ton exemple.

        Il est donc très mal choisie pour mettre en avant YAML

    • [^] # Re: Non a YAML !

      Posté par (page perso) . Évalué à 4.

      Je suis d'accord pour dire que YAML est un format horrible. Pour un travail précédent où j'ai écrit un outil qui convertissait des fichiers de localisation (et il se trouve que certains logiciels localisent avec un format basé sur YAML), j'ai écrit un parseur basé sur la spéc. C'était franchement l'un des pires formats avec lequel j'ai eu à travailler. Aucune cohérence, 20000 façons de faire la même chose sémantiquement, des règles/exceptions super tarabiscotées. Même pour un humain, puisqu'il y a plusieurs façons de faire les mêmes choses, je suis persuadé que quand on se met à travailler en groupe avec ce format, on se retrouve avec des problèmes de compréhension de syntaxe.

      Perso, je pense que XML reste un des meilleurs formats pour tout ce qui est automatisé (facile à parser par une machine, et facile à lire, donc débugguer par un humain en cas de problème); et pour tout ce qui est à éditer par un humain (fichiers de configuration pour un logiciel non-graphique par ex) ou pour des données vraiment simples et linéaires, de simples fichiers INI ou similaires vont parfaitement.
      Json, c'est bien pour le web, où on essaie souvent d'optimiser le moindre bit. Mais pour des fichiers qui restent principalement sur la même machine, je lui préfère de loin XML. C'est beaucoup plus lisible.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Non a YAML !

        Posté par (page perso) . Évalué à 4.

        de simples fichiers INI ou similaires vont parfaitement

        Je ne suis pas d'accord. Chacun a sa propre façon d’interpréter les fichiers INI dès qu'on a une structure un poil complexe comme une liste (et ça arrive très souvent dans les fichiers de configuration, par exemple, une liste d'IP à binder). Du coup, dès qu'on a un fichier INI, il faut chercher1 comment exprimer cette structure pour ce logiciel en particulier (ce qui n'est pas toujours simple si ce n'est pas écrit simplement).


        1. ou, plus souvent, se tromper, comprendre pourquoi le logiciel ne fait pas ce qu'on veut, comprendre que ça vient de la conf boiteuse et puis chercher comment l'exprimer correctement. 

        « 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

  • # Le plus gros manque ?

    Posté par (page perso) . Évalué à 7.

    Et ce qui manque le plus dans les jeux libres, ce sont ces formats standardisés

    J'aurai tendance à dire que non, c'est un problème très secondaire. Le jour où il y aura des tas de jeux libres de qualitay, et qu'on aura à gérer des tas de moteurs maisons avec leurs formats propres, et leurs différentes sous-versions etc…, alors le problème des standards se posera (d'ailleurs l'industrie du jeu y est confrontée — j'avais vu un article sur Gamasutra à propos de Collada y a quelques années par exemple).

    Je ne peux pas ouvrir mes fichiers .blend (de Blender donc) dans un autre modeleur 3D ; c'est dommage mais en pratique, je m'en tape parce qu'aucun autre modeleur libre ne lui arrive à la cheville. Je préfère avoir un seul logiciel libre/gratuit/multi-plateforme qui assure, plutôt que plusieurs interopérables mais qui font le tiers de ce que je veux.

    À côté de ça, ça plus de 10 ans qu'on peut facilement exporter les modèles 3D de Blender vers Ogre3D. Pourtant tous les jeux utilisant Ogre un tant soit peu aboutis sont propriétaires [*]. Pas parce que les libristes sont mauvais, mais parce que faire un bon jeu ça demande beaucoup de temps, qu'il y a peu de libristes graphistes, etc… De manière générale les créateurs de jeux libristes sont très peu nombreux, la comparaison avec les jeux propriétaires est donc forcément décevante.

    Ton jeu utilise 3 formats : et bien tant pis c'est pas grave ! Quand tu auras des milliers de joueurs tu pourras proposer à tes étudiants un projet consistant à régler ce problème (ils seront ravis de toucher à un programme utilisé par des tas de gens).

    Les formats standardisés ne vont pas t'apporter de graphiste libriste. A l'inverse un outil de création de jeu accessible à des non codeurs serait un vrai plus ; ces dernières années un certains nombre de très bons jeux indépendants utilisent des logiciels comme GameMaker. Mais :

    • qui va écrire un tel soft en libre (c'est sûrement beaucoup de travail aussi) ?
    • paradoxalement, un tel soft, gratuit et de qualité, serait sûrement utilisé avant tout pour faire des jeux proprios ! :)

    J'espère ne pas avoir l'air trop négatif, je pense juste que le problème est complexe, et la solution pas forcément technique ; l'organisation de Jam et le prosélytisme de la part de tes étudiants est peut-être plus efficace au final !

    Ah oui, félicitation pour ta série d'articles !

    [*] Je dis ça sans méchanceté aucune, j'ai moi-même pas mal d'embryons de jeux libres dans mes cartons, dont un utilisant Ogre.

    • [^] # Re: Le plus gros manque ?

      Posté par . Évalué à 2. Dernière modification le 03/01/15 à 13:20.

      Il y a déjà un beau moteur graphique dans le libre: http://springrts.com/ Les windowsiens a qui j'ai montré ce truc on été ébahi (mais l'extase est redescendu quand les fonctionnalités manquantes sont apparut (genre des IA)). C'est dommage qu'on ne parle jamais de ce projet sur linuxfr.

      PS: merci rewind pour tes articles super intéressant :)

      • [^] # Re: Le plus gros manque ?

        Posté par (page perso) . Évalué à 6.

        Il y a déjà un beau moteur graphique

        Ce n'est pas un moteur graphique, mais un moteur de jeu spécialisé dans les RTS.

        Et oui Spring fait parti des moteurs libres les plus aboutis ; mais pour appuyer mon 1er commentaire, au final la moitié des jeux l'utilisant (http://springrts.com/wiki/Games) ne sont pas libres (contraintes NC et/ou ND).

        Il ne permet donc pas de faire n'importe quel type de jeu, mais j'imagine qu'on doit pouvoir écrire son propre RTS sans toucher au code (ce qui est bien).

        C'est dommage qu'on ne parle jamais de ce projet sur linuxfr.

        Tu en sais sûrement plus que la plupart des linuxfriens sur ce projet, c'est donc peut-être à toi de faire le premier pas et d'écrire un journal ou une dépêche dessus ! :)

    • [^] # Re: Le plus gros manque ?

      Posté par . Évalué à 3.

      Le jour où il y aura des tas de jeux libres de qualitay,

      Je pense qu'on arrivera pas à ça sans avoir des formats standardisés. Pourquoi ? Parce que le libre ne se construit pas à grand coup de développements intensifs mais sur des briques de bases qu'on empile petit à petit. Et dans les fondations, il y a des standard. C'est une manière de distribuer la charge de travail sans que personne ne se concerte.

      ça plus de 10 ans qu'on peut facilement exporter les modèles 3D de Blender vers Ogre3D

      Quand il y a un bon éditeur avec des fonctions d'export, c'est parfait. C'est aussi le cas avec Tiled, même si tout le monde utilise le format de Tiled. Mais à terme, il se peut qu'il y ait un export vers un format plus générique et/ou plus commun.

      Quand tu auras des milliers de joueurs tu pourras proposer à tes étudiants un projet consistant à régler ce problème

      Hahahaha !

      Les formats standardisés ne vont pas t'apporter de graphiste libriste. A l'inverse un outil de création de jeu accessible à des non codeurs serait un vrai plus

      L'un ne va pas sans l'autre à mon avis.

      le problème est complexe, et la solution pas forcément technique

      Tu as parfaitement raison ! Dans ces cas là, une solution, c'est de faire des propositions, mais c'est aussi le risque de tomber dans le syndrome xkcd.

      • [^] # Re: Le plus gros manque ?

        Posté par (page perso) . Évalué à 3.

        Parce que le libre ne se construit pas à grand coup de développements intensifs mais sur des briques de bases qu'on empile petit à petit. Et dans les fondations, il y a des standard. C'est une manière de distribuer la charge de travail sans que personne ne se concerte.

        Pas d'accord. Ce n'est pas le libre qui est défini ainsi, mais plutôt le Principe_KISS cher à nos systèmes *nix.

        Et ce principe ne facilite pas, je pense, l'émergence de standard, car chaque brique est développée comme une brique indépendante et non comme faisant partie d'un tout. Du coup, si une brique veut utiliser YAML, une autre, JSON, une autre du binaire, etc… ben absolument rien ne les en empêches.

        Pour que des standards émergent, il est justement nécessaire d'avoir des concertations et de trouver un consensus.

      • [^] # Re: Le plus gros manque ?

        Posté par (page perso) . Évalué à 3.

        le libre ne se construit pas à grand coup de développements intensifs

        Hum, c'est une vision un peu idéalisée des choses je pense. Un certain nombre de logiciels star du libre en sont le contre-exemple :

        • Linux et ses milliers de contributeurs ; oui il implémente le standard POSIX, mais on ne peut pas dire qu'il ait vraiment pu utiliser des briques standards pour se faciliter le boulot.
        • Blender a été développé intensivement durant sa période propriétaire (200 ingénieurs à un moment si je me souviens bien), et il ne serait pas le logiciel libre qu'il est sans ça (il n'y a qu'à regarder la concurrence libre). Évidemment il utilise des libs existantes, certaines avec des standards (ex: jpg, mpeg, png…) et d'autres non (ex: bullet), mais il est très loin d'être un assemblage de petites briques qui géreraient les maillages 3D pour une, les squelettes pour une autre, la texturisation encore à côté etc… (à mon avis une telle approche serait vouée à l'échec).
        • Open/LibreOffice : là aussi développé à la base intensivement chez Sun. Les dépêches sur LinuxFr nous ont permis de voir qu'en pratique ils ont développé pas mal d'outils spécifiques (qui n'existaient pas en standalone) et se retrouve aujourd'hui à supprimer ces outils en faveur d'outils 'standards'. J'ajouterai que ODT a été standardisé longtemps après la création du logiciel, mais c'est sûrement une bonne chose, afin d'avoir une bonne idée des besoins et des problèmes rencontrés.
        • Firefox

        À côté de ça, les logiciels libres qui justement nécessiteraient peut-être d'un développement intensif (parce que les petites briques ne sont pas toujours une solution) mais qui n'en bénéficient malheureusement pas, sont en général à la traîne ("hey je suis un noob sous Linux et je cherche un équivalent gratuit à Photoshop/AfterEffects/Illustrator/SolidWorks…"). Pour le coup je pense que le financement participatif fait sûrement partie de la solution, puisque c'est naturel dans le libre de financer le développement avant plutôt qu'après, à coup de licences payantes.

        une solution, c'est de faire des propositions, mais c'est aussi le risque de tomber dans le syndrome xkcd.

        À mon sens, faire des propositions de standards n'est justement pas la chose à faire tout de suite ; ce qu'il faut faire c'est des bons jeux, avec des besoins variés, quitte à ce qu'il fasse des hacks chacun dans leur coin. Et ensuite on essaiera de rationaliser les besoins des uns et des autres afin de ne pas faire de standard bancal qui serait un boulet plus qu'autre chose.

        Les fichiers standardisés c'est fondamental pour sauver les données créées par les utilisateurs et garantir l'interopérabilité. Dans le cas des jeux, cela n'a pas vraiment de sens si on parle des utilisateurs finaux : tu ne vas pas importer ta sauvegarde de FrozenBobble dans Hedgewars. Et si on parle des développeurs, le problème se pose rarement ; parce que très peu de jeux, donc peu de chance qu'il y ait un projet suffisamment proche pour que lui prendre des assets.

        Je pense vraiment que akagoria est trop ambitieux pour quelqu'un qui ne peut évidemment pas bosser dessus à plein temps (mais la série d'articles n'en est pas moins excellente) [*] ; le fait de n'avoir pas à ce stade un prototype pour tester si les mécaniques fonctionne ou pas est bien plus inquiétant que d'avoir 3 parsers plutôt qu'un.

        PS: j'ai hâte de voir une rétrospective des jeux qu'auront pu faire tes étudiants.

        [*] j'ai du moi-même abaisser grandement les ambitions de mes jeux au cours des années, et je n'ai pourtant encore rien à montrer doit je puisse être fier…

        • [^] # Re: Le plus gros manque ?

          Posté par (page perso) . Évalué à 6.

          Linux et ses milliers de contributeurs ; oui il implémente le standard POSIX, mais on ne peut pas dire qu'il ait vraiment pu utiliser des briques standards pour se faciliter le boulot.

          Je ne suis pas d'accord, le fait qu'il soit compatible avec l'existant (dès le début, on pouvait utiliser des outils développés pour Minix) a permis d'avoir une base logicielle minimale qui a permis sont utilisation et l’engouement des contributeurs. Bien sûr, ça ne fait pas tout, et il ne suffit pas d'être compatible pour susciter l'engouement mais ça a une certaine influence.

          « 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

        • [^] # Re: Le plus gros manque ?

          Posté par . Évalué à 4.

          Hum, c'est une vision un peu idéalisée des choses je pense. Un certain nombre de logiciels star du libre en sont le contre-exemple :

          Tu te rends compte que tes exemples ne font qu'apporter de l'eau à mon moulin ? Linux, comme dit avant moi, n'est pas parti de rien, il s'est appuyé sur des briques déjà existantes à l'époque, notamment le userland GNU, et GCC. Blender et OpenOffice : beaux exemples de développements intensifs… non-libres. Et tu décris toi-même le processus en cours chez LibreOffice : ils utilisent un maximum des briques libres. C'est naturel, c'est la manière intrinsèque de fonctionner du libre. Quant à Firefox, il a commencé comme un navigateur basé sur une brique libre (Gecko) plutôt que par un développement from scratch.

          ce qu'il faut faire c'est des bons jeux, avec des besoins variés, quitte à ce qu'il fasse des hacks chacun dans leur coin.

          On ne fait pas des bons jeux avec des hacks dans le libre. Le libre a la particularité de ne pas fonctionner avec des logiciels jetables mais avec du durable et du réutilisable.

          tu ne vas pas importer ta sauvegarde de FrozenBobble dans Hedgewars

          Il ne s'agit pas de ça, il s'agit de partager des briques de base.

          parce que très peu de jeux, donc peu de chance qu'il y ait un projet suffisamment proche pour que lui prendre des assets.

          Je me suis peut-être mal exprimé mais il ne s'agit pas de partager des assets mais des formats. Si je reprends l'exemple des dialogues, on peut très bien avoir un format unique mais des dialogues différents pour chaque jeu. L'avantage du format unique est qu'il permet d'avoir des outils commun pour le manipuler.

          Je pense vraiment que akagoria est trop ambitieux pour quelqu'un qui ne peut évidemment pas bosser dessus à plein temps

          Sans doute ;)

          PS: j'ai hâte de voir une rétrospective des jeux qu'auront pu faire tes étudiants.

          Ils ont du mal, pas tant dans le code que dans l'organisation.

          • [^] # Re: Le plus gros manque ?

            Posté par (page perso) . Évalué à 3.

            Tu te rends compte que tes exemples ne font qu'apporter de l'eau à mon moulin ?

            Non et je vais ré-expliquer pourquoi.

            Linux, comme dit avant moi, n'est pas parti de rien, il s'est appuyé sur des briques déjà existantes à l'époque, notamment le userland GNU, et GCC

            Je n'ai pas prétendu que Linux était parti de rien. Évidemment qu'il utilise un langage/compilateur existant ; même si tu utilises C++ et SFML pour ton projet, je considère que tu l'as codé depuis 0, au contraire de si tu avais par exemple forké un jeu existant (après ça reste discutable). Ce que je dis c'est qu'il est issu d'un développement intensif, et pas d'un simple assemblage de briques existantes faisant une chose et une seule (scheduler, gestionnaire de mémoire, VFS…) ; si de telles briques avaient existé chez GNU, ça voudrait dire que Hurd était disponible.

            Blender et OpenOffice : beaux exemples de développements intensifs… non-libres

            Tout à fait mais que tu le veuilles ou non, ce sont maintenant des projets libres, et sans cette phase de développement non-libres, ils n'existeraient pas. Difficile de savoir si la communauté auraient été capable de faire aussi bien, et c'est pour ça que j'ai parlé des hypothétiques équivalent libres à Photoshop et cie, qui me font dire que non, on aurait pas aussi bien que Blender.

            Développer un logiciel proprio et le libérer ce n'est pas ma façon de faire, ni la tienne, mais ça reste une option qui a donné des résultats.

            Et tu décris toi-même le processus en cours chez LibreOffice : ils utilisent un maximum des briques libres.

            Oui maintenant ils ré-usinent le code (et c'est très bien), mais dans un premier temps il se sont foutu de faire des briques standards (parce que coder de telles briques était déjà suffisamment difficile comme ça), et s'en sont préoccupé largement après que OO est devenu une référence.

            Quant à Firefox, il a commencé comme un navigateur basé sur une brique libre (Gecko) plutôt que par un développement from scratch.

            Gecko est né des cendres de Netscape (avec donc une histoire un peu similaire a Blender/OpenOffice), et reste donc un logiciel développé de manière intensive par une grosse équipe, et pas un assemblage épars de briques standardisées.

            On ne fait pas des bons jeux avec des hacks dans le libre. Le libre a la particularité de ne pas fonctionner avec des logiciels jetables mais avec du durable et du réutilisable.

            • As-tu lu le code de beaucoup de logiciel libres ? Bon nombre de logiciels libres de référence (OpenSSL :) ) ont un code crade.
            • hacks ! = jetable. Parfois un hack est nécessaire à un instant T pour que les utilisateurs aient un logiciel qui marche, et on l'enlève quand on peut. Les codeurs de Linux ou de Python par exemple sont les premier à avouer avoir eu recours à des hacks, ce n'est pas sale :)
            • Attention je ne veux pas avoir l'air de prôner le code dégueulasse, en revanche la vertu numéro 1 d'un soft c'est de fonctionner (il faut juste ne pas s’arrêter à ce stade).

            Je me suis peut-être mal exprimé mais il ne s'agit pas de partager des assets mais des formats. Si je reprends l'exemple des dialogues, on peut très bien avoir un format unique mais des dialogues différents pour chaque jeu. L'avantage du format unique est qu'il permet d'avoir des outils commun pour le manipuler.

            Je comprends tout à fait l'idée, mais dans la mesure ou il n'y a pas de jeux libres d'aventures du genre d'akagoria, difficile de savoir quels vont être les besoins des autres jeux, qui devront donc être satisfaits pas cet éventuel format. Évidemment des tas de gens ici seront capable de te dire qu'il faut absolument ceci ou cela (moi le premier), mais sans être vraiment confronté au problème dans un vrai jeu, il est probable que tu finisses pas implémenter des fonctionnalités dont personne ne va se servir au final, et oublier les besoins réels des futurs jeux.

            Si Ruby on Rails et Django sont si bons, c'est parce qu'ils ont été écrits par des gens ayant écrit par mal de sites/apps web, ce qu'il leur a permis de voir les besoins réels, les patterns récurrents, les abstractions qui seraient utiles. S'il les avaient conçus avant même d'avoir ne serait-ce qu'un seul site à moitié fini, ces frameworks serait sûrement morts et enterrés.

            Ils ont du mal, pas tant dans le code que dans l'organisation.

            Difficile de leur jeter la pierre, rien de ce que j'ai pu écrire étant étudiant ne vaut quoi que ce soit.

  • # crossroad

    Posté par (page perso) . Évalué à 3.

    Cool de lire que tu utilises enfin crossroad, et apparemment avec succès! J'ai pas beaucoup de retours et ne savais pas si y avait vraiment des utilisateurs, hormis moi-même. N'hésite donc pas à faire des retours.

    Aussi il y aura encore quelques changements de syntaxe de ligne de commande avec la prochaine version (qui arrivera quand je trouverai enfin le temps de finaliser le tout), car j'ai ajouté quelques paradigmes, notamment pour pouvoir travailler sur plusieurs projets en même temps, avec des environnements de cross-compilation indépendants.
    Rien de terrible, ceci dit. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: crossroad

      Posté par . Évalué à 3.

      N'hésite donc pas à faire des retours.

      Ha ben, facile : ça fait le boulot, c'est pas dur à utiliser, ça me convient parfaitement. La documentation est suffisante, quand je me suis remis dedans, j'ai relu la manpage et hop, c'était parti.

      j'ai ajouté quelques paradigmes, notamment pour pouvoir travailler sur plusieurs projets en même temps, avec des environnements de cross-compilation indépendants.

      Il n'y a pas déjà ça dans la version actuelle ? En tout cas, je crois qu'il y a une notion de projet et à la fin, on peut avoir un gros zip avec tout ce qu'on a compilé. J'ai bien aimé ça (même si ça n'a pas fonctionné au final).

      • [^] # Re: crossroad

        Posté par (page perso) . Évalué à 3.

        Il n'y a pas déjà ça dans la version actuelle ?

        À part si tu utilises la version de dév (dépôt git), la version "release" n'a pas encore ce concept.
        Pour l'instant y a juste le concept de plateforme cible (w32, w64), mais la version à venir a des projets nommés par cible. Donc la cible "w64" pourra avoir le projet "akagoria", et d'autre projets (nommés différemment), chacun avec son propre environnement séparé, car on ne veut pas mélanger les binaires de plusieurs projets indépendants en général.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: crossroad

          Posté par . Évalué à 3.

          Alors je dois utiliser la version de dev ;) La première fois, j'avais utilisé le dépôt git, et du coup, j'ai continué. C'était étiquetée 0.5 dans le --version donc, je pensais que ça correspondait à cette version.

          Plus précisément, j'utilisais la version dont le dernier commit est f8c6b9e4d8afa4635a475c92af0a058a42bd76da (Date: Fri Oct 10 01:35:11 2014 +0200).

          • [^] # Re: crossroad

            Posté par (page perso) . Évalué à 4.

            Ah ben c'est en effet un commit intermédiaire. Mon dernier tag de release date de juillet.

            Je viens de rajouter des infos supplémentaires dans le --version pour distinguer des versions de dév à partir de maintenant. :-)

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # tmx

    Posté par (page perso) . Évalué à 3.

    Le format TMX est à peu près le seul format sur lequel tout le monde s'appuie dans pas mal de jeux libres. Certes il n'est pas parfait, mais son système de propriétés fait qu'on peut lui ajouter des fonctionnalités à peu de frais, tout en restant compatible avec le seul éditeur du format connu jusqu'à présent. Mais est-ce bien suffisant ?

    Oh que non, ce format est très compliqué, mal documenté et la compatibilité ascendante n'est pas garantie.

    http://devnewton.bci.im

    • [^] # Re: tmx

      Posté par . Évalué à 2.

      Ouais, pas parfait. Déjà pour les changements de la dernière version, c'était pas hyper clair au début pour moi. Et puis, en fouillant un peu, j'ai trouvé. La doc est pas super bien foutue, on ne sait pas trop ce qui est obligatoire et ce qui ne l'est pas, notamment dans les attributs (je crois qu'il y a des issues ouvertes à ce sujet sur github). Et d'ailleurs, ça peut changer d'une version à l'autre. Récemment, j'ai eu un cas : la longueur et la largeur sont facultatives, y compris pour un rectangle ou une ellipse (je ne crois pas que c'était le cas avant). La valeur par défaut est 0 pour les deux. Et le pire, c'est que dans l'éditeur, ça apparaît avec une largeur et une longueur non-nulles.

    • [^] # Re: tmx

      Posté par . Évalué à 4.

      J'ajoute que la standardisation, ça servirait aussi à ça, à documenter proprement et à décrire la compatibilité qu'on garantit.

  • # SQlite

    Posté par (page perso) . Évalué à 0. Dernière modification le 05/01/15 à 22:39.

    Et pourquoi pas SQlite?
    C'est utilisable partout, fiable contre les corruptions, supporte les fichiers de grande tailles, etc.
    Et pour les autres données devant être éditées à la main (dialogues, configuration), Lua me parait plus approprié que le json.

    • [^] # Re: SQlite

      Posté par (page perso) . Évalué à 2. Dernière modification le 05/01/15 à 23:02.

      Et pourquoi pas SQlite?

      bin parce que tu confonds tout : on parle de format, pas du stockage en tant que tel.

      Uh format c'est éditable, compréhensible.

      et tu le confirmes

      Et pour les autres données devant être éditées à la main (dialogues, configuration), Lua me parait plus approprié que le json.

      un langage tel que LUA, c'est pour lire ce format (l'écrire n'est qu'accessoire pour un format ouvert et cela est indépendant du langage).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.