24-06-2016, 09:41 AM
Salut,
Une table "quest" comme indiquée
Une table "quest_step (id, id_quest, step_index, fullfilled [bool])" + foreign key id_quest -> quest.id et primary key [auto_increment] (id_quest, step_index) pour pouvoir ordonner les étapes de quêtes et fullfilled histoire de savoir où on en est (je n'ai pas mis de contrainte sur l'ordre des fullfill, on peut faire des "trous" donc: charge à ton système d'insert/update dans la BDD de faire les checks si tu veux, ou charge à toi de poser le TRIGGER adéquate)
N tables d'objectifs, un par type (quest_objective_kill, quest_objective_find,...) car je suis contre les tables hyper-génériques avec des paquets de colonnes à NULL. Chacune de ces tables peut alors avoir une foreign key quest_objective_*.id_quest_step -> quest_step.id. Charge à toi là encore de voir si deux tables quest_objective_* peuvent référence le même quest_step (mais ce serait étrange), ou s'il te faut mettre des checks pour éviter cela.
Perso, je ne ferai pas de "progression" qui traine: je pense qu'il vaut mieux avoir 6 entrées dans "quest_objective_kill" pour tuer 1 sanglier, puis 1 autre, puis 1 autre etc plutôt que des objectifs qui se remplissent partiellement (et charge à ton affichage de faire le grouping). Après, tu peux mettre du progress avec une colonne "objective_total_count" et "objective_achieved_count" dabs quest_step: le total indique combien de fois cet objectif (donné par le quest_objective_* correspondant) doit être rempli, et le achieved_count indique le nombre de fois où cet objectif a été rempli. Les deux structures se valent, mais j'aime mieux la 1ere car elle limite les types de données à traiter.
Une table "quest" comme indiquée
Une table "quest_step (id, id_quest, step_index, fullfilled [bool])" + foreign key id_quest -> quest.id et primary key [auto_increment] (id_quest, step_index) pour pouvoir ordonner les étapes de quêtes et fullfilled histoire de savoir où on en est (je n'ai pas mis de contrainte sur l'ordre des fullfill, on peut faire des "trous" donc: charge à ton système d'insert/update dans la BDD de faire les checks si tu veux, ou charge à toi de poser le TRIGGER adéquate)
N tables d'objectifs, un par type (quest_objective_kill, quest_objective_find,...) car je suis contre les tables hyper-génériques avec des paquets de colonnes à NULL. Chacune de ces tables peut alors avoir une foreign key quest_objective_*.id_quest_step -> quest_step.id. Charge à toi là encore de voir si deux tables quest_objective_* peuvent référence le même quest_step (mais ce serait étrange), ou s'il te faut mettre des checks pour éviter cela.
Perso, je ne ferai pas de "progression" qui traine: je pense qu'il vaut mieux avoir 6 entrées dans "quest_objective_kill" pour tuer 1 sanglier, puis 1 autre, puis 1 autre etc plutôt que des objectifs qui se remplissent partiellement (et charge à ton affichage de faire le grouping). Après, tu peux mettre du progress avec une colonne "objective_total_count" et "objective_achieved_count" dabs quest_step: le total indique combien de fois cet objectif (donné par le quest_objective_* correspondant) doit être rempli, et le achieved_count indique le nombre de fois où cet objectif a été rempli. Les deux structures se valent, mais j'aime mieux la 1ere car elle limite les types de données à traiter.