Le topic de la programmation, string, chaînes, cuir et compagnie

[Møgluglu]

Je demande ça parce que j'avais fait un jeu et le choix de sérialiser en XML avait été fait

T'as bossé sur The Witcher ?

[Nattefrost]

Non, pas du tout

[Møgluglu]

Ouf, tu me rassures.

Jelb: c'est le seul jeu que je connais où il faut 3 minutes de temps de chargement pour afficher la liste des sauvegardes.

[Nattefrost]

Haha . Nan c'était un projet etudiant. Mais du coup est-ce que dans certains projets ça peut valoir le coup de mettre les deux en place ou c'est overkill ?
Sérialisation
-XML (ou json) pour le dev
-binaire pour le mode release (ça complique aussi la triche dans le cas d'un jeu)

[Patate]

N'essaie pas. Cherry-picke dans ton état ce qui est nécessaire. Même dans un langage plus managé, la sérialisation brutale de toutes les données du jeu à partir d'un objet racine est quasi-systématiquement une connerie.
Et j'en ai débuggué des codes trop élégants à base de pickle python ou autres.
En plus si tu choisis ce que tu sauvegardes, ajoute des numéros de version. Et tu pourras sans doute gérer la compat' ascendante de tes sauvegardes au fur et à mesure que ton code continuera à évoluer, ce qui est précieux.
Mais il te faut quand même un framework pour itérer sur tous tes objets, les sérialiser, et savoir les reconstruire.

Il me semble qu'en général le principe c'est que tu convertis entre ton état de jeu et une série d'objets plus simples, et ces objets-là tu les sérialises/désérialises bêtement.

Tu sérialise en binaire pour des raisons particulières?
Je demande ça parce que j'avais fait un jeu et le choix de sérialiser en XML avait été fait pour pouvoir éditer des sauvegardes et créer des états de jeu particuliers soit pour faire une démo à qqun mais surtout pour faire des tests unitaires dans des cas bien précis.

Tant que je suis là j'ai une question : quelqu'un a déjà entendu causer ou même utilisé Crystal ? C'est bien moins avancé qu'un Rust ou Kotlin mais je suis assez curieux.

Enfait je cherche le moyen le plus simple (dans l'implémentation) de faire un système de sauvegarde. Je note que sérialiser l'objet racine est une mauvaise idée

Pour le choix du binaire, c'est juste par simplicité. Mais maintenant que je vais devoir gérer ça plus ou moins à la main, la finalité (xml ou binaire) revient au même en terme de travail je pense.

Tes arguments sur le fait d'utiliser le xml sont intéressants (surtout pendant le debug), je vais peut-être partir là dessus. Maintenant c'est un petit jeu perso pour le plaisir donc si un jour des gens lancent le jeu et veulent tricher...

Merci pour les conseils !

[Tomaka17]

Je vois pas trop l'intérêt du binaire. Ça permet d'économiser de la place, mais c'est rarement un problème pour les sauvegardes de jeu.
Si tu veux éviter les script kiddies qui trichent, t'as qu'à gzipper le JSON puis tu modifies le magic number de l'en-tête pour éviter que ce soit ouvrable facilement.

[Tramb]

Je vois pas trop l'intérêt du binaire. Ça permet d'économiser de la place, mais c'est rarement un problème pour les sauvegardes de jeu.
Si tu veux éviter les script kiddies qui trichent, t'as qu'à gzipper le JSON puis tu modifies le magic number de l'en-tête pour éviter que ce soit ouvrable facilement.

C'est souvent un problème pour les sauvegardes de jeu avec un peu de state.
Binaire ou texte, ça ne change rien, il faut du code qui passe un peu partout opur dire sauve moi ça comme un u32, sauve-moi ça comme une string, et tutti quanti. Si le framework est bien fait, ils seront interchangeables. Et convertibles.
Le seul intérêt du texte, c'est le diff et le patching, à mon sens.
Et toujours penser à truffer de numéros de versions pour la backward compat, à bumper quand quelque chose change.

[Patate]

D'ailleurs si je pars en xml ou json. Il y aurait une façon élégante de coder ça ? Parce là, à mon niveau, je pense écrire sur chaque objet une fonction save/load en gros.

[Patate]

Hum comme me la suggéré Tomaka17, je vais créer un objet intermédiaire pour stocker plus facilement les données à sauvegarder avant de les écrire.

[Tramb]

C'est pas élégant mais fonctionnel et ça répond à un principe : pars du cas particulier et va vers le général plutôt qu'essayer tout de suite de faire une usine à gaz.
Exo : vérifie comment ton système marche quand tu ajoutes, enlèves et change le type d'une variable.

[Patate]

J'ai attaqué comme ça, je vais voir comment ça réagit

[Nattefrost]

D'ailleurs si je pars en xml ou json. Il y aurait une façon élégante de coder ça ? Parce là, à mon niveau, je pense écrire sur chaque objet une fonction save/load en gros.

C'est ce que j'avais fait mais c'était en C# (enfin chaque objet avec une fonction save/load). Fais gaffe si t'as des objets qui se référencent les uns les autres.
Après je ne sais pas si c'est la 'bonne' façon de faire, en tous cas ça fonctionne.

[Tramb]

Pour les liens entre objets, il te faudra une notion de handle.

[Tomaka17]

Binaire ou texte, ça ne change rien, il faut du code qui passe un peu partout opur dire sauve moi ça comme un u32, sauve-moi ça comme une string, et tutti quanti. Si le framework est bien fait, ils seront interchangeables. Et convertibles.

Ouai jusqu'au moment où tu repères un bug dans l'encodage binaire du framework.
Modifier le comportement de ton programme entre le debug et le release c'est toujours horriblement casse-gueule.

[war-p]

Hum comme me la suggéré Tomaka17, je vais créer un objet intermédiaire pour stocker plus facilement les données à sauvegarder avant de les écrire.

Pour en revenir sur ce que tu disais, ça sert à rien d'essayer de faire un stage save de tout ton moteur. Il vaut mieux wrapper toutes les valeurs qui ont du sens dans un fichier et le recharger par la suite. Ça sera plus léger et moins casse gueule pour toi.

[Tramb]

Ouai jusqu'au moment où tu repères un bug dans l'encodage binaire du framework.
Modifier le comportement de ton programme entre le debug et le release c'est toujours horriblement casse-gueule.

Pourquoi il y aurait plus de bug que dans l'encodage texte du framework ?

[Tomaka17]

Pourquoi il y aurait plus de bug que dans l'encodage texte du framework ?

Il n'y en a pas nécessairement plus, mais si t'as testé ton app en debug et qu'au moment de compiler en release tu trigger un bug sans le savoir, tu vas ship une appli buggée.

[Tramb]

Il n'y en a pas nécessairement plus, mais si t'as testé ton app en debug et qu'au moment de compiler en release tu trigger un bug sans le savoir, tu vas ship une appli buggée.

Ca c'est bien vrai. Mais il ne faut pas conditionner ça au build debug/release.

[deathdigger]

Sur les sauvegardes des jeux qui demandent beaucoup de data (je pense notamment aux rpgs genre Elder Scroll), ça marche comment d'ailleurs ? Parce que vu la quantité de coffres/portes/objets qui peuvent être ouverts/déplacés/plein/vides, les sauvegardes doivent peser une tonne au bout d'un moment, non ?

[Tramb]

Souvent ce genre de jeux encode le delta entre l'état pristine et l'état courant.
Souci : les sauvegardes deviennent de plus en plus grosses et lentes au fur et à mesure que tu joues.
Deux écoles, soit tu vises le worst case, soit tu souhaites améliorer le cas moyen.

[war-p]

Sur les sauvegardes des jeux qui demandent beaucoup de data (je pense notamment aux rpgs genre Elder Scroll), ça marche comment d'ailleurs ? Parce que vu la quantité de coffres/portes/objets qui peuvent être ouverts/déplacés/plein/vides, les sauvegardes doivent peser une tonne au bout d'un moment, non ?

A noter que la plupart du temps, les coffres "peu important" n'ont pas d'état sauvegarder, par exemple, seul les coffres de loot de boss vont être liés au statut du donjon (fini ou pas). Bref, il y a plein d'astuces, d'ailleurs je conseil les articles sur gamasutra, il y a pas mal d'idées concernant ce genre de choses. (J'avais lu par exemple un article expliquant comment faire du rewind et des savestate assez facilement en suivant un pattern bien défini)

[Tomaka17]

Et à part ça, oui parfois les sauvegardes de jeu font jusqu'à plusieurs dizaines voire plus d'une centaine de Mo.

[war-p]

A l'inverse on trouve des systèmes de sauvegarde très malin comme celui des premier metroids.

[Teocali]

Un bout de papier et un crayon pour noter le code ?

[Mr Slurp]

Un bout de papier et un crayon pour noter le code ?

Ouai mais le fait que le code soit capable de donner précisément un état du jeu (salles visitées, équipement obtenu, etc), c'est plutôt futé (ce n'est pas le seul à avoir employé cette méthode à l'époque des cartouches sans sauvegarde)

[Teocali]

Ouai mais le fait que le code soit capable de donner précisément un état du jeu (salles visitées, équipement obtenu, etc), c'est plutôt futé (ce n'est pas le seul à avoir employé cette méthode à l'époque des cartouches sans sauvegarde)

Je suis d'accord mais je me souviens du nombre de parties de Megaman que j'ai recommencé parce que j'avais mal noté le code...

[Patate]

Vous utilisez quoi comme paramètres sur votre compilateur (c++) pendant le développement (sans parler d'opti). Au niveau des warnings, bonnes pratiques, etc ?

[gundz]

Vous utilisez quoi comme paramètres sur votre compilateur (c++) pendant le développement (sans parler d'opti). Au niveau des warnings, bonnes pratiques, etc ?

-Wall -Werror -Wextra pour ma part

[Tramb]

Niveau 3 sur msvc avec des pragma pour ignorer les trucs les plus relous.
Mais ceux de gcc et clang sont vraiment mieux foutus.
Essaie de compiler ton projet avec plusieurs compilos, de passer des outils d'analyse statique, c'est toujours positif !

[Patate]

En outil d'analyse statique vous pensez à quoi ? Statique c'est que ça analyse uniquement le code source, pas pendant l'exécution ?