09-11-2018, 12:52 PM
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)
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)