Salut,
je suis entrain de réfléchir à une structure pour le xml dont je vais avoir besoin.
Dans le jeu, le joueur bouge de case en case, et chaque case contient une rencontre.
Typiquement, une rencontre contient un texte narratif d'introduction et des choix. Un choix mène aussi typiquement à un autre texte narratif, avec là aussi éventuellement des choix, et aussi souvent un effet (de l'or, une arme, etc.., ou bien un combat).
Déja, je n'ai jamais géré de xml avec des données asymétriques; c-à-d qu'un élément "rencontre", peut parfois contenir seulement 2 choix, parfois 3, parfois aucun choix du tout, et juste un effet, ou bien un test sur un des attributs du personnage(par exemple si la force du personnage est inférieure à 5 ou bien si le perso possède tel ou tel artéfact, le texte narratif est différent et les éventuels choix aussi..)
A l'époque j'avais géré un xml qui contenait les données d'un quizz, donc c'était assez simple. Le nombre de réponses était fixe à chaque question, et une seule réponse était la bonne, puis ça s’arrêtait là. Ici, j'avoue que je suis un peu perdu.
J'ai évidemment en tête la structure dans les grandes lignes, mais dès que je réfléchis à l'aspect asymétrique de la chose, ça devient flou.
Vous pensez que le xml est adapté ?
Merci. (je rajoute que je code en c# sur unity)
Le XML m'avait permis de mettre des données en masse, avec des branches en nombre variable et de type différents à chaque ramification, il faut juste avoir une approche "for each" dans le code de chargement, c'est à dire que tu pars du principe que tu ne connais effectivement pas à l'avance le contenu d'une balise (en terme de quantité), mais que tant qu'il y en a qui arrive, tu stocke dans un conteneur dynamique.
Le XML est adapté pour une description basique des niveaux d'un jeu et d'une partie de leur logique, mais pour de la logique plus complexe, il vaut mieux passer par l'intégration d'une vraie partie scripting pour le projet. Mais là ça commence à devenir assez massif, un jeu simple peut se contenter de XML.
Je pense qu'il faut deja penser a comment sera ta structure en memoire, et ensuite tu pourra trouver comment la stoquer. Car ton XML va falloir le lire. Tu le lis ou et tu l'exploite comment ? (avec ces reponses ce sera plus simple)
A savoir que maintenant on préfère le JSON qui est plus flexible
Le 21 mai 2017 à 20:07:31 Lapintade a écrit :
Je pense qu'il faut deja penser a comment sera ta structure en memoire, et ensuite tu pourra trouver comment la stoquer. Car ton XML va falloir le lire. Tu le lis ou et tu l'exploite comment ? (avec ces reponses ce sera plus simple)
Je le lis à partir d'une classe qui va piocher aléatoirement une rencontre dans le xml et qui va afficher tout ça dans des éléments UI. Typiquement, un texte narratif puis en dessous de 2 à 4 choix.
Voila une rencontre typique :
<rencontre id="1">
<titre retentable="0">Le soldat blessé</titre>
<intro nbChoix="3" >Sur votre chemin, vous croisez un soldat en piteux état adossé contre un arbre.
Son armure est en partie détruite et du sang coule sur sa tempe.
Il vous toise du regard comme pour vous jauger. "Voyageur!", vous crie-t-il tant bien que mal, "un dernier repas pour un soldat au bord de la mort..."</intro>
<choix>
<texteChoix provisions="-3" honorHit="1">Approcher et lui donner 3 provisions.</texteChoix>
<texteNarratifResultat nbChoix="1" >Le soldat avale difficilement quelques bouchées. "Merci, voyageur".</texteNarratifResultat>
</choix>
<choix quitter="1" honteHit="1">Le laisser à son triste sort et continuer votre chemin.</choix>
<choix honteHit="5" testHasard="1" succes="8" ratage="15"> L'achever pour récupérer son équipement.</choix>
</rencontre>
Je crois que j'ai pas le choix que d'utiliser lourdement les attributs et de tester leur présence.
Retentable signifie si cette rencontre peut être réactivée ou pas, si le joueur repasse sur cette case par la suite.
nbChoix pourra peut-être me servir à me faciliter la tache.
Honte et honneur sont des caractéristiques du personnage et les choix ont des conséquences.
testHasard activera un petit jeu de hasard, "succes" signifie que le joueur gagnera(s'il réussit le jeu de hasard) le bonus numero 8 dans une liste de bonus que j'aurai créée à l'avance, idem pour ratage mais dans une liste de malus.
Je trouve que ça devient vite lourd et que xml n'est pas très adapté à ce que je cherche à faire. Je réfléchis à créer mon propre format de fichier avec mes propres "panneaux indicateurs", si vous voyez ce que je veux dire.
je viens d'apprendre que dans unity on ne peut pas placer un prefab en tant qu'enfant d'un autre prefab dans la hiérarchie sans que cet enfant perde son lien vers le prefab de base... Tout a coup, unity me parait etre un truc amateur bidon. Ca me complique encore tache, moi qui voulait laisser tomber le xml pour créer des prefab de mes "rencontres"...