URL: https://linuxfr.org/news/je-cree-mon-jeu-video-e14-formats-de-donnees Title: Je crée mon jeu vidéo E14 : formats de données Authors: rewind Nils Ratusznik, Benoît Sibaud et palm123 Date: 2015年01月01日T13:21:46+01:00 License: CC By-SA Tags: gamedev, format et opensuse Score: 33 «Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au [tag gamedev](http://linuxfr.org/tags/gamedev/public). Dans l'[épisode 13](http://linuxfr.org/news/je-cree-mon-jeu-video-e13-un-an-premier-bilan), 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. ---- [Akagoria, la revanche de Kalista](http://www.akagoria.org/) [le tag gamedev](http://linuxfr.org/tags/gamedev/public) ---- # 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](http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Format_de_s%C3%A9rialisation_de_donn%C3%A9es) serait probablement plus approprié, puisque pour chacun de ces formats, il peut y avoir plusieurs dialectes. Concrètement : - [XML](http://fr.wikipedia.org/wiki/Extensible_Markup_Language) 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](http://www.grinninglizard.com/tinyxml2/). - [Protocol Buffers](http://fr.wikipedia.org/wiki/Protocol_Buffers) est utilisé par le format Nanim de [devnewton](http://linuxfr.org/users/devnewton). Dans les dernières versions, Nanimstudio peut exporter les données en JSON plutôt qu'en Protocol Buffers. Actuellement, j'utilise [protobuf](https://code.google.com/p/protobuf/) couplée avec l'analyseur lexical généré depuis `nanim.proto`. - [YAML](http://fr.wikipedia.org/wiki/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](https://code.google.com/p/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](https://code.google.com/p/andors-trail/source/browse/AndorsTrail/res/raw/conversationlist_erinith.json), 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](http://fr.wikipedia.org/wiki/Analyse_s%C3%A9mantique) pour ces dialectes. Ces inconvénients sont une variante de la [réinvention de roue](http://fr.wikipedia.org/wiki/R%C3%A9inventer_la_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](http://fr.wiktionary.org/wiki/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](https://pypi.python.org/pypi/crossroad) qui a été [présenté ici-même](http://linuxfr.org/news/a-la-croisee-des-chemins-crossroad-environnement-de-cross-compilation) 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 [``](http://en.cppreference.com/w/cpp/header/cmath) ? En fait, elles sont dans les [spécifications Unix](http://pubs.opengroup.org/onlinepubs/7908799/xsh/math.h.html) 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](http://globalgamejam.org/). C'est un exercice amusant, et il y a de plus en plus de sites [partout en France](http://globalgamejam.org/2015/jam-sites?title=&country=FR&locality=), n'hésitez pas à y faire un tour. Personnellement, je serai à Besançon, avec mes étudiants qui organisent le site.

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