+1 ter rowan, je vais pas filer à mes players un champ uranium, un champ pommes, un champ t-shirts, un champ épées+2force, etc.
Mais effectivement on mélange les concepts de ressource commune à tous (genre or/bois/pierre dans age of empires), les items genre épées, les items différenciables genre épée avec usure à 3, aiguisage à 5 + pommeau magique ajouté.
Dans le fond on est plutot d'accord d'après ce que j'ai pu lire ici.
Mais par contre là ou je ne suis pas d'accord sur le count(), c'est que la seule raison valable (y compris pour merise) de stocker un item par tuple, c'est que cet item puisse être unique. Pour être unique, il faut qu'il ait des particularités comme on à proposé (usure, bonus ajoutés, modifications).
Mais dans ce cas, à quoi peut bien te servir le count() ? A quoi te sert-il de savoir que tu as 10 fusils si pas un n'est pareil.
Alors ok, mettons que tu joues plusieurs personnages. tu as 5 persos, tu as 5 fusils, ça tombe bien. Maintenant tu vas quand même prendre les fusils un par un pour voir lequel est le plus adapté à chaque personnage (puisuqu'ils sont différenciés par des modifs) ; il y aura un personnage qui sera plus balèse avec une machette, un autre auquel tu vas plutot faire jouer du soutien, un troisième qui ne sait pas encore utiliser ce fusil.
À mon sens, avoir le count(), le décompte, sert quand les items sont pareils et que tu les brasses: combien j'ai de cuissots de viande pour donner à mes nobles dans Anno 1404, combien j'ai de marbre dans Zeus pour construire mon temple. Et dans ce cas là, la meilleure modélisation reste de stocker la quantité d'items dans une relation n,n entre l'entité joueur et l'entité objet.
Ce qui va généralement se traduire dans une table (joueur, item, quantité), ou parfois, comme tu l'as présenté, et quand peu d'items différents sont présents en jeu, dans un champ quantité_or, quantité_bois, quantité_pierre directement dans la table joueur. (ou dans une table ressource pour plus de lisibilité mais qui ne sera qu'un "morceau" séparé de la table joueur.
Dans le cas de nos 5 fusils, là chacun aura son tuple perso, bien sur, mais pour la seule raison qu'ils ne se stackent pas puisque ils sont uniques.
Mais effectivement on mélange les concepts de ressource commune à tous (genre or/bois/pierre dans age of empires), les items genre épées, les items différenciables genre épée avec usure à 3, aiguisage à 5 + pommeau magique ajouté.
Dans le fond on est plutot d'accord d'après ce que j'ai pu lire ici.
Mais par contre là ou je ne suis pas d'accord sur le count(), c'est que la seule raison valable (y compris pour merise) de stocker un item par tuple, c'est que cet item puisse être unique. Pour être unique, il faut qu'il ait des particularités comme on à proposé (usure, bonus ajoutés, modifications).
Mais dans ce cas, à quoi peut bien te servir le count() ? A quoi te sert-il de savoir que tu as 10 fusils si pas un n'est pareil.
Alors ok, mettons que tu joues plusieurs personnages. tu as 5 persos, tu as 5 fusils, ça tombe bien. Maintenant tu vas quand même prendre les fusils un par un pour voir lequel est le plus adapté à chaque personnage (puisuqu'ils sont différenciés par des modifs) ; il y aura un personnage qui sera plus balèse avec une machette, un autre auquel tu vas plutot faire jouer du soutien, un troisième qui ne sait pas encore utiliser ce fusil.
À mon sens, avoir le count(), le décompte, sert quand les items sont pareils et que tu les brasses: combien j'ai de cuissots de viande pour donner à mes nobles dans Anno 1404, combien j'ai de marbre dans Zeus pour construire mon temple. Et dans ce cas là, la meilleure modélisation reste de stocker la quantité d'items dans une relation n,n entre l'entité joueur et l'entité objet.
Ce qui va généralement se traduire dans une table (joueur, item, quantité), ou parfois, comme tu l'as présenté, et quand peu d'items différents sont présents en jeu, dans un champ quantité_or, quantité_bois, quantité_pierre directement dans la table joueur. (ou dans une table ressource pour plus de lisibilité mais qui ne sera qu'un "morceau" séparé de la table joueur.
Dans le cas de nos 5 fusils, là chacun aura son tuple perso, bien sur, mais pour la seule raison qu'ils ne se stackent pas puisque ils sont uniques.