27-05-2013, 07:05 PM
Variante:
un système qui enregistre, pour chaque joueur, le nombre de points de vie dans la BDD, avec le timestamp donnant la date de validité de ces PV.
Dans le PHP, dans la classe "player", l'attribut "vie" est initialisé en lisant la vie dans la BDD, et en calculant la différence entre timestamp actuel et timestamp de la BDD. Cette différence est alors multipliée par la valeur de regénération, donnant la santée réelle dans l'attribut "vie" de la classe "player" pour le code PHP. Une fois ces opérations faites, le joueur est re-sauvé dans la BDD, avec le timestamp actuel et sa santé issue de l'attribut "vie" de la classe "player".
Si la BDD est de type "objet" (certains NoSQL par exemple), cela peut se simplifier en déportant tout le calcul du PHP vers la BDD elle-même.
Dans les autres cas, type MySQL, la seule délicatesse à gérer est de s'assurer que le scénario suivant ne se produit pas:
- Le script lit la BDD et instancie "player"
- La vie du joueur est calculée
- Un autre script instancie ce même joueur (un autre visiteur du jeu par exemple)
- Le 1er script fait ses traitement, et blesse le joueur (classe "player")
- Le 2nd script fait ses traitement et blesse le joueur (classe "player")
- Le 1er script sauve son résultat
- Le 2nd script sauve son résultat
Le 1er script se fera, dans ce scénario, totalement occulter.
On peut le gérer de plusieurs façons:
- L'ignorer (si les traitements sont courts, et qu'il n'y a pas énormément de joueurs, la probabilité que ce scénario apparaisse peut être faible et tolérée)
- Verrouiller la table (dur!) ou la ligne (mieux) de la BDD, mais cela ralentit le traitement
- Utiliser un système incrémental (au lieu de lire la vie dans la BDD, puis de la mettre à jour dans la classe, puis de combattre et enfin de sauver, on fait tout ca dans une seule et même requête SQL qui serait "atomique")
Cela dit, la méthode de Niahoo est parfaitement envisageable aussi. En revanche, si tu as des milliers d'enregistrements ou si ce genre de scénario se reproduit de nombreuses fois par minute ou pour de nombreuses variables, cette méthode peut vite devenir lourde.
Celle que je te propose est lourde aussi, mais sa "lourdeur" est répartie sur tous les clients (vaut-il mieux faire, dans une journée, 24*60=1440 mises à jours de toute la table de la BDD, soit une par minute, ou faire des mises à jour que lorsque cela est nécessaire?)
un système qui enregistre, pour chaque joueur, le nombre de points de vie dans la BDD, avec le timestamp donnant la date de validité de ces PV.
Dans le PHP, dans la classe "player", l'attribut "vie" est initialisé en lisant la vie dans la BDD, et en calculant la différence entre timestamp actuel et timestamp de la BDD. Cette différence est alors multipliée par la valeur de regénération, donnant la santée réelle dans l'attribut "vie" de la classe "player" pour le code PHP. Une fois ces opérations faites, le joueur est re-sauvé dans la BDD, avec le timestamp actuel et sa santé issue de l'attribut "vie" de la classe "player".
Si la BDD est de type "objet" (certains NoSQL par exemple), cela peut se simplifier en déportant tout le calcul du PHP vers la BDD elle-même.
Dans les autres cas, type MySQL, la seule délicatesse à gérer est de s'assurer que le scénario suivant ne se produit pas:
- Le script lit la BDD et instancie "player"
- La vie du joueur est calculée
- Un autre script instancie ce même joueur (un autre visiteur du jeu par exemple)
- Le 1er script fait ses traitement, et blesse le joueur (classe "player")
- Le 2nd script fait ses traitement et blesse le joueur (classe "player")
- Le 1er script sauve son résultat
- Le 2nd script sauve son résultat
Le 1er script se fera, dans ce scénario, totalement occulter.
On peut le gérer de plusieurs façons:
- L'ignorer (si les traitements sont courts, et qu'il n'y a pas énormément de joueurs, la probabilité que ce scénario apparaisse peut être faible et tolérée)
- Verrouiller la table (dur!) ou la ligne (mieux) de la BDD, mais cela ralentit le traitement
- Utiliser un système incrémental (au lieu de lire la vie dans la BDD, puis de la mettre à jour dans la classe, puis de combattre et enfin de sauver, on fait tout ca dans une seule et même requête SQL qui serait "atomique")
Cela dit, la méthode de Niahoo est parfaitement envisageable aussi. En revanche, si tu as des milliers d'enregistrements ou si ce genre de scénario se reproduit de nombreuses fois par minute ou pour de nombreuses variables, cette méthode peut vite devenir lourde.
Celle que je te propose est lourde aussi, mais sa "lourdeur" est répartie sur tous les clients (vaut-il mieux faire, dans une journée, 24*60=1440 mises à jours de toute la table de la BDD, soit une par minute, ou faire des mises à jour que lorsque cela est nécessaire?)