Propriétés d'un objet: stockage ou calcul à la volée?

[Xenos]

Salut,

j'ai une question d'ordre "préférence personnelle", mais je serai curieux d'avoir quelques points de vue dessus.

Dans VariiSpace, les joueurs peuvent concevoir leurs vaisseaux. Chaque plan de vaisseau aura donc des "propriétés" (sommairement, on va simplifier avec des PV, une masse, une vitesse max, et une puissance de feu).

Ces propriétés sont calculées par une méthode (une fonction SQL, mais osef un peu du code là).

Ma question porte sur la manière de stocker cette information: est-ce que vous la stockeriez dans une table dédiée (disons, "spaceship_blueprint_properties") ou est-ce que vous laissez le système recalculer les propriétés du vaisseau à la volée quand vous en avez besoin?

Le 2nd cas me semble plus "naturel": on a un vaisseau avec une géométrie, des modules, des recherches du joueurs, etc, et on calcul donc les propriétés de combat/vitesse/PV de ce vaisseau à partir de ces infos entrantes.

Mais

1) Ce calcul peut être lent (bon, ça, osef un peu, c'est pas un argument)
2) Le calcul peut changer au cours de la vie du jeu, et les propriétés des vaisseaux changeront donc immédiatement: un joueur qui n'a rien fait verra son vaisseau changer de propriétés, sans forcément le voir
3) On ne peut pas afficher les propriétés des vaisseaux. Enfin, si, on peu, mais comme c'est calculé à la volée, ces propriétés pourraient différer entre le moment où on les affiche à l'écran, et le moment où un combat a lieu

Le 1er cas semble alors plutôt bien adapté, puisqu'on "fige" finalement les propriétés à un instant donné (en les recalculant quand c'est utile) et on n'a donc plus de soucis de lenteur, ou de changement de propriétés "à la volée" sans que le joueur ne le sache. Le cas 3 peut éventuellement arriver, mais uniquement si le joueur a fait une action au milieu (aka si les propriétés ont été recalculées). Donc, ce n'est pas dérangeant.

En revanche, cela fait un peu... "dénormalisation" du modèle je trouve (comme si je stockait la date de naissance du joueur, et que je stockais aussi son age, recalculé chaque jour, dans une colonne). Mais je ne sais pas trop si c'est un vrai argument...

J'ai une troisième piste intermédiaire à la limite: "stocker" les propriétés dans une vue. Cela me supprime le soucis de dénormalisation, mais cela réactive les problèmes 2 et 3 (le 1, on peut l'ignorer si la vue est matérialisée, même si MySQL ne sait pas le faire)

Bref, votre opinion là dessus? Votre expérience?
Perso, je vais le faire de la 1ere façon, parce que la "normalisation" à outrance, je m'en tappe un peu (il suffit de savoir que cette table est "calculée" à partir d'autres infos, ce qu'un commentaire indique facilement).

[Ter Rowan]

Pour moi tu calcules, tu stockes, ce qui te permet d'enrichir le gameplay :

en effet, le sujet principal est la modification des règles de calcul par choix de conception de jeu.

Grâce à stockage de la donnée tu as plus de liberté pour faire "passer la pilule"

1) Rééquilibrage dur : j'ai fait une connerie de conception à corriger
==> tu fais une annonce disant que maintenant le moteur XenOs a un poids qui change, et du coup tous les vaisseaux qui l'ont doivent avoir leur poids qui changent (tu refais les calculs, tu restockes)

2) Rééquilibrage doux : J'améliore ma conception
==> XenCorp United annonce qu'elle modifie la technologie du moteur XenOs, les nouveaux moteurs achetés auront un poids plus (faible / fort)
après peut être un numéro de version dans une propriété , ou bien un nouveau item "moteur XenOs 2.0" et tu "bannis" la production / vente du "moteur XenOs 1.0"


aujourd'hui le volume est plus vraiment le pb

[Sephi-Chan]

A mon sens, on ne devrait pas modifier de valeurs en dehors de mises à jour planifiées.

