Système de quêtes et comment les vérifier ?

[GeGe_KAT]

Si à chaque page tu dois tester l'histoire de tes quêtes périmées et que tu les lis en session ça sera plus lent que si tu les lis depuis la base de données. Car la lecture de la session induit une désérialisation depuis un fichier.

Ben cette opération est déjà faite de toutes façons (pour récupérer les autres infos de session pseudo / partie / etc)... Et ce, que tu compares tes value avec des données en base ou en session. Donc y'a pas vraiment de surcout à ce niveau là, je pense.

Mais je suis daccord aves ta dernière phrase, en tous cas. Je pense que je vais pas me prendre la tête et faire les requètes à chaque coup.

[niahoo]

Oui mais si en session tu ne stockes que l'ID user et que tu récupères le reste ailleurs ça sera mieux. D'autant plus que sur une page où tu n'as besoin que du login, toute ta session va être désérialisée (contenant toutes les infos des quêtes) afin de pouvoir lire ce login.

Il y a bien un surcoût : la taille de ta session influe directement sur le temps d'extraction des données.

[Xenos]

... mais seuls des tests sur la plateforme réelle diront si ce surcout dépasse le cout d'une requête SQL.
On pourrait imaginer que le fichier des session est sur un SDD ou un RAMDisk. En ce cas, stocker dans la session sera probablement plus rapide qu'établir une connexion à mysql (si elle n'est pas déjà établie), puis lire les données, puis les traiter, puis fermer la connexion.

[php_addict]

- Les seuils des quêtes (points pour gagner la quête) seront des variables dans une classe php (pas de SQL, ni de define)

par contre je ne sais pas du tout où stocker si le joueur a remplit les quêtes 1, 2, et 5 par exemple: Dans une table 'quetes_resolues' ? ca vaut certainement mieux que des champs quete1 quete2 quete3 dans la table 'joueurs' j'imagine...

y aura peut etre un flag dans le table 'joueurs' du genre un booléan 'nouvelle_quete_resolue' pour avertir le joueur..

non ?

[Xenos]

