Encore et toujours, gestion des ressources

[niahoo]

Oui, ne pas compter sur les connexions du joueur pour gérer quelque chose qui est indépendant du fait qu'il soit connecté ou non ! Cela me semble évident

[pollop]

J'ai modifié mon message précédant car je pense qu'il n'était pas très clair

Merci

[niahoo]

Non,

ton message était très clair, et le mien aussi je pense. Tu comptes sur la connection du joueur pour mettre à jour ses ressources, alors que celles-ci sont censées augmenter même si le joueur ne se connecte pas.

Si un jour tu as besoin de connaitre les ressources d'un joueur alors que celui-ci ne s'est pas connecté depuis une semaine, tes données seront complètement fausses.

C'est pourquoi je pense que c'est une mauvaise approche.

Essaie plutôt de voir comment tu ferais dans le cas que j'ai cité pour connaitre les ressources, il te suffit alors de le refaire toutes les x minutes.

[php_addict]

je comprends pas ton probleme...

si le joueur avait 1000 resources il y a 20 minutes et qu'il en produit 1 ressource par minute alors il a 1000 + 20*1 ressources...et tu n'est meme pas obligé de faire un UPDATE de ta base de données, il te faut simplement une fonction qui calcul le nb de ressources...

c'est tout bête non ? apres évidement tu doit faire un UPDATE de temps en temps, genre à la connexion du joueur (pas obligé), ou quand il se fait attaquer ou quand il construit quelque chose, ou quand il depense des ressources (obligé), etc...à toi de voir en fonction du jeu...

[pollop]

Merci de vous intéresser à mon problème

Mais je ne pense pas que nous parlions du même problème

Tout d'abords, le choix de mettre les ressources à jour de façon sélective par rapport à une gestion via des cron job est déjà pris !
Le rapport avantages/inconvénients favorise plus que grandement la première approche.

Pour niahoo, la mise à jour des ressources n'est pas faite à la connexion du joueur !
Elle est faite dès qu'on en a besoin !
Donc à chaque fois que le joueur va sur une nouvelle page, on calcule les nouvelles ressources.
Mais pas seulement ! i.e. si le joueur est attaqué alors qu'il n'a pas été sur le jeu depuis 2mois et bien ses ressources seront mise à jour avant d'exécuter l'attaque.

Ma question portait simplement sur la façon de stoquer les ressources dans la base de donnée.
Imaginons que dans mon jeu, les ressources sont des nombres entiers. Car, par exemple, avoir 0,66 unité n'a pas de sens.
J'ai donc naturellement envie de les stoquer sous forme d'entier non signé (BIGINT UNSIGNED) dans ma base de donnée. Ça a pour avantage de pouvoir stoquer des nombres très grand !

Je vous rappelle l'algorithme pour que vous compreniez bien la suite.
Dans la BDD, on garde le nombre d'unité de chaque ressource que possède le joueur.
En plus, on garde la date de la dernière mise à jour de ces dernières.

Petit exemple:
BDD
Ressource: 800
LastUpdate: 2010-02-06 12:00:00

Le joueur arrive sur une page à 2010-02-06 13:00:00, on récupère les données dans la BDD et on calcule le temps qui s'est écoulé depuis la dernière mise à jour (Ici 1h).
Si sa production est de 50 unités par heure, on va mettre à jour la BDD de cette façon :

BDD
Ressource: 850
LastUpdate: 2010-02-06 13:00:00

Mais avec cette approche (ressources sous forme de nombre entier), un problème surviens.
Imaginons que la production du joueur est de 3 unités par heure, donc de 0.05 unité par minute.

Le joueur arrive sur une page, la BDD est comme suit:
BDD
Ressource: 800
LastUpdate: 2010-02-06 12:55:00

Il est maintenant 13h, on calcule la différence: 5 minutes. Ce qui correspond à 0.25 unité produite ! Si on calcule en entier, ça correspond à 0 unité supplémentaire, la BDD sera donc mise à jour de la façon suivante :

BDD
Ressource: 800
LastUpdate: 2010-02-06 13:00:00

Le problème est que si je joueur se promène sur le site à raison de 1 page toutes les 5 minutes, seul le champ LastUpdate sera mis à jour et ses ressources n'augmenteront jamais !!

Une solution serait de stoquer les ressources en float, après 5 minutes la BDD serait alors :
BDD
Ressource: 800.25
LastUpdate: 2010-02-06 13:00:00

Mais cette solution ne me plait pas trop
Tout d'abord parce qu'elle a un range de valeur possible fort inférieur aux entiers... Mais également car sémantiquement, 0.5 unité n'a pas de sens dans mon jeu.