J'aime beaucoup l'idée de rééquilibrage doux exposée par Ter Rowan. Il suffit de ne plus permettre d'obtenir de nouveaux exemplaires, mais les anciens restent fonctionnels.

J'aime assez l'idée de calculer à la volée, mais c'est quand même typiquement le genre de cas où je mettrais un cache.

[Xenos]

Le ré-équilibrage doux est attractif, mais je en suis pas sûr que j'arriverai à bien l'appliquer pour VariiSpace.

En effet, si j'interdis d'utiliser un module à partir d'un instant donné, en conservant les plans de vaisseaux d'avant, alors ces modules continueront de "lurker" pendant des siècles: les joueurs ne changeront pas leurs plans de vaisseaux avant une éternité... Et si j'interdis de construire un vaisseau dont le plan utilise le module interdit, alors des joueurs seront hyper-désavantagés: ils ne pourront pas modifier leur plan de vaisseau avec le module interdit tant que des vaisseaux de ce type existent dans l'espace, et ils ne pourront pas construire de nouveaux vaisseaux de ce type.
Alors, je n'ai pas d'autre choix que de leur "offrir" un slot de plan de vaisseau supplémentaire, pour qu'il puissent faire un nouveau plan et laisser l'ancien lurker. Donc, le nombre max de plans de vaisseaux de ces joueurs n'est plus directement dépendant de leur niveau de recherche ou de leurs stats de jeu, mais dépend aussi d'un "offset" correspondant aux slots-cadeaux que je dois leur offrir.

C'est aussi pour ce genre de raison que je préfère stocker les stats "calculées" (comme le nombre max de plans de vaisseaux) plutôt que de réellement les calculer à la volée. Sans compter que, dans le cas des plans de vaisseaux, il serait logique de ne jamais avoir plus de plans que de slots libres, même si je change la règle de calcul. Calculer à la volée fait prendre ce risque (ou oblige à intégrer un GREATEST(COUNT(plans de vaisseaux déjà faits par le joueur), (valeur calculée par la formule)) pour l'éviter); et si ce nombre de slots est utilisé dans une autre formule, ça va faire un sacré bazar :/

Quant au ré-équilibrage "dur", je suis d'accord qu'il est à prendre avec de sacrées pincettes, car il change totalement l'état du joueur (ses stats) sans qu'il n'ait rien demandé ni fait.

