Gestion Inventaire

[Sephi-Chan]

Essaye de donner les informations utiles dès le premier post, ça sera plus pratique pour tout le monde. :p

On parle de quantité pour les objets qui peuvent être stack. Par exemple les potions dans un jeu. Avoir des entités indivuelles n'a pas d'intérêt dans un tel cas.

Et ce n'est pas parce que tu stock toutes les informations dans une même table (ce que je trouve plus approprié) que tu dois tout récupérer d'un compte.

De plus, tu n'as pas répondu à ma question du premier post, ce qui t'aiderait pourtant à définir (ou à nous communquer) ton besoin.

[Argorate]

Ta liste de ta première réponse est évidemment correct, c'est le principe même d'un inventaire, mais je ne veux pas parler des méthodes que doivent contenir ma classe, c'est pas le but ^^

Par contre: comment tu fais si tu as un mixte d'objet "unique" (instancié) et des objets comme des potions qui nécessite qu'une "qte"? il faut forcement plusieurs table non? C'est un peu gênant...

[Sephi-Chan]

Pourtant ce sont les méthodes de ton inventaire qui vont faire que c'est efficace ou non.

Tu n'as pas besoin de plusieurs tables pour gérer les objets individuels et stackés : il suffit de mettre une quantité de 1 pour les premiers ont une quantité de 1 et N pour les autres. Ça se joue seulement dans la table items, qui a au moins 3 colonnes : character_id, item_type_id, et quantité.

[Damocorp]

Comment ça ?

Les stats ou les tests qui montre quand il est judicieux de découpé une table ? C'est pas de cela que tu parlais en parlant de volumétrie ?

[Argorate]

Ok, admettons, tu cheat en mettant 1 pour les objets distinct pour la qte, mais tu mets quoi dans la colonne id_objet pour les objets "stack"? Tu laisse un id_objet qui correspond à plusieurs objet en réalité? c'est cette ambiguïté qui m’embête.

Sinon, pour ce qui est du "flag" qui permet de situer l'objet, ça ne marche pas, ou plutôt ça marche que dans un cas restreint où l'objet ne peux qu’appartenir à qq'un ou être dans un coffre qui appartient à qq'un.

Si jamais l'objet est au sol (sur la map mais n’appartient personne, tant que pas ramassé)? dans un véhicule qui lui est sur la map? ou encore au sol mais à l’intérieur d'un batiment, le champs id_joueur n'est plus utilie et le seul champs "flag" ne suffit pas a définir le type de "lieu" où se trouve l'objet, c'est pour ça que de base, j'ai plutôt: une table avec les carac de l'objet, puis plusieurs table qui contienne des listes d'objets (inventaire, map, dans un batiment, l'étage... etc), non?

[Sephi-Chan]

Ok, admettons, tu cheat en mettant 1 pour les objets distinct pour la qte, mais tu mets quoi dans la colonne id_objet pour les objets "stack"? Tu laisse un id_objet qui correspond à plusieurs objet en réalité? c'est cette ambiguïté qui m’embête.

Mais arrête avec tes cheat… Considérons que dans ton jeu il y a des bandages pour se soigner. Les bandages occupent une place dans l'inventaire et peuvent être empilés. On aura donc une entrée dans la table item_types qui a (en plus d'autres colonnes spécifiques à ton jeu) pour label Bandage. Disons que l'id de cette ligne est 42.

