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

Posté par rewind (Mastodon) le 02 janvier 2015 à 14:21. Édité par Nils Ratusznik, Benoît Sibaud et palm123. Modéré par NeoX. Licence CC By‑SA.

Étiquettes :

jan.

2015

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

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.

Aller plus loin

Akagoria, la revanche de Kalista (209 clics)
le tag gamedev (165 clics)

# formats de données?

Posté par alpha_one_x86 (site web personnel) le 02 janvier 2015 à 14:47. É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 rewind (Mastodon) le 02 janvier 2015 à 18:50. É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 EdB le 02 janvier 2015 à 15:03. Évalué à 1.

Je pense qu'il y a erreur de catégorie
- [^] # Re: catégorie
  
  Posté par Benoît Sibaud (site web personnel) le 02 janvier 2015 à 15:15. Évalué à 4.
  
  Corrigé, merci.
# Non a YAML !

Posté par Drup le 03 janvier 2015 à 08:56. Évalué à 1. Dernière modification le 03 janvier 2015 à 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 M.Poil (site web personnel) le 03 janvier 2015 à 09:38. É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 David Carlier le 03 janvier 2015 à 10:15. É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 ariasuni le 03 janvier 2015 à 18:46. É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 Drup le 03 janvier 2015 à 23:31. É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 rewind (Mastodon) le 04 janvier 2015 à 00:03. É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 grim7reaper le 03 janvier 2015 à 10:26. É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 Drup le 03 janvier 2015 à 23:36. É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 grim7reaper le 04 janvier 2015 à 09:38. É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 claudex le 03 janvier 2015 à 10:34. É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 devnewton 🍺 (site web personnel) le 04 janvier 2015 à 00:56. É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).
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Non a YAML !
      
      Posté par claudex le 04 janvier 2015 à 10:33. É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 devnewton 🍺 (site web personnel) le 04 janvier 2015 à 15:07. É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.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Non a YAML !
        
        Posté par claudex le 04 janvier 2015 à 19:01. É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 devnewton 🍺 (site web personnel) le 08 janvier 2015 à 18:25. Évalué à 2. Dernière modification le 09 janvier 2015 à 10:08.
        
        Il suffit de faire:
        
        { "doc" : { "what": "this is a video conf", "sample": { "video": { "w": 640, "h": 480 } } }, "video": { "w": 640, "h": 480 } }
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Non a YAML !
        
        Posté par PyroTokyo le 06 janvier 2015 à 06:56. É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 claudex le 06 janvier 2015 à 18:59. É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 PyroTokyo le 07 janvier 2015 à 01:31. É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 PyroTokyo le 07 janvier 2015 à 02:10. É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 rewind (Mastodon) le 03 janvier 2015 à 11:12. É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 wysman le 03 janvier 2015 à 12:43. É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 Jehan (site web personnel, Mastodon) le 03 janvier 2015 à 21:06. É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 claudex le 03 janvier 2015 à 21:31. É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 chercher¹ comment exprimer cette structure pour ce logiciel en particulier (ce qui n'est pas toujours simple si ce n'est pas écrit simplement).
    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
    - [^] # Re: Non a YAML !
      
      Posté par devnewton 🍺 (site web personnel) le 04 janvier 2015 à 01:06. Évalué à 2.
      
      Plus mieux que les INI, il y a le format "INFO": http://www.boost.org/doc/libs/1_57_0/doc/html/boost_propertytree/parsers.html#boost_propertytree.parsers.info_parser
      
      Ça a l'air pas mal, mais je ne crois pas qu'il existe des parsers pour d'autres langages…
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Non a YAML !
        
        Posté par reno le 05 janvier 2015 à 10:43. Évalué à 2.
        
        Je ne connais pas le format INFO mais il y a le format TOML qui est intéressant: https://github.com/toml-lang/toml
        
        Bon ça n'est pas encore en version 1.0 et ~~il n'y a pas de de spec BNF~~ la spec (A)BNF est cachée dans une branche et je ne l'avais pas remarquée.
