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

[php_addict]

Après un long long long moment d'absence sur JeuWeb.org...


Bonjour à tous!

Il faut que je réalise un système de quête à réaliser pour un jeu du type WarGame, et je ne sais pas du tout comment m'y prendre:

exemple de quête: Tuer 10.000 ennemis, brûler un village, etc...

- Pour la réalisation des quêtes en elles mêmes pas de problème...

- Par contre, c'est pour le côté structurel et le système de vérification des quêtes que je bute...


Il faut qu'à chaque instant, à chaque chargement de page, à chaque résolution d'action (attaque, défense, etc...) je vérifie si une quête à été accomplie, cela fait de très lourdes vérifications pour le serveur, car il risque d'avoir au minimum 20 quêtes et j'espère à terme 100 quêtes.

L'idéal est que le joueur soit averti instantanément quand une quête est réalisée, et pas une heure à près...

Donc se pose la question de "comment est ce que je vérifie si les quêtes des joueurs ont été accomplies sans plomber le serveur comme une grosse merde..."


niveau structurel, j'imagine bien une table à part recensent les quêtes accomplies par le joueurs, cela dépendra de mon système de vérification des quêtes accomplies...

Une idée lumineuse, Ô créateurs de jeux web ?

Merci de m'avoir lu

Have Fun
Be happy !

[niahoo]

Ben quand un joueur bute un mob de type X, tu vérifies s'il a une quête en cours demandant de tuer des X et si oui, tu incrémentes un compteur lié à cette quête pour le joueur. Quand il bute son 10 000 ième mec le compteur atteint le maximum et tu sais instantanément que la quête est finie.

non ?

[Xenos]

Mais si la quête fait intervenir le temps, comme par exemple "Planter 100 ha de blé avant 19:00:00"? Okay, à chaque ha de blé planté, on vérifie si la quête est réussie, mais pour savoir si elle échoue, il y aurait-il mieux que de faire un "SELECT ... WHERE `queteFinie`=FALSE AND `dateFin`<NOW()" à chaque chargement de page?

[php_addict]

Niahoo, oui ok sur le principe, mais j'ai bien peur que cela soit bien lourd pour le serveur que de checker à chaque fin d'action, je vais essayer, c'est de toute façon la seule façon synchrone...

[niahoo]

@Xenos pour moi le problème est bien de réfléchir en termes de "action = chargement de page". La plupart des difficultés viennent de là.

[GeGe_KAT]

J'ai exactement le même soucis ! Je vois

Je ne fais que la mise à jour du "hauts-fait / quète" à chaque nouvel évenement sans ensuite tester si la nouvelle valeur dépasse le seuil (car il faut récupérer tous les seuils pour cette quète et comparer etc, c'est lourd de le faire à chaque action, comme tu dis...). J'ai une fonction du style update_haut_fait($id_haut_fait, $login, $valeur_a_ajouter) qui fait le taf de mettre à jour chaque évènement (du même type que tes exemples). Mais elle ne fait qu'un UDAPTE, pas de vérif des seuils car lourd justement...

Ce que je m'étais dis (que je n'ai pas encore fait) : au démarrage de la partie (ou équivalent), c'est peut-être envisageable de charger en session tous les fameux seuils en tableau (10.000 ennemis, etc) et donc de faire les comparaisons sans requète. Cette vérif peut être faite dans la fonction de maj ci-dessus et éviterait les requètes à tout va...

[niahoo]

Par défaut la session est enregistrée dans des fichiers. Ce n'est pas plus rapide que d'utiliser la base de données. Ce que vous appelez "lourd" c'est une opération qui prend quelques millisecondes. Vous devriez commencer par faire comme ça, même si c'est lourd. Ensuite, si vraiiiment vous sentez que ça rame, que vous faites vos mesures et que vous constatez que la lenteur vient bien de là, vous pourrez optimiser avec du cache ou des requêtes SQL plus costaud.

Mais je parie que ce ne sera pas le cas.

[Xenos]

D'accord avec niahoo, à un détail près. Sur ma structure, certaines pages PHP ne requièrent pas de connexion à MySQL, mais chargent la session de l'utilisateur. Si je dois tester à chaque page l'histoire des quêtes "périmées", alors il faut que j'ouvre une connexion à la BDD à chaque page. Si je stocke en session, je n'ai pas ce problème (qui joue sur les perf' mais aussi sur le nombre de connexions à la BDD qui peut être limitée par l'hébergeur).

Ces "quelques ms" peuvent finir par peser lourd, à la seule condition d'avoir des pages nombreuses et chacune très rapide.



Après, oui, si la connexion est déjà établie, je te rejoins niahoo: il sera temps de se poser des problèmes d'optimisation aussi poussés que cela quand le jeu sera vraiment rentable financièrement (ce qui, d'ailleurs ouvre la solution du "ajouter de la puissance machine").

[GeGe_KAT]

Ben les sessions ont beau être stockées dans un fichier, on ne fait pas un accès au fichier à chaque utilisation d'une variable de session (les datas sont chargées au démarrage du script, à priori). Alors que dans le cas d'une requète, on fait bien un accès supplémentaire pour chaque requète, ce qui est beaucoup plus couteux (surtout si on fait deux requètes qui accèdent à deux pages différentes du disque).
Dans notre cas, si on veut déterminer si on dépasse le seuil, il faut deux requètes SELECT de plus (une pour connaitre la valeur actuel du "compteur d'ennemis tués par le joueur" et une pour récupérer tous les seuils de cette quête) au lieu de faire juste un UPDATE et une comparaison avec la variable de session (qui sera de toute façon lue).

Il y a une différence, je pense que c'est ça qu'il veut éviter.

Mais en tous cas, je note que vous pensez qu'on se bat pour couper un cheveu en deux et qu'il faut pas se prendre la tête avec ça et le faire tel que vous le dites. Je testerais.

[niahoo]

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.

Dans ce cas le plus optimisé est d'utiliser des tables MEMORY (pour mysql) pour gérer les session PHP.

En tout cas, il faut vérfier et mesurer par soi même. Peut-être que je me trompe et que la session et 10 000 000 fois plus rapide. Mais ça ne sert à rien de chercher à coder des trucs compliqués pour "ne pas faire une requête car c'est lourd" alors qu'on n'a aucune idée des ressources mobilisées dans un cas ou l'autre.