Quand un personnage (d'id 10) acquiert un bandage, tu crée une ligne dans la table items. Elle a pour character_id 10, pour item_type_id 42, pour quantity 1 et pour location bag). Après il te suffit d'influer sur la quantité quand tu veux en ajouter et en retrancher.

La table item_types contient les modèles d'objets, alors que items contient les instances de l'objet. J'ai l'impression que tu c'est ça que tu n'as pas compris dans la modélisation qu'on te propose.

Sinon, pour ce qui est du "flag" qui permet de situer l'objet, ça ne marche pas, ou plutôt ça marche que dans un cas restreint où l'objet ne peux qu’appartenir à qq'un ou être dans un coffre qui appartient à qq'un.

Si jamais l'objet est au sol (sur la map mais n’appartient personne, tant que pas ramassé)? dans un véhicule qui lui est sur la map? ou encore au sol mais à l’intérieur d'un batiment, le champs id_joueur n'est plus utilie et le seul champs "flag" ne suffit pas a définir le type de "lieu" où se trouve l'objet, c'est pour ça que de base, j'ai plutôt: une table avec les carac de l'objet, puis plusieurs table qui contienne des listes d'objets (inventaire, map, dans un batiment, l'étage... etc), non?

Non. Si l'objet est au sol il n'a pas de character_id, il a une location qui indique s'il est sur la carte, dans un véhicule ou dans un bâtiment, et tu as une colonne location_id qui contient éventuellement l'id de cette entité (NULL sinon), et des colonnes x et y pour stocker sa position si besoin (NULL sinon).


Tu comptes continuer d'exposer tes besoins au compte goutte ou bien tu penses nous dire tout ce dont on a besoin pour t'aider avant la trentième réponse ? iffle:

[Akira777]

Argorate : La quantité, il faut bien que je la gère, par exemple le joueur pourra avoir des shurikens, des potions, des denrées alimentaires, des armures, des armes, ...
Il y'a des objets dont l'unicité n'est pas nécéssaire, pour les shurikens ou les denrées alimentaires par exemple, je me vois mal leur attribuer un Id unique sachant le rythme auquel ils sont consommés dans le jeu...
En ce qui concerne les armes, armures, oui elles sont uniques, mais dans le cas ou le joueur aurait deux armes identiques (avec le même niveau d'usure et le même enchantement), il faut aussi prévoir la stackabilité.

[Argorate]

Argorate : La quantité, il faut bien que je la gère, par exemple le joueur pourra avoir des shurikens, des potions, des denrées alimentaires, des armures, des armes, ...
Il y'a des objets dont l'unicité n'est pas nécéssaire, pour les shurikens ou les denrées alimentaires par exemple, je me vois mal leur attribuer un Id unique sachant le rythme auquel ils sont consommés dans le jeu...
En ce qui concerne les armes, armures, oui elles sont uniques, mais dans le cas ou le joueur aurait deux armes identiques (avec le même niveau d'usure et le même enchantement), il faut aussi prévoir la stackabilité.

En fait la notion d'empiler n'est pas bonne, je vois pas pourquoi tu pourrais "empiler" deux armes sous le prétexte qu'elles sont identique, elles devraient toutes deux prendre de la place (distinct) dans l'inventaire. Même chose pour les potions et tout autres objets qui a un volume et une masse propre.

Sephi-Chan: ce n'est pas du tout mon besoin actuel, mais autant implémenter un système qui prend en compte tout les cas, pour que les évolutions futurs puissent être envisagé sans avoir a tout recoder le système d'inventaire^^

PS: je vois pas en quoi le rythme de consommation embête pour un id surtout si c'est autoincrementer?

[Sephi-Chan]

Le but de l'objet de pouvoir changer simplement l'implementation. Inutile donc de t'embeter.
Et c'est exactement pour ça que je maintiens que tu dois juste lister les méthodes de ton inventaire. Tu pourras modifier leur implémentation plus tard si besoin.

Courage. Avance encore un peu dans la voie de l'objet.
Tu es passé à l'objet pour la syntaxe. Maintenant passe-y pour de vrai.

Si tu n'as pas besoin du mécanisme de stack, le modèle que j'ai proposé fonctionne quand même.

[niahoo]

utilises Redbean, il créera les tables et les champs pour toi au fur et à mesure de tes tests, tu n'as qu'à implémenter le code de tes méthodes et la base en découlera. ça permet de faire un pont sympa entre un modèle conceptuel des données et le modèle physique