Du coup, j'ai une 3e approche d'équilibrage en tête qui surgit grâce à ce système de "je stocke les valeurs calculées, et je ne les calcule que quand je le veux": les stats du joueurs/d'une entité ne bougent pas tant que le joueur n'a pas lui-même changé cette entité. Par exemple, supposons que le joueur ait un plan de vaisseau, et que les 5 modules dans ce plan lui donne 500 points de vie (car la règle, c'est 100PV/module). Je change la règle, et je passe à 80PV/module (un gap pas trop trop grand donc).

- Si les stats du plan de vaisseaux sont calculées à la volée, alors il passe direct à 400PV, et tous les vaisseaux déjà construits aussi (impossible de distinguer les vaisseaux construits avant la MAJ et ceux après: ce sera ingérable et incompréhensible pour le joueur passé les 2-3 mises à jour). Je sens venir la frustration des joueurs.
- Si la formule de calcul est inchangé et que je fais du "ré-équilibrage doux", alors je vais devoir interdire TOUS les modules du jeu pour n'autoriser que des nouveaux modules, à 80PV. Ca va vite, très vite faire énormément de changements partout, je pense que je vais me perdre.
- Si la formule de calcul est changée, mais que le calcul n'est fait qu'à la sauvegarde d'une modification du plan de vaisseau par le joueur, alors le joueur conservera ses stats (0 frustration), je ne "jette" aucun module (simple à gérer) et la MAJ ne s'appliquera que quand le joueur l'aura décidé, en modifiant &sauvant son plan de vaisseau.

Ca me semble pas déconnant... Si?!

[Meraxes]

Et si j'interdis de construire un vaisseau dont le plan utilise le module interdit, alors des joueurs seront hyper-désavantagés: ils ne pourront pas modifier leur plan de vaisseau avec le module interdit tant que des vaisseaux de ce type existent dans l'espace, et ils ne pourront pas construire de nouveaux vaisseaux de ce type.

Si c'est pas trop indiscret, est-ce que tu pourrais décrire rapidement les relations entre les tables que tu utilise (juste les clés primaires et étrangères pour les tables concernant les vaisseaux, les plans, les joueurs et les modules) parce qu'il y a probablement plein de façons de remanier ton modèle pour éviter ce problème (, non ?).

Par que, pour moi, il faudrait probablement faire la distinction entre la table des modèles de vaisseaux (la table sur laquelle il y a une clé étrangère qui pointe depuis la table des vaisseaux) et la table des plans de vaisseau (avec un nombre de slot limités et sur laquelle il y a une clé étrangère qui pointe depuis une table d'association avec la table des modules).

Après je dis ça complètement à l'aveugle, car je ne fais que supposer la structure de ton schéma.

[Xenos]

Intrinsèquement, le modèle n'influe pas sur le problème: les plans de vaisseaux sont constitués de modules, on construit des "exemplaires" de ces plans de vaisseaux, et si un exemplaire du vaisseau existe, alors le plan n'est pas modifiable (sinon, je pense que ce sera trop trop vite un bordel monstre pour les joueurs, qui auront des vaisseaux sans avoir aucune idée de leur "plan" de construction et de leurs capas). Et si un module interdit est utilisé dans un de ces plans, alors soit il interdit la construction de nouveaux vaisseaux utilisant ce plan (d'où le désavantage qui en découle: sommairement, si on n'a qu'1 slot de plan, et que ce plan est bloqué parce qu'il contient un module interdit, alors on ne peut plus construire aucun vaisseau), soit il continue à l'autoriser (et le module ne sera probablement jamais abandonné).


Niveau modèle, pour répondre à la question, 1 table "fleet" liste les flottes dont le joueur dispose, chaque flotte est liée N-N aux plans (blueprints) du joueur, chaque blueprint est lié N-N aux modules.

CREATE TABLE `fleet` (

	`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

	`id_player` INT(10) UNSIGNED NOT NULL,

	`id_orbit` INT UNSIGNED NOT NULL,

	`label` VARCHAR(100) NOT NULL COLLATE 'utf8mb4_bin',

	-- @todo Remove this "status" as it seems totally useless now

	`status` ENUM('ATTACK','DEFEND') NOT NULL COLLATE 'utf8mb4_bin'

		COMMENT 'An aggressive fleet will automatically and instantly attack every hostile fleet on the same OC,

				while a defensive fleet will leave the other fleet alone',

	`chronotons_quantity` INT(10) UNSIGNED DEFAULT 0 NOT NULL

		COMMENT 'Quantity of chronotons ships in this fleet holds at the specified date',

	`chronotons_date` DATETIME DEFAULT CURRENT_TIMESTAMP NOT NULL,

	`extraction_mass_per_chronoton` INT UNSIGNED NOT NULL DEFAULT 0

		COMMENT 'Mass of atoms fleet can extract per chronoton',

	`atom_storage_capacity` INT UNSIGNED NOT NULL DEFAULT 0

		COMMENT 'Quantity of atoms you can store in all the ships',

	`construction_power` INT UNSIGNED NOT NULL DEFAULT 0

		COMMENT 'Multiply the chronotons quantity by this to get the constructions points of the fleet',

	PRIMARY KEY (`id`),

	UNIQUE INDEX `fleet_orbit` (`id_orbit`),

	-- A player cannot be deleted: you might only insert "fake credentials" in their account if needed

	UNIQUE INDEX `id_player_label` (`id_player`, `label`),

	CONSTRAINT `FK_fleet_orbit` FOREIGN KEY (`id_orbit`) REFERENCES `orbit` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_fleet_player` FOREIGN KEY (`id_player`) REFERENCES `player` (`id`)

		ON UPDATE CASCADE ON DELETE CASCADE

	-- Delete the fleet on deleting the player since fleet has no meaning (it is fleet_blueprint that must not be deleted)

	-- So if such FK cascades a DELETE, then it means the fleet was empty (no spaceship in it at all)

)

COLLATE='utf8mb4_bin'

ENGINE=InnoDB

COMMENT 'The fleets the players control'



CREATE TABLE `fleet_blueprint` (

	`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

	`id_fleet` INT(10) UNSIGNED NOT NULL,

	`id_blueprint` INT(10) UNSIGNED NOT NULL,

	`number` INT(10) UNSIGNED NOT NULL,

	PRIMARY KEY (`id`),

	-- A same blueprint cannot appear twice in a fleet (easier interface later)

	UNIQUE INDEX `id_blueprint_id_fleet` (`id_blueprint`, `id_fleet`),

	CONSTRAINT `FK_fleet_blueprint_blueprint` FOREIGN KEY (`id_blueprint`) REFERENCES `blueprint` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_fleet_blueprint_fleet` FOREIGN KEY (`id_fleet`) REFERENCES `fleet` (`id`)

		ON UPDATE CASCADE

)

COLLATE='utf8mb4_bin'

ENGINE=InnoDB

COMMENT 'Spaceships (conceptions) in every fleet

Quantities are always "for all ships of this type in that fleet"'



CREATE TABLE `blueprint` (

	`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

	`id_player` INT(10) UNSIGNED NOT NULL,

	`id_material` INT(10) UNSIGNED NOT NULL

		COMMENT 'The blueprint must be made of a single and already defined material

				Otherwise, it explodes too quickly: 5 different materials for 3 different conceptions = 15 combinations',

	`label` VARCHAR(100) NOT NULL COLLATE 'utf8mb4_bin',

	`id_grid` TINYINT(3) UNSIGNED NOT NULL

		COMMENT 'Each spaceship is an assembly of modules aligned on a specific 2D grid so this is the grid',

	`id_appearence` SMALLINT(5) UNSIGNED NOT NULL

		COMMENT 'It will be computed by some dynamic code, and the file number (with no extension) is saved.

				So if I change the dynamic code, then the conceptions already made will not change their appearence',

	`atom_storage_capacity` INT UNSIGNED DEFAULT 0 NOT NULL

		COMMENT 'Total amount of atoms you can store in that ship',

	`extraction_mass_per_chronoton` INT UNSIGNED DEFAULT 0 NOT NULL

		COMMENT 'The mass of atoms this ship can extract per chronoton; 0 if no extraction possible',

	`construction_power` INT UNSIGNED DEFAULT 0 NOT NULL

		COMMENT 'The capacity of construction this ship has',

	`construction_power_for_building` INT UNSIGNED DEFAULT 0 NOT NULL

		COMMENT 'The construction capacity required by a fleet to make this ship',

	`atom_quantity_factor_for_building` INT UNSIGNED NOT NULL DEFAULT 1000

		COMMENT 'Multiply the number of atoms of the material by this factor

				to get the real quantity of atoms you need to make this ship',

	`is_editable` BIT(1) NOT NULL DEFAULT 0,

	PRIMARY KEY (`id`),

	-- 'A label must be unique for a specific player, to identify the blueprint uniquely'

	UNIQUE INDEX `id_player_label` (`id_player`, `label`),

	-- 'One same material can be used for several different conceptions'

	INDEX `FK_blueprint_material` (`id_material`),

	INDEX `FK_blueprint_grid` (`id_grid`),

	-- 'The appearence is stored so if I change the algorithm, then existing ships are NOT altered'

	INDEX `FK_blueprint_appearence` (`id_appearence`),

	CONSTRAINT `FK_blueprint_appearence` FOREIGN KEY (`id_appearence`) REFERENCES `appearence` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_blueprint_grid` FOREIGN KEY (`id_grid`) REFERENCES `grid` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_blueprint_material` FOREIGN KEY (`id_material`) REFERENCES `material` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_blueprint_player` FOREIGN KEY (`id_player`) REFERENCES `player` (`id`)

		ON UPDATE CASCADE ON DELETE CASCADE

)

COLLATE='utf8mb4_bin'

ENGINE=InnoDB

COMMENT 'Players'' spaceship conceptions

They are made in a specific single material, so their characteristics are determined by the blueprint

and not in real time by blueprint+material'



CREATE TABLE `blueprint_module` (

	`id_blueprint` INT(10) UNSIGNED NOT NULL,

	`id_module` TINYINT(3) UNSIGNED NOT NULL,

	`id_grid_case` INT(10) UNSIGNED NOT NULL,

	-- A blueprint cannot have two modules on the same grid case (a grid case cannot appear twice for a blueprint)

	UNIQUE INDEX `id_blueprint_id_grid_case` (`id_blueprint`, `id_grid_case`),

	INDEX `FK_blueprint_module_module` (`id_module`),

	INDEX `FK_blueprint_module_grid_case` (`id_grid_case`),

	CONSTRAINT `FK_blueprint_module_blueprint` FOREIGN KEY (`id_blueprint`) REFERENCES `blueprint` (`id`)

		ON UPDATE CASCADE ON DELETE CASCADE,

	CONSTRAINT `FK_blueprint_module_grid_case` FOREIGN KEY (`id_grid_case`) REFERENCES `grid_case` (`id`)

		ON UPDATE CASCADE,

	CONSTRAINT `FK_blueprint_module_module` FOREIGN KEY (`id_module`) REFERENCES `module` (`id`)

		ON UPDATE CASCADE

)

COLLATE='utf8mb4_bin'

ENGINE=InnoDB

COMMENT 'The modules in the blueprint, placed on spaceship grid cases'



CREATE TABLE `module` (

	`id` TINYINT(3) UNSIGNED NOT NULL AUTO_INCREMENT,

	`name` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_bin'

		COMMENT 'Code readable identifier in dash-lower-case,

				and avoid any special-* name since it is used for other purposes',

	`is_registering_required` TINYINT(1) UNSIGNED NOT NULL DEFAULT 1

		COMMENT 'Indicates which modules must be used when registering',

	`label` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_bin',

	`image` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_bin'

		COMMENT 'Name of the image resource file URL, with extension but without path',

	PRIMARY KEY (`id`),

	-- Code readable identifier (unique tho)

	UNIQUE INDEX `name` (`name`),

	-- Human readable identifier (so unique to make it non ambiguous)

	UNIQUE INDEX `label` (`label`),

	-- Two modules cannot share the same image, or it's gonna be confusing

	UNIQUE INDEX `image` (`image`)

)

COLLATE='utf8mb4_bin'

ENGINE=InnoDB

COMMENT 'The modules of the ship'

[Meraxes]

Ah OK, c'est intéressant de voir les choix de conception faits.

Mais alors, dans ce cas là est-ce qu'on ne peut pas faire en sorte que :
- les 'blueprint' qui utilisent des modules interdits (ou qui, plus généralement, ne sont plus valides) passent à l'état inactif ;
- les 'blueprint' inactifs ne consomment aucun slot et n'apparaissent pas dans la page d'édition des modules (donc non modifiables) mais restent toujours consultables depuis les page de gestion des 'fleet' pour voir les capacités du modèle de vaisseau ;
- lorsque le dernier enregistrement 'fleet_blueprint' lié à un 'blueprint' inactif est supprimé, il entraine la suppression de ce 'blueprint' (car il n'y a plus rien qui pointe dessus)

Dans ce cas, l'impact est que le joueur doit recréer un nouveau 'blueprint' valide si il veut continuer à créer des 'fleet'.


Edit :
Ah oui, c'est vrai, c'est encore mieux en ajoutant le fait de pouvoir remplacer automatiquement le plan invalide par un plan valide :


- les 'blueprint' qui passent en inactif sont automatiquement remplacés par un blueprint valide (copie du blueprint inactivé en remplaçant tous les modules obsolètes par des modules nouvelles versions ; on a donc deux 'blueprint' : un inactif ancienne version et un actif avec correction)

Bon, ok je ne veux pas faire dériver encore plus le sujet...

[Xenos]

n'apparaissent pas dans la page d'édition des modules => Le problème est alors de faire clairement comprendre aux joueurs pourquoi le plan n'est plus modifiable, et de gérer ce paramètre en plus (je n'ai pas alourdir les choses avec ce genre de condition). Parce que mettre le plan en grisé ou autre pour dire pas modifiable, ok, mais est-ce que les joueurs accepteront l'idée que le plan n'est plus du tout modifiable parce qu'un module ne plait plus au MdJ...
Et cela m'oblige à rajouter la possibilité de copier/coller un vaisseau (sinon, si 1 seul module dans mon plan de 600 modules est lock, alors je refais tout le vaisseau de 600 modules...!)

Et perdre son plan de vaisseau pouf quand tu perds ton derniers vaisseau... mouais... c'est quand même censé être du "taff" de faire un plan alors j'aime moyennement le concept de le supprimer.

Après, l'idée est intéressante, pour sûr. Mais je préfère encore le non-recalcul des formules, vu le bouzin que cela risque de faire sinon (parce que, là encore, on ne parle que d'un module "inactivé", mais si c'est une logique globale comme le concept de 100PV/module qui change, là, ça va vraiment être ingérable: imagine tous les joueurs avec tous leurs plans rendus inactifs... :/ )

[Ter Rowan]

Hello suis dans le bus avec vieil iPhone... donc désolé du style

J aim pas trop ta troisième voie mais je comprends la critique de ma méthode douce

J aime bien l'idée de meraxes cependant

Sinon ma propal (qui change ton modèle c est sur)

1) le joueur a n sorte de plans
2) un plan est un assemblage de TYPE de modules
3) certains assemblages sont debiles : un type de module réacteur de poussée arrière n a pas d intérêt placé autrement qu'à l arrière
4) le plan permet de calculer des coefficients de...
5) le joueur a accès à plusieurs modules du même type
6) chaque module a ses propriétés qui permettent le calcul global
7) l utilisation d un module l use: au bout de n utilisations le module doit être remplacé sans pour autant casser les plans