Je me demandais donc si vous voyiez une autre solution

Un grand merci d'avance

[Horace]

Stocker dans la BD le reste de la division ? $modulo = $ressource % $coef
Tu multiplies par 100 puis arrondi, pour stocker comme un INT. (ça fait 2 chiffres après virgule suffisant pour augmenter toutes les secondes).

Et/ou tu bloques le nouveau calcul si NOW - LastUpdate < X minutes

Idée du réveil...

[php_addict]

La solution de Horace est intéressante et astucieuse

FLOAT: A small (single-precision) floating-point number. Cannot be unsigned

Ranges are –3.402823466E+38 to –1.175494351E-38, 0 and 1.175494351E-38 to 3.402823466E+38
. If the number of Decimals is not set or <= 24 it is a single-precision floating point number

ca laisse quand même de la marge non :omg: ?

si ton soucis n'est que celui de la limitation du FLOAT par rapport au BIGINT faut se poser la question de combien tes joueurs peuvent avoir de ressources au maximum...

personnellement j'ai opté pour le FLOAT avec 2 décimales

[pollop]

Merci pour vos réponses

Je ne savais pas que le range de valeur des FLOAT était si grand
C'est vrais que ça n'est plus un problème du coup
(Pour info : BIGINT UNSIGNED : de 0 à 18,446,744,073,709,551,615 )

Par contre un gros problème des virgules flottantes c'est que ce n'est pas de l’arithmétique exacte :/
C'est à dire que un joueur qui est connecté 24h/24 et navigue de page en page toutes les secondes ne verra pas ses ressources augmenter de la même façon qu'un joueur naviguant sur la site à raison de 1 page par semaine... (Bon, d'un point de vue théorique, je vous l'accorde)
MYSQL précise quand même que le range de valeur possible ainsi que la précision, dépend du hardware !
Ce qui n'est pas le cas des entiers.

Sinon, Horace, ta solution du modulo est très séduisante ! J'aime beaucoup !

Voici comment je l'ai compris:

Dans la BDD:
ressource: Le nombre de ressources dont dispose le joueur.
seconds_ignored: Le nombre de secondes qui n'ont pas encore été comptabilisées.
lastUpdate: La date et heure de la dernière mise à jour.

Petit exemple !
La production est de 360 unités/heure. Donc de 0.1 unité par secondes.
Il faut donc 10 secondes / unité

On commence avec :
ressource: 0
seconds_ignored: 0
lastUpdate: 2011-02-06 12:00:00

Le joueur retourne sur la page après 5 secondes
On calcule
Gain = Floor( (TimeElapsed + SecondsIgnored) / SecondsByUnit )
Gain = Floor( (5+0) / 10) = 0
Modulo = (5+0) % 10 = 5

On a donc
ressource: 0
seconds_ignored: 5
lastUpdate: 2011-02-06 12:00:05

La joueur retourne sur la page après 8 secondes
Gain = Floor( (8+5) / 10) = 1
Modulo = (8+5) % 10 = 3

On a donc
ressource: 1
seconds_ignored: 3
lastUpdate: 2011-02-06 12:00:13

Ce qui est génial, c'est que si le coefficient change, ça ne pose aucun problème sur les valeurs stoquées dans la BDD.
De plus, avec cette technique, aucune seconde n'est ignorée ! Et si j'ai rien zappé, que le membre déclenche des updates toutes les secondes ou une fois par mois, il y aura aucune différence.

Petit bémol toutefois, il faut pour chaque ressources garder un champ supplémentaire dans la BDD. Celui du nombre de secondes ignorées.

J'ai bien tout compris ? Qu'en pensez vous ?

[Horace]

@pollop : oui, avec le modulo, tu ne perds aucune seconde*, mais ça t'ajoute un champ dans la BDD.

* Enfin, faudrait travailler avec des microsecondes pour ne perdre aucune seconde sur 24 heures.

[php_addict]

Par contre un gros problème des virgules flottantes c'est que ce n'est pas de l’arithmétique exacte :/
C'est à dire que un joueur qui est connecté 24h/24 et navigue de page en page toutes les secondes ne verra pas ses ressources augmenter de la même façon qu'un joueur naviguant sur la site à raison de 1 page par semaine... (Bon, d'un point de vue théorique, je vous l'accorde)

tu ne compte pas faire un UPDATE des ressources toutes les secondes quand même? tu fais des UPDATE que quand nécessaire, donc pas de problème...non ??