Comment stocker des améliorations basées sur la valeur calculée de deux nombres ?

[Maz]

Salut, petite question du jour, plusieurs réponses possibles, pas forcément de mauvaises réponses:

Si vous deviez stocké pour chaque utilisateur des améliorations (+ de 20) calculés à pour chaque à partir de 2 nombres : genre un par rapport au niveau d'un bâtiment, l'autre par rapport au stats du joueur, son niveau entre guillemets.

Vous ne souhaitez pas stocké uniquement la valeur calculé pour garder une trace, question de gameplay.

En base de données vous stockeriez:
1./ Sur une seul table avec un champs au format json avec les deux nombres pour chaque.
2./ Sur deux champs deux la même table pour chaque aeliorations.
3./ Sur deux tables différentes avec des noms de champs identiques.


Pour donner un exemple concret puisque ma question te semble ambiguë, disons qu'un joueur au démarrage à le droit à 50 unités maximum.

En réalisant certaines quêtes, il augmente ce niveau donc niveau de base + amélioration lié au niveau(disons +20 au niveau 3 du joueur).

Aussi grâce à des améliorations de ses bâtiments, il peut augmenter cette limite.

Ce sont ces deux chiffres pour lesquels je pose la question. Ils sont utilisés pour calculer la même chose: le nombre max d'unité possible. Mais la contraintes lié au game design est de conserver indépendamment ces deux chiffres pour les afficher par exemple dans le tableau de bord du joueur:

Unités maximum : 70 à votre niveau(+bonus de 20 grâce à votre bâtiment amélioré)

Sachant qu'il existera à terme plus d'une vingtaine de ces variables d'amélioration.

La discussion est ouverte

Edit que quelqu'un me corrige cette faute de français monumentale! Sinon ça va troller à juste titre sur ma gueule c'est sûr ! Et je peux pas modifier les questions du sondage