# Le plus gros manque ?

Posté par GuieA_7 (site web personnel) le 03 janvier 2015 à 12:30. É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 voxmundix le 03 janvier 2015 à 13:19. Évalué à 2. Dernière modification le 03 janvier 2015 à 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 GuieA_7 (site web personnel) le 03 janvier 2015 à 13:54. É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 rewind (Mastodon) le 03 janvier 2015 à 16:18. É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.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 03 janvier 2015 à 20:55. Évalué à 3.
    
    Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Le plus gros manque ?
    
    Posté par GuieA_7 (site web personnel) le 04 janvier 2015 à 12:52. É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 claudex le 04 janvier 2015 à 13:01. É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 rewind (Mastodon) le 04 janvier 2015 à 13:54. É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 GuieA_7 (site web personnel) le 04 janvier 2015 à 15:16. É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 Jehan (site web personnel, Mastodon) le 03 janvier 2015 à 21:11. É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 rewind (Mastodon) le 04 janvier 2015 à 00:07. É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 Jehan (site web personnel, Mastodon) le 04 janvier 2015 à 01:04. É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 rewind (Mastodon) le 04 janvier 2015 à 09:33. É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 Jehan (site web personnel, Mastodon) le 04 janvier 2015 à 12:14. É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 devnewton 🍺 (site web personnel) le 03 janvier 2015 à 22:25. É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.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: tmx
  
  Posté par rewind (Mastodon) le 04 janvier 2015 à 00:16. É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 rewind (Mastodon) le 04 janvier 2015 à 00:19. Évalué à 4.
  
  J'ajoute que la standardisation, ça servirait aussi à ça, à documenter proprement et à décrire la compatibilité qu'on garantit.
# SQlite

Posté par weeber (site web personnel) le 05 janvier 2015 à 22:36. Évalué à 0. Dernière modification le 05 janvier 2015 à 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 BAud (site web personnel) le 05 janvier 2015 à 23:01. Évalué à 2. Dernière modification le 05 janvier 2015 à 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).
  - [^] # Re: SQlite
    
    Posté par weeber (site web personnel) le 05 janvier 2015 à 23:06. Évalué à 3.
    
    Protocol Buffer n'est pas vraiment un format éditable, concernant le XML c'est discutable…
  - [^] # Et pourquoi pas un langage pour le fichier de config
    
    Posté par nado le 22 janvier 2015 à 13:39. Évalué à 0.
    
    Il y a quelques projets qui utilisent un fichier source comme fichier de configuration, tel xmonad (haskell), est-ce que ça ne pourrait pas être une solution ?
    
    Lua pourrait le faire. Ou d’autres d’ailleurs, il suffit de trouver un langage assez accessibles à des non informaticiens et interfaçable avec un maximum d’autres langages afin d’être indépendant du projet.
    - [^] # Re: Et pourquoi pas un langage pour le fichier de config
      
      Posté par nado le 22 janvier 2015 à 16:50. Évalué à 0.
      
      Config voulant dire éditable par un utilisateur, au cas où. Si ça ne doit jamais être utilisé par un utilisateur, autant utiliser un format plus adapté.
      - [^] # Re: Et pourquoi pas un langage pour le fichier de config
        
        Posté par rewind (Mastodon) le 25 janvier 2015 à 11:18. Évalué à 2.
        
        Il n'y a pas que le confort de l'utilisateur, il y a aussi le confort du développeur : ne pas avoir à recompiler un jeu pour tester un changement dans un fichier de config, c'est très appréciable !
        
        [^] # Re: Et pourquoi pas un langage pour le fichier de config
        
        Posté par barmic le 25 janvier 2015 à 14:16. Évalué à 4.
        
        Tu dis ça parce que tu fais du C++ avec des templates. :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Et pourquoi pas un langage pour le fichier de config
        
        Posté par rewind (Mastodon) le 25 janvier 2015 à 20:59. Évalué à 2.
        
        Même pas, hormis la STL ;)

Suivre le flux des commentaires

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