Du coup
Si tu te plantes en conception globale
Soit tu petes les coefficients des plans ( méthode dure)
Soit tu crees des nouveaux modules avec des valeurs corrigées les anciens sons interdits et disparaîtront à la longue

Après si tu veux accélérer la "migration" tu proposes de remplacer gratuitement les modules par leur nouvelle version pendant une période de temps (le joueur y gagne des utilisations)

[Xenos]

Je ne vois franchement pas à quoi correspond le point 7: c'est un plan, y'a pas "d'usure" du module?!

Je vais en revanche me répéter une dernière fois: y'a des propriétés qui sont cross modules. Appliquées à TOUS les modules. La masse par exemple, ou l'impact sur les PV ou sur la taille du vaisseau, etc. Avec ces approches, je ne PEUX pas toucher à ces propriétés (et je suis certain que j'aurai besoin de le faire, parce que je n'ai aucune idée de la masse de joueur que j'aurai et celle-ci influencera clairement le résultat de l'équilibrage, cf ECLERD où le vide sidéral de joueurs a fait sauter toute la balance économique du jeu): si je doit invalider, quelque soit la manière, tous les modules à chaque ajustement de ce type, ça sera ingérable par moi, incompréhensible par les joueurs.

A la limite, l'idée d'avoir des modèles et des plans séparés (donc, en gros, des plans de vaisseaux "figés" et pas modifiables voire pas accessible par les joueurs) se tient mieux. Perso, je vais rester sur mon idée de départ pour ce cas précis (bon, initialement, le concept était plus large mais bon): tant que le joueur n'a pas touché à son plan de vaisseau, ses propriétés restent identiques et inchangées (d'où l'intérêt de ne pas calculer les choses à la volée, mais uniquement à la sauvegarde du plan, pour en revenir au sujet initial).