Oui, je stockerai les quêtes résolues dans une table type "idJoueur, idQuete, dateDebut, dateFin,...<autres stats>" (et les seuils dans un fichier de constantes).
Si un joueur ne peut finir une quête qu'une fois, une clef primaire sur la paire d'id sera certainement intéressante.
L'ajout de nouvelles quêtes sera d'ailleurs facilité (je suppose que plein de nouvelles quêtes s'ajouteront peu à peu).

En revanche, si la table des quêtes résolues stocke la date de fin de quête (cette table pourrait d'ailleurs ajouter un flag BIT(1) indiquant si la quête est réussie ou échouée), j'utiliserai la date de dernière visite du joueur (en BDD ou en session, voire les deux) pour piocher les quêtes résolues.
Après, si tu veux pas faire cette "pioche" trop souvent, tu peux ajouter une date dans la session indiquant le dernier "contrôle" ainsi effectué, et ne refaire un contrôle des quêtes résolues que toutes les 5 minutes (ou toutes les heures).

[niahoo]

... mais seuls des tests sur la plateforme réelle diront si ce surcout dépasse le cout d'une requête SQL.
On pourrait imaginer que le fichier des session est sur un SDD ou un RAMDisk. En ce cas, stocker dans la session sera probablement plus rapide qu'établir une connexion à mysql (si elle n'est pas déjà établie), puis lire les données, puis les traiter, puis fermer la connexion.

J'ai suggéré d'utiliser mySQL avec des tables RAM, je crois que c'est plus rapide puisque on de désérialise pas mais il est possible que je raconte n'importe quoi en effet.

par contre je ne sais pas du tout où stocker si le joueur a remplit les quêtes 1, 2, et 5 par exemple: Dans une table 'quetes_resolues' ? ca vaut certainement mieux que des champs quete1 quete2 quete3 dans la table 'joueurs' j'imagine...

y aura peut etre un flag dans le table 'joueurs' du genre un booléan 'nouvelle_quete_resolue' pour avertir le joueur..

Comme le suggère Xenos, une table indiquant les quêtes actives/terminées du joueur avec un champ indiquant la date à laquelle la quête à été complétée. Ainsi, si le champ n'est pas null, la quête est terminée.

Je rajouterais un champ vu : quand tu affiches la page à ton joueur tu lui affiche un genre de pop-up indiquant que la quête est finie avec les récompenses, les gains d'XP ou de réput, etc. Une fois qu'il clique sur "OK" tu viens remplir ce champ vu par true afin de ne plus mettre la popup au joueur pour cette quête.

Après, si tu veux pas faire cette "pioche" trop souvent, tu peux ajouter une date dans la session indiquant le dernier "contrôle" ainsi effectué, et ne refaire un contrôle des quêtes résolues que toutes les 5 minutes (ou toutes les heures).

Comme je le disais, mieux vaut commencer par faire un truc qui fonctionne, puis de passer à la suite afin d'avoir un prototype jouable le plus rapidement possible. Ensuite seulement chercher à optimiser.

---

d'autant plus que quand un joueur fait une action qui termine une quête il s'attend a avoir le résultat de suite, pas 5 min plus tard.

[Ter Rowan]

d'autant plus que quand un joueur fait une action qui termine une quête il s'attend a avoir le résultat de suite, pas 5 min plus tard.

c'est clair, ça doit être du "synchrone" (ou presque) ce genre de message

[Argorate]

Oui, je stockerai les quêtes résolues dans une table type "idJoueur, idQuete, dateDebut, dateFin,...<autres stats>" (et les seuils dans un fichier de constantes).
Si un joueur ne peut finir une quête qu'une fois, une clef primaire sur la paire d'id sera certainement intéressante.
L'ajout de nouvelles quêtes sera d'ailleurs facilité (je suppose que plein de nouvelles quêtes s'ajouteront peu à peu).

En revanche, si la table des quêtes résolues stocke la date de fin de quête (cette table pourrait d'ailleurs ajouter un flag BIT(1) indiquant si la quête est réussie ou échouée), j'utiliserai la date de dernière visite du joueur (en BDD ou en session, voire les deux) pour piocher les quêtes résolues.
Après, si tu veux pas faire cette "pioche" trop souvent, tu peux ajouter une date dans la session indiquant le dernier "contrôle" ainsi effectué, et ne refaire un contrôle des quêtes résolues que toutes les 5 minutes (ou toutes les heures).

C'est assez simple niveau conception:

comme pour toutes les tables de ce genre, tu dois avoir 2 tables, une pour les modèles, l'autre pour les instances:

QuestType qui représente les quetes, leurs objectifs et toutes les données qui sont commune à tous, et une table Quest qui elle représente les instances pour un joueur d'un QuestType, où dedans tu as une date de début et de fin, et savoir si une quest est fini revient à demander si la date de fin est NULL ou pas...

bon courage.

[Xenos]

Comme je le disais, mieux vaut commencer par faire un truc qui fonctionne, puis de passer à la suite afin d'avoir un prototype jouable le plus rapidement possible. Ensuite seulement chercher à optimiser.

D'où mon "Après" :p J'avais tendance à sur-optimiser trop tôt aussi, j'ai changé de tactique pour sortir d'abord, optimiser ensuite.

Quand je dis "toutes les 5 minutes un contrôle", cela n'exclus pas de faire un contrôle quand un évènement survient Par là j'entends "quand un évènement pouvant terminer une quête apparait, contrôler si ces quêtes sont terminées" + "ajouter un contrôle de toutes les quêtes toutes les 5 minutes" (ou autre unité de temps). c'est comme se dire que le temps qui passe (5 minutes) est un évènement pouvant terminer les quêtes, qui doit donc entrainer un contrôle pour vérifier les quêtes terminées.
J'utilise également ce procédé sur eclerd: mettre à jour (dans mon cas une image, ici, une table sql) lorsqu'une action survient, mais également toutes les N unités de temps; l'écoulement d'une unité de temps peut être considéré comme une "action".

Pour "QuestType", j'aurai mis ça dans une classe de constantes, dans un fichier PHP. Si ce sont des données très statiques (changent peu, sauf quand on mets le jeu à jour pour ajouter une quête) et souvent accédées, je préfère éviter d'encombrer la BDD. Seul inconvénient: on ne peut pas faire de jointure directement...

[php_addict]

merci pour vos avis

Pour "QuestType", j'aurai mis ça dans une classe de constantes, dans un fichier PHP. Si ce sont des données très statiques (changent peu, sauf quand on mets le jeu à jour pour ajouter une quête) et souvent accédées, je préfère éviter d'encombrer la BDD. Seul inconvénient: on ne peut pas faire de jointure directement...

effectivement en base de donnée c'est lourdingue pour des données qui ne changeraont que très peu, mais plus facile à manipuler pour les croisements de données

je penche pour un stockage en base de donnée, avec un cache en mémoire vive avec APC