+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Modélisation Dialogues & prérequis (/showthread.php?tid=6740)
Pages :
1
2
RE: Modélisation Dialogues & prérequis - Xenos - 18-04-2013
Ok, XML est verbeux, mais il possède la contrepartie d'avoir également la norme XSD, qui permet de définir clairement (et de façon standard) la structure du fichier XML (pour JSON, je suis pas certain que cela existe). La verbosité est également à relativiser, la différence majeure entre XML et JSOn étant la présence d'un tag de fermeture en XML; si le fichier ne présente pas une hyper-abondance structurelle (que des noeuds, et quasiment pas de données), la différence est minime. C'est le cas d'un fichier de dialogues (le contenu texte d'un dialogue sera bien plus important que la longueur de la chaine de caractères constituant le nom du noeud).
L'autre intérêt du XML étant la sécurité (JSON doit être évalué: que se passera-t-il si un tiers modifie le fichier JSOn pour y coller des commandes malsaines, ou si une erreur a lieu dans le transfert de fichier? On est obligé de rajouter une couche de sécurisation).
Bon, après, c'est le même genre de "débat" que Linux/MAC/Windows, tout aussi productif, alors, fait comme tu le sens
Effectivement, la relecture peut être intéressante si le joueur a raté un truc. Tu devrais, à mon avis, joindre un petit système de statistiques qui te permettrait de savoir quels dialogues ont été lus combien de fois, et après quels autres. L'idée serait que tu puisses te construire un visuel du graphe d'un dialogue qu'un joueur a fait, et de disposer également d'un visuel du graph moyen des dialogues, qui indiquerait, en moyenne, quel dialogue est lu après quel autre. De cette façon, tu devrais pouvoir dégager des tendances. Par exemple, si 90% des gens ont répétés 2 fois un lot de 4 dialogues, alors peut-être que ces dialogues ne sont pas clairs, ou alors ils sont trop vite "écrasés" par les dialogues suivants, bref, y'a un soucis à ce niveau là. Cela te permettra aussi de savoir quels dialogues ne sont jamais lus, et donc de pouvoir les remplacer ensuite par d'autres textes de dialogues, plus pertinents.
Bonne chance !
RE: Modélisation Dialogues & prérequis - Argorate - 18-04-2013
Si un joueur modifie le JSON, ça changera peut être les textes écris a l'écran mais ça n'a donc aucun intérêt (autant modifier le contenu avec firebug, ce sera moins long)...
C'est verbeux mais plus lourd en terme de poids comme je disais. je compte faire des tableau et des objets, donc [] et {} là où il faut des <dialogs><dialog></dialog></dialogs>...
De plus, je charge déjà les infos de pnj en json, du coup c plus simple de leur ajout un attribut dialogs qui sera charger dans le même ajax qu’actuellement (et qu'une fois), que de devoir faire un autre appel serveur.
L'idée des stats est pas mal mais ça veux dire faire des requêtes ajax régulièrement juste pour des stats
RE: Modélisation Dialogues & prérequis - Xenos - 18-04-2013
Citation :je charge déjà les infos de pnj en jsonC'est l'argument le plus pertinent si on était dans un débat
Tu n'es pas forcé de faire des requêtes AJAX régulières: tu peux très bien stocker les informations de statistiques dans un objet temporaire (objet javascript par exemple), et une fois le dialogue fini, envoyer cet objet au serveur (via AJAX par exemple) pour qu'il le traite.
Rien ne t'oblige à récolter les statistiques d'un évènement (lancement d'un dialogue par exemple) au moment exact où cet évènement a lieu.
RE: Modélisation Dialogues & prérequis - Argorate - 18-04-2013
oui oui j'entends bien, si c'est un dialogue ça va, mais le risque c'est que le mec ferme le navigateur ou quoi et que tu perdes tout. Si tu ajax une fois quand la pop up de dialogue de pnj se ferme par exemple, ça me parait pertinent, du coup ton idée me plaît assez bien, j'essayerais de voir de faire ça, après
merci pour ton aide en tout cas.