[L'Omniscient]

Ah attend, j'ai mal voté :p Je pensais que tu voulais tout mettre dans un même champs en format JSON, ce que je trouvais plus facilement manipulable.
Si tu veux quand même que chaque amélioration ait au moins un champs, je partirais sur deux tables différentes (bon perso je ne mettrais pas des noms identiques ça peut embrouiller, un petit Old New dans les titres ça peut aider ^^ )
En terme de lisibilité une table avec beaucoup de champs c'est pas très pratique je trouve.

(Je n'aime pas l'idée du JSON dans chaque champs parce que ça me parait nécessiter trop de manipulations à chaque appel des données).

[Maz]

Pour donner un exemple concret puisque ma question te semble ambiguë, disons qu'un joueur au démarrage à le droit à 50 unités maximum.

En réalisant certaines quêtes, il augmente ce niveau donc niveau de base + amélioration lié au niveau(disons +20 au niveau 3 du joueur).

Aussi grâce à des améliorations de ses bâtiments, il peut augmenter cette limite.

Ce sont ces deux chiffres pour lesquels je pose la question. Ils sont utilisés pour calculer la même chose: le nombre max d'unité possible. Mais la contraintes lié au game design est de conserver indépendamment ces deux chiffres pour les afficher par exemple dans le tableau de bord du joueur:

Unités maximum : 70 à votre niveau(+bonus de 20 grâce à votre bâtiment amélioré)

Sachant qu'il existera à terme plus d'une vingtaine de ces variables d'amélioration.

Pour ta note au sujet du traitement du json. Il est très aisé de transformer ce json en objet et ensuite de l'utiliser avec quelque chose du genre(maximum_unities étant le n du champs):

$maximums_unities =(object)$requete['maximum_unities']
$maximum_unities->buildings
$maximum_unities->level

[Xenos]

Salut,
pour moi, ça ne doit aps être stocké en JSON (sinon, autant ne pas faire de BDD relationnelle): tu dois avoir 3 colonnes dans une table soit "player" (qui a directement les infos du compte), soit éventuellement "player_game_stats" dans laquelle se trouve toutes les stats de jeu du compte (histoire de l'isoler des infos du compte comme l'email/pseudo/etc).

De plus, sur mon archi de jeu habituelle, j'ai tendance à nommer les champs "calculés" sous la forme "cp_*". Cela me permettra, quand mysql 8 sera utilisé chez OVH pour le mutualisé (ou quand je basculerai dessus car je crois que mysql8 est déjà dispo chez eux), de remplacer ces colonnes "cp_*" par des "VIRTUAL COLUMNS", c'est à dire des colonnes calculées & stockées dans la DB

Donc, dans mon cas, je ferai:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0
- cp_actual_units_limit INT UNSIGNED DEFAULT 0

& soit un TRIGGER "AFTER UPDATE" sur player_game_stats qui met à jour le cp_*, soit une procédure stockée (c'est ma solution usuelle) compute_player_stats qui recalcule cette table (UPDATE player_game_stats SET cp_actual_units_limit = 20 * gamelevel + units_count_bonus). L'avantage de cette procédure est de permettre un recalcul de cp_actual_units_limit si je change les règles du jeu. Genre, si je passe de *20 à *30, quand je déploie, j'exécute cette procédure stockée pour tous les joueurs et tout le monde récupère la nouvelle règle du jeu.

On pourrait utiliser une vue également, c'est une alternative possible. Je le fais dans le cas où le compute est trop récurrent, ou quand la donnée change de manière temporelle (genre si le nb d'unités était augmenté de 1 chaque heure), car là, impossible de faire un "compute" proprement (on peut faire un EVENT SQL, pour un truc qui se passe chaque heure, ca va, mais si c'est chaque seconde comme les distances entre les astres dans variispace, alors ça n'a pas d'intérêt).

Dans le cas d'une vue, cela ferait:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0

VIEW computed_player_game_stats AS
SELECT id_player, 20 * gamelevel + units_count_bonus AS actual_units_limit
FROM player_game_stats

Je devrais d'ailleurs un peu plus systèmatiser cette approche... J'ai parfois tendance à oublier d'exécuter le "compute_player_stats" quand je touche au gamelevel ou au units_count_bonus. L'inconvénient, c'est que ce sera moins facile de migrer vers des VIRTUAL COLUMNS, puisque la VIEW n'a pas le même nom que la table... D'où le fait que je reste quand même sur la 1ere approche.

Je ne trouve pas d'option dans le sondage représentant cette approche "3 colonnes (2 data de base + data calculée)". Donc, je n'ai pas voté

[niahoo]

Je ne stockerais pas ça.

[Sephi-Chan]

Maz, puisque tu utilises Postgres - qui dispose aussi de ces colonnes virtuelles - ça peut être très intéressant dans ton cas.

Sinon, je calculerais ça dynamiquement quand j'en ai besoin : c'est le meilleur moyen d'être simple et toujours à jour, et tu stockera ça quand tu en auras besoin. EDIT : grillé par Niahoo. :p

[Maz]

J'aurais du mettre 15 options au forum ;P

Ne pas stocker et calculer est un peu contraignant je trouve: il faudrait créer un getter à un endroit pour être sûr de ne pas dupliquer le calcul avec les risques d'erreur lié à ça. Et ok pour un calcul basique genre si 1niveau = 10 unité.

Mais je préfère la technique Xenos pour que tout soit calculé au même endroit et notamment à la source. D'autant que maintenant que j'ai découvert ça, il faut que je l'essaie !

[Sephi-Chan]

Parce que ton approche est bizarre : si tu viens demander de l'aide, c'est que tu as un problème, donc mieux vaut exposer le problème est entendre des solutions que d'arriver avec déjà tes solutions.

[niahoo]

Bien sûr qu'il faut un getter. Tu en auras un pour ton champ de toutes façons.

[Maz]

@Sephi-Chan honnêtement j'avais déjà "une solution", pour dire vrai j'ai voté JSON lol

Mais je ne cherchais pas une solution, c'était plus de la curiosité qui je l'espérais et ça a été le cas, profiteras à d'autres je l'espère.

En tout cas ça me servira à moi ici. Même si j'avais une solution qui en pratique était tout à fait fonctionnelle, ce n'était pas la meilleure. Et je suis bien le premier à apprendre des autres à livre ouvert