15-08-2012, 03:08 PM
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.
- 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.