Gestion Inventaire

[Argorate]

Bonjour,

j'aurais aimé avoir vos conceptions pour ce qui concerne l'inventaire et l'équipement.

1. Faite vous deux table différente entre les objets équiper et ceux dans l’inventaire (sac a dos), ou une seul table avec un champs boolean pour savoir s'il est équipé ou non?


2. Étant en objet j'aurais tendance a vouloir créer une classe Inventaire. Ce qui m’embête c'est que j'ai peur que ce soit vraiment lourd, si pour choper l'arme équipe, je dois charger l’inventaire, puis chercher l'arme équiper puis chargé l'objet Arme, ça fait beaucoup de requête et de code supplémentaire par rapport a mon système actuel, quel conception faites-vous? Pourquoi?


Merci.

[Sephi-Chan]

Il faudrait que tu nous détailles l'interface d'un inventaire, de quoi as-tu besoin ? C'est ça qui doit te guider quand tu conçois tes classes.

Exemple des choses qui pourraient être dans ton interface :

• Lister tous les objets équipés ;
  
• Lister tous les objets du sac à dos ;
  
• Ajouter un objet au sac à dos ;
  
• Vérifier la présence d'une quantité donnée d'un type objet ;
  
• Vérifier la présence d'une quantité donnée d'un objet précis ;
  
• Utiliser un objet du sac ;
  
• Equiper un objet du sac ;
  
• Retirer un objet et le mettre dans le sac ;
  
• …
  

En listant les interactions dont tu as besoin, tu peux encapsuler chacune de ces interactions dans une méthode qui sera très efficace pour sa tâche (en terme de stockage et/ou d'interrogation de la base de données).

[Akira777]

Pour ma part :

- une table listant les objets avec leurs accès et leurs données de commerce (niveau pour l'avoir, prix, argus marché, ...)
('id', 'name', 'weight', 'price', 'marketable', 'required_level', 'required_rank' [...]).
- une table listant les objets du coffre du joueur
('player_id', 'player_item_stock_id', 'player_item_base_id', 'player_item_quantity')
- une table de l'inventaire du joueur
('player_id', 'player_item_stock_id', 'player_item_base_id', 'player_item_quantity')
- une table des équipements du joueur
('player_id', 'player_item_stock_id', 'player_item_base_id', 'player_item_quantity')

Un objet dans la table des items du jeu à un identifiant smallint, c'est le patron de l'objet.
Une fois obtenu par le joueur l'objet est stocké dans l'inventaire du joueur (s'il a suffisamment de place pour le stocker) et se voit générer un identifiant bigint pour rendre l'item unique tout gardant correspondance avec son Id patron pour déterminer l'objet de base.

Sur ce modèle là, je peux déplacer l'objet de l'inventaire par son nouvel Id vers le coffre ou son équipement porté.

Du coup ca me fait 3 tables identiques (j'ai omis quelques champs). Si je veux déséquiper tous les joueurs je vide la table des équipements. Ou quand je charge deux joueurs (pour les faire combattre par exemple), je n'ai pas besoin de parcourir contenant tous les items d'un joueur. Surtout que le coffre d'un joueur peut contenir des centaines d'objets alors que son inventaire seulement une petite dizaine. Et de ce fait je préfère travailler avec une table contenant quelques milliers d'enregistrement qu'une table en contenant des millions.
(A l'heure actuelle sur mon jeu : table d'inventaire = 28 000 enregistrements, table de coffre = 1 470 000 enregistrements
Quand à l'équipement, comme sur mon jeu, au maximum 3 objets peuvent être équipés au maximum et que ces équipements sont chargés à chaque page, ils ont droits à une table séparée fait quelque chose comme 8000 enregistrements.

[Sephi-Chan]

Quel est l'intérêt d'utiliser 3 tables, plutôt qu'une seule table avec une colonne pour distinguer (equipped, bag, bank, par exemple).

Sinon c'est bien le modèle que j'adopterais, avec une différence de terminologie pour mes 3 entités :

• Character (table characters) ;
  
• ItemType (table item_types) ;
  
• Item (table items, avec des FK character_id et item_type_id, ainsi que la quantité (si le type d'objet est empilable) et le fameux flag pour savoir où l'objet est) ;
  

[Akira777]

Pourquoi ? Parce que comme expliqué : la totalité des objets des joueurs stockés approche les 1 500 000 entrées dans la base.

Les objets uniquement équipés approchent les 8000 enregistrements et son chargés à chaque appels de page (à peu près 10 000 hits par heure). Autant l'équipement est chargé à chaque fois, autant son coffre ne l'est pas. Pourquoi faire subir une requête sur une table à plus d'1 000 000 d'entrées pour au final même pas 1% de données utiles dans cette table. D'où la séparation...
(Pour la troisième table c'est parce que j'y stocke beaucoup de données également...)

[archANJS]

+1 Sephi.

Que feriez-vous dans le cas où tous les items sont uniques (par exemple, avec des dommages et un état actuel différents même pour deux items du même type) ? La même solution, mais avec deux champs additionnels ?

[Sephi-Chan]

J'ai lu l'information sur la volumétrie, mais as-tu eu des soucis de performance pour passer à un tel découpage ?
Si oui, as-tu remarqué des gains notables après modification ?

Car à première vue, je ne pense pas que des requêtes sur des champs indexés puissent être longues, même sur 2 millions de lignes (les bases de données sont taillées pour des volumes conséquents), et je n'encouragerai pas à utiliser ce découpage si ce n'est pas nécessaire.

[Damocorp]

Vous avez un lien vers l'information sur la volumétrie ?
Ca risque de m'obliger à changer pas mal de chose

[Sephi-Chan]

+1 Sephi.

Que feriez-vous dans le cas où tous les items sont uniques (par exemple, avec des dommages et un état actuel différents même pour deux items du même type) ? La même solution, mais avec deux champs additionnels ?

Oui. Dans un jeu comme Diablo ou World of Warcraft, les objets s'abîment à force d'être utilisés. Le niveau maximal de durabilité est stocké au niveau de l'ItemType alors que le score actuel de chaque objet doit être stocké au niveau de l'entité Item.

Vous avez un lien vers l'information sur la volumétrie ?
Ca risque de m'obliger à changer pas mal de chose

Comment ça ?

[Argorate]

La solution proposé n'est pas du tout la bonne pour mon cas, puisque je suis en train de passer à un modèle où les objets sont instanciés, hors ici, Akira777, tu parles de "quentity", ce qui signifie donc que tu ne distingues pas les objets entre eux, hors c'est justement tout le but de ma manœuvre!
Moi, je suis en train de passé au modèle: chaque objet a un id unique (et est unique avec des modification sur leur caractéristiques qui peuvent être propre a chaque objets [pour gérer mon futur système de rareté à carac générer aléatoirement]), c'est donc avec ce contexte là que je souhaite discuter de modèle de conception.

Sinon, pour la question soulevé, je ferais également deux tables distinct: inventaire et coffre. Ce sont des entités différente (et comme cela a été dit, pas besoin de charger les objets de l'un quand on veux l'autre et vis versa) par contre le fait qu'il soit équipé ou non, j'hésite tjs pour mettre un champs, mais je pense que c'est quand même plus judicieux, puisqu'une seule requête SQL suffit.