Système d'objectifs à remplir pour les quêtes

[Colmea]

Bonjour,

Suite à une discussion sur le chan #webgames sur la façon d'implémenter un système de conditions à remplir pour valider une quête, voici la solution qui a été retenue.
N'hésitez pas à partager votre avis sur la méthode


La (bon ok, Ma) principale question était surtout: De quelle façon structurer les tables relatives aux quêtes.
Il s'est avéré que la division du système de quête en 3 tables semblait être la meilleure solution (encore une fois, donnez votre avis):

-Une table "quest":
regroupant les infos de la quête (description, titre, etc ...)

-une table "objectives" lié à la table "quest":
qui regroupe les différents objectifs de la quête.
Chaque type d'objectif représente une colonne dans cette table (monstreATuer, ObjetAPosseder, ...)

-une table "progressions" liée à la table quest et objectives:
Stocke la progression du joueur par rapport aux différents objectifs de la quête. Une entrée dans la table correspondra donc à une entrée dans la table "objectives" qui correspond elle à une entrée dans la table "quest".

Exemple de tables:

Code PHP :

<?php 

quest:

   id

   titre

   description



objectives:

   id

   quest_id

   type

   id_monstre_a_tuer

   nombre_monstre_a_tuer

   id_objet_a_posseder

   nombre_objets_a_posseder

   niveau_requis



progressions:

   objective_id // fait référence à une entrée dans la table 'objectives'

   user_id //fait référence à un membre

   count //compte la progression .ex: "5" (sur 10 monstres à tuer) 

   accompli // booléen. si cet objectif est rempli ou non 

[genosite]

bonne idée.

[Blarg]

Chouette! J'en étais justement rendu à me creuser la tête pour implanter un système de quête...

En regardant le schéma des tableaux, j'aurais tendance à regrouper les tables «quest» et «objectives» ensemble. On obtiendrait ainsi une table décrivant la quête et les conditions pour la remplir et une deuxième table notant la progression des quêtes enclanchées.

Merci de partager!

[Kihmé]

une table quête, une table objectif avec un attribut poids (un entier pour mettre une valeur d'importance pour traduire un pourcentage d'accomplissement) reliée à quête en 1,n. Une table joueur reliée en n, n à objectif avec un bouléen à true ou alors la simple présence de la relation marque l'accomplissement donc plus besoin de l'attribue boulean.

Après libre à vous de mettre un système de contrainte pour vérifier que la quête et les objéctifs sont bels et bien accéssible au joueur. (sécurité interne à la bdd)

[Sephi-Chan]

Voici la transcription de la discussion. Ça vient d'IRC donc c'est un peu pollué, mais ça donne une idée.

En regardant le schéma des tableaux, j'aurais tendance à regrouper les tables «quest» et «objectives» ensemble. On obtiendrait ainsi une table décrivant la quête et les conditions pour la remplir et une deuxième table notant la progression des quêtes enclanchées.

Oui, on peut aplatir cette proposition puisqu'ici, le modèle Quest n'est qu'un conteneur d'objectifs. Je trouve que c'est mieux ainsi puisqu'on peut alors faire des quêtes plus élaborées.


Sephi-Chan

[NicoMSEvent]

Pour ma part, j'ai fait a peu près comme ça (3 tables -> Quetes / Objectifs / Progression), j'ai ai même rajouté une 4eme, avec les quetes requises pour pouvoir accéder a la quete en cours (par exemple, il faut avoir telle et telle quete, mais surtout pas celle là si on veut lancer cette quete ci)

Cette table a ce format chez moi :
QueteEnCoursID , QuetesRequiseID, FlagRequis/Interdit

Note a part :
Dans ma table objectifs, il y a certains objectifs qui provoquent l'échec de la quete
Les quetes ont un flag "répétable" pour éventuellement pouvoir les faire plusieurs fois

[Argorate]

Sephi: peut pas dl ton pdf

Unauthorized partial download

Pour ce qui est de la table des objectifs, je me demande comment on fait quand ça se complexifie? Car en l'occurrence "nombre de monstre a tuer/objet a posséder" c'est pour des quêtes assez basique...
On va pas rajouter des champs pour chaque type d'objectif non? ne vaudrait-il mieux pas faire une table objectifs {id_quete, type_objectif} et une autre table qui définira le type en question?

[Sephi-Chan]

Je verrais pour la pièce jointe. Je suis dans le train.
Edit : j'y accède très bien… Peut-être parce que je suis admin… :heuuu:

Concernant les colonnes, qu'est ce qui ne va pas avec la multiplication des colonnes ?
Ça permet de faire de l'héritage de table (grâce à la colonne type qui contient la classe qui modélise l'objectif (avec ses propres méthodes, donc). Et puis, des champs à NULL, ça ne coûte rien.


Sephi-Chan

[Argorate]

Personnellement je n'aime pas trop les tables avec des NULL, ça attire des ennuis pour les requêtes.
D'autre part je trouve ça assez lourd de devoir allez modifier la structure de la table dès qu'on invente une quête avec de nouveaux objectifs

[Anthor]

Personnellement je n'aime pas trop les tables avec des NULL, ça attire des ennuis pour les requêtes.

Si tu attires les ennuis, ca ne veut pas dire que c'est mauvais...
Remise en question apprentissage, tout ça...

Une requête bien écrite n'a jamais posé de problème.