+- 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 : gestion des différents prérequis (/showthread.php?tid=7535)
Pages :
1
2
gestion des différents prérequis - fortz - 15-12-2015
Bonjour à tous,
Je suis en pleine conception de mon jeu par navigateur, plus précisément je suis actuellement en train de créer mon modèle relationnel de données afin d'y voir plus clair à ce niveau et de commencer le développement. Je me heurte alors à un problème de taille : la gestion des prérequis. Avant tout je tiens à préciser que j'ai déjà lu les sujets concernant les prérequis sur ce forum et d'autres, mais je voudrais vous proposer mon modèle afin de recueillir vos avis et vos propositions d'améliorations.
Ce système de prérequis n'est pas totalement basique. En effet, il y a 4 types de prérequis :
- ceux concernant les bâtiments (ex : avoir l'armurerie niveau 8)
- ceux concernant les objets (ex : avoir la faux du diable en sa possession)
- ceux concernant les quêtes (ex : avoir terminer la quête "tueur de soldats")
- ceux concernant les technologies (ex : avoir rechercher "économie")
Ces prérequis s'appliquent sur plusieurs domaines :
- les bâtiments (ex : pour construire ce bâtiment, il vous faut ...)
- les quêtes (ex : pour pouvoir commencer cette quête, il vous faut ...)
- les technologies (ex : pour pouvoir rechercher cette technologie, il vous faut ...)
- les objets (ex : pour pouvoir avoir cet objet, il vous faut ...)
- les troupes (ex : pour pouvoir former cette troupe, il vous faut ...)
Voila pour les présentations. J'ai donc tenter de créer un modèle permettant de prendre tout cela en compte et j'ai aboutit à celui-ci :
À savoir que le champ 'type' dans les tables prérequis serait par exemple 'quete' ou 'batiment', c'est-à-dire ce sur quoi porte le prérequis. Ce qui me permet ensuite de comprendre le sens du #id du champ suivant qui se réfère aux 'quete' ou 'batiment'. Donc par exemple si 'type' = 'batiment' alors 'id' portera sur le champ 'id_batiment' de la table Batiments.
Batiments (id_batiment, nom_batiment, description_batiment)
Objets (id_objet, nom_objet, description_objet, rarete_objet)
Quetes (id_quete, nom_quete, description_quete, recompenses_quete)
Technologies (id_technologie, nom_technologie, description_technologie, effet_technologie)
PrerequisBatiment (id_prerequis_batiment, type, #id, #id_batiment_requis, niveau_batiment_requis)
PrerequisObjet (id_prerequis_objet, type, #id, #id_objet_requis)
PrerequisQuete (id_prerequis_quete, type, #id, #id_quete_requise)
PrerequisTechnologie (id_prerequis_technologie, type, #id, #id_technologie_requise, niveau_technologie_requise)
Voilà, en attente de vos critiques ou améliorations. Je suis disponible pour répondre à toutes vos questions. Merci par avance !
RE: gestion des différents prérequis - Xenos - 15-12-2015
Citation :À savoir que le champ 'type' dans les tables prérequis serait par exemple 'quete' ou 'batiment', c'est-à-dire ce sur quoi porte le prérequis. Ce qui me permet ensuite de comprendre le sens du #id du champ suivant
D'expérience, je peux te dire que ce genre d'approche, ça explose vite (= c'est la merde), car tu ne peux plus faire de jointure ni utiliser des clefs étrangères. Ca va te péter dans les doigts.
Mieux vaudrait, à ce compte-là, avec N colonnes dans la table de prérequis (une colonne par type) et mettre tout à NULL, sauf une. T'auras au moins les clefs étrangères et les jointures. Mais ce sera un peu la misère car tu vas avoir N colonnes (une par type, donc ici 4) dont une et une seule doit être non-NULL.
Pour ma part, je ferai plutôt cela {J'ai édité ce message pour ajouter la 2nde partie; j'aurai pu synthétiser, mais je préfère laisser le processus de pensée complet car je le trouve intéressant (et tant pis si ça sonne "je me jette des fleurs")}:
• 1 table pour chacun des domaines:
Batiment - Objets - Quetes - Technologies - Troupes
• 1 table pour chacun des types de prérequis:
PrerequisBatiment - PrerequisObjets - PrerequisQuetes - PrerequisTechnologies
• 1 table pour chacun des liens possibles:
Batiment _PrerequisBatiment - Batiment _PrerequisObjets - Batiment _PrerequisQuetes - Batiment _PrerequisTechnologies - Objets _PrerequisBatiment - Objets _PrerequisObjets - Objets _PrerequisQuetes - Objets _PrerequisTechnologies - Technologies_PrerequisBatiment - Technologies_PrerequisObjets - Technologies_PrerequisQuetes - Technologies_PrerequisTechnologies - Troupes_PrerequisBatiment - Troupes_PrerequisObjets - Troupes_PrerequisQuetes - Troupes_PrerequisTechnologies
C'est sûr, dit comme cela, ça fait un paquet de tables, mais mieux vaut beaucoup de tables élémentaires en charge d'une seule chose (d'une seule relation) que peu de tables qui font tout (et n'importe quoi). Ca répond à la problématique posée.
2e partie:
Maintenant, on lève une nouvelle problématique: ça fait plein de tables.
Donc, construisons un composant (une table) qui répond à cette problématique (qui n'a rien à voir avec la notion des prérequis/domaines). On a 4 types de prérequis et 5 domaines, soit 5x4=20 combinaisons. L'idée, c'est de faire un composant intermédiaire qui, à l'image d'une spec (genre HTML5) va faire passer de 5x4 combinaisons à 4+5 combinaisons. On va donc abstraire chaque moitié (domaine d'un coté, prérequis de l'autre) et on fera le lien entre ces abstractions:
• 1 table "abstraite" représentant un Domaine:
Domaine (id)
Ca fait pauvre en colonnes comme table, mais osef.
• 1 table pour chacun des domaines:
Batiment - Objets - Quetes - Technologies - Troupes
Avec une nouvelle colonne "idDomaine" qui fait référence à la table "Domaine::id"
• 1 table "abstraite" représentant un Prérequis:
Prerequis (id)
Ca fait là-encore pauvre en colonnes comme table, mais osef.
• 1 table pour chacun des types de prérequis:
PrerequisBatiment - PrerequisObjets - PrerequisQuetes - PrerequisTechnologies
Avec une nouvelle colonne "idPrerequis" qui fait référence à la table "Prerequis::id"
• 1 table unique liant le Domaine au Prérequis:
Domaine_Prerequis (id, idDomaine, idPrerequis)
La colonne "id" est facultative. Une clef unique (idDomaine, idPrerequis) sera utile.
Voilà
RE: gestion des différents prérequis - fortz - 15-12-2015
Avec le dernier modèle que tu me présente, il me semble que ça ne gère pas le fait de vouloir mettre deux prérequis d'un même domaine (ex : pour construire un batiment je dois avoir deux technologies) ?
Ca donnerait ainsi cela :
Batiments (id_batiment, nom_batiment, description_batiment)
Objets (id_objet, nom_objet, description_objet, rarete_objet)
Quetes (id_quete, nom_quete, description_quete, nombre_etapes_quete, recompenses_finale)
Technologies (id_technologie, nom_technologie, description_technologie, effet_technologie, cout_koins, cout_pierres, cout_bois, cout_ciment, cout_metal)
Domaines (id_domaine)
Batiments (#id_domaine_batiment)
Objets (#id_domaine_objet)
Quetes (#id_domaine_quete)
Technologies (#id_domaine_technologie)
Troupes (#id_domaine_troupe)
Prerequis (id_prerequis)
PrerequisBatiments (#id_prerequis)
PrerequisObjets (#id_prerequis)
PrerequisQuetes (#id_prerequis)
PrerequisTechnologies (#id_prerequis)
DomainePrerequis (id_domaine, id_prerequis)
Et je me heurte à un nouveau problème :
Comment faire en sorte (en considérant qu'une quête est composé de plusieurs étapes) de donner des prérequis différents à une même quête (mais pas à la même étape) ? J'ai pensé à rajouter une table PrerequisEtapesQuetes (id_prerequis_etape_quete, type, #id, #id_quete, numero_etape) sur mon ancien modèle mais sur le modèle que tu me conseilles je n'arrive pas à l'appliquer !
Et si au lieu de mettre que 'type' = 'batiment', 'quete', etc... j'associais à chacun des types un numéro et que du coup 'type' = 1 ou 2 ou ... (avec 1 qui correspond aux batiments, etc...), serait-ce mieux ?
RE: gestion des différents prérequis - Xenos - 16-12-2015
Citation :Et si au lieu de mettre que 'type' = 'batiment', 'quete', etc... j'associais à chacun des types un numéro et que du coup 'type' = 1 ou 2 ou ... (avec 1 qui correspond aux batiments, etc...), serait-ce mieux ?
Non. Les données dans les tables ne doivent pas définir la structure des relations entre les tables (aka, le "sens" des données contenues dans une colonne ne doit pas dépendre des données des autres colonnes).
Lier Domaine et Prerequis est le but de la table Domaine_Prerequis (id, idDomaine, idPrerequis): celle-ci peut contenir les données (1, 1), (1, 2), (1, 3), (2, 2), (2, 4) indiquant que le Domaine 1 nécessite les Prerequis 1, 2, 3 et le Domaine 2 nécessite les Prérequis 2, 4 (un Prérequis peut servir à plusieurs Domaine).
On peut donc avoir plusieurs prérequis pour un même domaine, et un prérequis peut servir à plusieurs domaines (cela s'appelle "une table de relation N-N" car on peut avoir N domaines liés à N prerequis).
Comme "Prerequis" est une abstraction, tu peux avoir 2 Prerequis pour 1 Domaine, qui sont 2 PrerequisTechnologique.
L'ajout des étapes de quêtes se fait en ajoutant la table:
EtapesQuete(id_etape, #id_quete,..., #id_domaine)
A chaque EtateQuete, il faudra créer un Domaine, auquel seront associé un ou plusieurs Prerequis.
Je me demande si la confusion ne vient pas de la lecture qu'on fait chacun de "PrerequisBatiment". Dans ma réponse, il faut l'entendre comme "Un prérequis qui est d'avoir tel Batiment", alors que dans ta question (après 3e relecture), j'ai l'impression que tu le lis comme "Un prérequis permettant de construire un batiment".
Remplace "Domaine" par "RequiertPrerequis" dans mes réponses, ce sera peut-être plus clair.
RE: gestion des différents prérequis - niahoo - 16-12-2015
Citation :Comment faire en sorte (en considérant qu'une quête est composé de plusieurs étapes) de donner des prérequis différents à une même quête (mais pas à la même étape) ?
C'est simple : tu fais plusieurs quêtes. Elles vont s'appeler « Quete du truc bidule – Étape 1 », « Quete du truc bidule – Étape 2 » mais en fait ce sont plusieurs quêtes. Quand une étape finit, la quête suivante s'affiche automatiquement.
Je ne sais pas si tu as joué à WoW ou à d'autres MMO du même genre, mais quand tu finis une étape, genre « parle à Machin », tu as un bouton « Terminer », puis automatiquement un texte apparaît te proposant la suite. C'est en fait une nouvelle quête. Selon le jeu, elle est automatiquement acceptée par le jeu (pour qu'elle reste dans le journal de quêtes). Dans d'autres jeux, il faut cliquer sur « Accepter » à chaque étape.
Il faut donc que tes quêtes aient un champ indiquant l'id de la quête suivante.
Bon, ensuite tu peux simplement appeler ça des étapes dans une table étapes, mais je pense qu'il est plus simple comme ça de lier les pré-requis et les récompenses aux étapes. ça te permet de donner des récompenses intermédiaires : un peu de thunes, ou un objet qui sert justement de pré-requis pour la suite ; genre amène moi 10 rondis de bois, puis en récompense avec ces rondins je te craft instantanément un bâton magique, et à l'étape suivante on va se servir de ce bâton.
RE: gestion des différents prérequis - fortz - 16-12-2015
Merci pour vos réponses
Xenos : en fait, je n'arrive pas à "m'approprier" ton modèle de données car je ne vois pas tellement ce qu'il pourrait y avoir dans chacun de ces tables (mis à part celle que tu m'as déjà détaillé), pourrais-tu me fournir un petit jeu de données à l'intérieur de certaines tables pour que je vois avec un exemple (je comprends tjr mieux avec des exemples, la jeunesse surement :p)
niahoo : Merci pour ces conseils, donc selon toi je ne devrais avoir qu'une seule table "quetes" avec toutes les quetes et simplement rajouter un champ "quete_precedente" qui sera égale à l'id de l'étape précédente ou null si c'est la première étape ?
Merci pour votre aide
RE: gestion des différents prérequis - Xenos - 16-12-2015
RE: gestion des différents prérequis - fortz - 17-12-2015
Donc si j'ai bien compris :
Quelque soit le type de prérequis, il est référencé dans la table prérequis ? Et chaque élément de la table requiertprerequis peut être composé de plusieurs prerequis ? donc chaque domaine pointe vers un requiertprerequis qui pointe lui même sur 1 ou plusieurs prérequis de même/différents types ?
Si c'est bien ça je crois que je comprends le fonctionnement qui est plutôt intelligent : 1 domaine -> 1 requiertprerequis -> 1..* prerequis. Je te te laisse confirmer ou infirmer mes explications
Merci en tout cas.
RE: gestion des différents prérequis - niahoo - 18-12-2015
(16-12-2015, 06:18 PM)fortz a écrit : niahoo : Merci pour ces conseils, donc selon toi je ne devrais avoir qu'une seule table "quetes" avec toutes les quetes et simplement rajouter un champ "quete_precedente" qui sera égale à l'id de l'étape précédente ou null si c'est la première étape ?
Merci pour votre aide
Ouais sauf que moi je pensais plutôt un champ quête suivante, et null si c'est la dernière quête. Mais ça revient au même, les deux se valent je pense, c'est juste une relation de une seule quête à une seule autre. Avec un champ quête suivante, une quête ne peut avoir qu'une autre quête qui la suit. Avec un champ quête précédente, tu peux avoir plusieurs quêtes qui en suivent une première, et ça c'est faux sémantiquement, car ça devient redondant avec le système de prérequis.
Par exemple, ton héros arrive dans une nouvelle zone, il doit faire une série de quêtes d'introduction, et une fois cette série terminée, plusieurs PNJ de la zone vont lui proposer des quêtes : là, c'est le système de prérequis doit être utilisé. Par contre, pour ordonner cette série de quêtes d'introduction, on va utiliser les champs quête précédente / quête suivante. Ce sont deux systèmes indépendants.
Quelques remarques ensuite :
Si on a deux quêtes, A et B qui sont reliées par cette relation quête suivante, c'est le PNJ qui termine la quête A qui doit commencer la quête B. De sorte que quand on valide la quête A, la quête B peut nous être proposée directement.
Dans la même idée, la quête B ne doit pas pouvoir être disponible si la quête A n'a pas été remplie, c'est un prérequis de facto. C'est vrai que dans ce cas précis, un champ quête précédente est plus simple, donc s'il n'y a pas d'inconvénients, le champ quête précédente peut être préféré à un champ quête suivante, en mettant une contrainte unique sur le champ quête précédente. (Alors que théoriquement, on n'est pas obligé de mettre une contrainte unique sur un champ quête suivante, on peut imaginer deux PNJ qui donnent chacun une petite quête qui vont donner suite à la même grosse quête).
Ensuite, la quête B ne doit pas avoir d'autre prérequis que la quête A. Si on a pu avoir la quête A grâce à certains prérequis, la quête B devrait pouvoir être prise dès qu'on a fini la quête A, car on gère en réalité des étapes, et non pas des quêtes distinctes. Sinon, si tu finis la quête A et que la B n'est pas disponible, le joueur ne va pas forcément penser à venir la chercher ensuite, il croira qu'il n'y a pas de suite. Alors que quand tu débloques une zone ou un nouveau bâtiment, tu peux légitimement te demander si cela ne peut pas intéresser de nouveaux PNJ. Bon, après si tu mets des gros ! au dessus de ton PNJ ça marche aussi.
Enfin, si tu veux que lors d'une quête on aie à faire un choix, qui va déterminer quelle sera la suite de la quête (genre je vais aider machin contre bidule, ou bidule contre machin) alors il te faudra gérer un arbre de quêtes, une relation précédente/suivante ne suffit plus.
RE: gestion des différents prérequis - fortz - 18-12-2015
Merci pour cette réponse Niahoo, alors sur mon système il n'y a pas cette complexité : une étape amène à une et une seule autre et une étape n'ai précédée que par une seule autre étape (qui peut elle même être précédée d'une autre hein, donc pas de croisement entre plusieurs quêtes à l'horizon). Pour ce qui est des prises de décisions, c'est finalement plutôt simple, une quête peut (ou pas) proposé un choix entre 2 types de récompenses une fois la quête finie, donc ca reste assez simple à modéliser selon moi.
Après rien ne m'empêche de vouloir un jour complexifier ce système, mais je n'y ai pas encore songé pour le moment
Merci