Propriétés d'un objet: stockage ou calcul à la volée? - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : Propriétés d'un objet: stockage ou calcul à la volée? (/showthread.php?tid=7958) Pages :
1
2
|
RE: Propriétés d'un objet: stockage ou calcul à la volée? - Ter Rowan - 08-11-2018 L'usure n'est pas sur le plan mais sur le moteur physique (par exemple) RE: Propriétés d'un objet: stockage ou calcul à la volée? - Xenos - 08-11-2018 Hum, ok, ça fait un peu plus sens. Après, cela pose toujours le même problème de "slot de plan" locké par un plan inconstructible car utilisant des modules désactivé, et le problème du "bulk désactivation de modules" si une propriété/formule globale a chié dans la colle. RE: Propriétés d'un objet: stockage ou calcul à la volée? - Ter Rowan - 08-11-2018 Non t as pas compris Le plan définit des types de module Ton module has been sera du même type que le module le remplaçant RE: Propriétés d'un objet: stockage ou calcul à la volée? - Xenos - 08-11-2018 Alors si je comprends bien, mon plan P possède par exemple un module de type T, et j'ai 2 modules de type T: M1 et M2, M1 étant le "has been" et M2 le nouveau module. Comment tu gères alors les vaisseaux V1 qui datent d'avant l'upgrade (et qui ont donc les modules M1) et les vaisseaux V2 qui datent d'après l'upgrade (qui auraient donc les modules M2, si je comprends bien l'idée qui vise à résoudre le problème du "le slot de plan est bloqué parce qu'on ne peut pas construire de nouveaux vaisseaux avec ce plan et qu'on ne peut pas non plus le supprimer car il existe des vaisseaux avec ce plan-là")? Franchement, je trouve ça complexe, point de vue joueur... si je dois jouer au jeu, j'ai moyennement envie de me prendre la tête à savoir quels "âge" ont ces différents modules: j'ai juste 500 vaisseaux de type "Mon Stocker", correspondant au plan "Mon Stocker" avec ses stats (figées, et plan non modifiable parce que j'ai fait des vaisseaux de ce type), et non pas 200 vaisseaux "Mon Stocker" qui date de longtemps avec 2 modules dépréciées, 100 autres "Mon Stocker" plus récents qui ont juste le premier module déprécié, et les 200 derniers qui sont des "Mon Stocker" qui correspondent pour de vrai au plan du vaisseau... Quant à savoir les propriétés (PV/bouclier/puissance de feu, etc) de ce mic-mac... :/ RE: Propriétés d'un objet: stockage ou calcul à la volée? - Ter Rowan - 09-11-2018 j'avais pas en tête le coté j'ai plan.nbVaisseaux je croyais j'ai des plans, j'ai n vaisseaux unitaires basés sur ces plans c'est sur que dans cette approche c'est compliqué d'intégrer l'usure par contre pour moi y a pas plus de complexité à avoir : Mon Stocker.config1 = 500 Mon Stocker.config2 = 200 Mon Stocker.config3 = 100 que Mon Stocker = 800 Mon Builder (?!) = 300 Mon Pinguin = 400 mais encore une fois la modélisation que je proposais, basé sur l'usure, était sur une approche micro de la flotte, unitaire, et pas macro. Et la je reconnais que : Mon Stocker.config1 = 150 (usure 98%), 200 (usure 61%) 3 (usure 48%) ... ... ..... ...... Mon Stocker.config2 = 200 ... ... ..... ...... Mon Stocker.config3 = 100 ... ... ..... ...... ça peut être compliqué et il faudrait se pencher sur une simplification du truc (ma flotte de 500 c'est 500* n pv) et ça pourrait pourrir l'expérience du joueur bref comme t'aimes pas, la notion de 1 plan = plusieurs configs, et que ce n'est intéressant que pour l'usure (ou presque) qui nécessiterait de repenser l'interface gestion macro de la flotte, ça milite pas pour mon modèle RE: Propriétés d'un objet: stockage ou calcul à la volée? - Xenos - 09-11-2018 Y'a une complexité à présenter "a.1, a.2, a.3, b.1, c.1, c.2" au joueur plutôt que "a, b, c, d, e, f": ce (le plan et la config) ne sont pas des "objets" de même nature dans le 1er cas, alors que le 2nd ne présente que des objets de même nature. La complexité est donc plus importante dans le 1er cas, même avec le même nombre d'éléments (schématiquement, il faudra une page dédiée aux configs du plan sélectionné, ou un distingo entre les plans et les configs dans la page principale: au lieu d'avoir une liste de plans, on devra avoir un tableau plan/config par exemple). En revanche, je garde quand même le principe de l'idée hein, mais pas pour VariiSpace: Eclerd, si je le reboot, sera probablement basé sur une approche "unitaire" (micro) car là, ce devrait être bien plus gérable. Et là, je ne sais pas comment je travaillerai les équilibrages (peut-être de la façon proposée... même si je pense plus probablement le gérer en figeant les stats de chaque bâtiment à sa construction, ayant donc "1 plan = 1 batiment construit"... à voir, j'y réfléchirai plus tard) |