[Gestion inventaire] ID unique, ou non?

[Ruz]

perso, j'ai pas tropcompris le problème, un ID unique par objet c'est pas trop un probleme.
Si l'or a l'ID 1, que le joueur en ai 1 ou 50.000 ca change rien, son ID reste 1, le nombre est enregistré directement...
Ca c'est pour le développement des objets.
m'enfin comme vous etes pas trop clair sur le problème j'ai essayé de le voir autrement et il se pourrait que Ruz est eu la mauvaise ID(mouahahaha...bon ok => [] ) d'enregistrer dans une table les objets de tous les joueurs...ce qui ne se fait pas...(Mon dieu les requetes de oufs pour le serveur !!!)
J'espère qu'au moins une de ces interprétations est bonne

Enfin, le problème est et reste toujours:
un ID par type d'objet par joueur + gestion quantité: ok
un ID par type d'objet par joueur + gestion quantité + gestion dégats: KO
=> Je dois passer à un ID par armure d'un meme type chez le meme joueur... donc, gérer ca par code (lourd), soit passer TOUS les objets en ID unique par unité d'objet=> meme les 250 pièces d'or en poche seraient passées en 250 ID différents (un ID par pièce)
Je cherche un système qui permette de différencier deux armures endommagées différemment chez un meme joueur. (valable aussi pour les armes, etc...), autre que le "tu traites les armes/armures à part" (donc, un ID par lien ID_perso/ID_armure)


sinon, enregistrer dnas une table les objets de tous les joueurs. Ben, oui, table inventaire... qui consiste en un lien entre l'ID joueur et un ID d'objet, plus une quantité et une état de dégat. La table Objet contenant, elle, les caracs, nom, disponibilité, etc... des objets.
Suis pas dingue au point de stocker les caracs complètes de chaque objet pour chaque perso... maitnenant si je suis pas dans le bon, faut le dire ^^

[Satevis]

Petite idée qui n'est surement pas la meilleure voir la bonne .
-Ta table 'Objet', tout les types objets disponible avec leurs caractéristiques toussa toussa ce qui nous donne l'ID_Objet.
-Ta table 'Inventaire' qui lie un ID_Objet à un ID_Joueur plus les infos complémentaires genre la quantité si équipé ou pas toussa toussa qui nous donne ID_inventaire.
-1 table 'UsureObjet' qui associe un ID_Inventaire à la valeur d'usure si l'objet en à une. Exemple : si tu as 5 épées tu insères 5 ligne, pour l'or pas la peine de l'y ajouter puisque pas d'usure.

[Cartman34]

Personnellement, je suis contre le principe d'utiliser une table pour enregistrer ces informations mais toi tu me fais la totale !
Tu me parles d'inventaire, moi ce que je ferais...
Comme la plupart des jeux on imagine des cases dans un inventaire correspondant au nombre de place qu'il peut contenir.
Chaque case doit se démarquer des autres, les objets ont soit un niveau de vie/casse (armure, épee, sabre laser...) soit une quantité (pièce d'or, unités de métal...).
Pour que la bdd puisse gérer cela facilement, j'y réfléchis et je me dis: "Tiens mais je n'ai aps besoin de faire de recherche sur cela, l'ID du joueur me suffit pour récupérer son inventaire..." alors pourquoi ne pas faire un champs inventaire contenant TOUT l'inventaire.
Pour cela, je vais revenir sur un point dont j'ai parlé précédemment, à chaque objet correspond un ID voir une variable(généralement présente et davantage utilisée). Par exemple, le joueur vient de s'acheter une Grosse épée de la mort qui tue, dans ta bdd, tu n'auras jamais marquer "Grosse épée de la mort qui tue" mais un nom de variable ou bien un ID, un numéro qui lui serait propre et qui lui permettrait d'être plus facilement manipulable et plus léger. Surtout que tu ne sais pas vraiment combien en a le joueur, mais tu t'en fiche un peu, toi ce que tu veux, c'est avoir la liste de ce qu'il possède tout en pouvant les compter(osef un peu...).
Tu peux donc avoir un champs TEXT inventaire pour chaque joueur(ou chaque entité) qui pourrait etre de la forme OBJECTID,NUMBER;
Avec OBJECTID l'ID de l'objet, NUMBER la quantité de l'objet ou son état(en pourcentage par exemple).
Ainsi, je viens de m'acheter ma belle Epée(ID: 21) neuve(100% de sa "vie") et il me reste 155 pièces d'or(ID: 1), je pourrais avoir un champs TEXT inventaire contenant: "21,100;1,155;".
A coups de concaténation et d'explode c'est extrêmement facile à utiliser. Avec des tableaux, tu peux faire des correspondance de variable et de langage. ET le stockage de ces données te prend quoi...? 13 octets ! et le nombre n'a pas vraiment d'importance, il n'est qu'une donnée en plus.
Voici un petit script te montrant comment passer ces données en un tableau PHP.

Code PHP :

<?php

//$User contientles données de l'utilisateur tel que l'inventaire.

$inventaire = array(); //on initialise l'inventaire



$ObjectList = explode(';', $User['inventaire'], -1);



foreach( $ObjectList as  $ObjectStr) {



    List($ObjectID, $Nb) = explode(',', $ObjectStr);



    $inventaire[$ObjectID] = $Nb;

}

?>

[Eluox]

Après faut voir si une table a part est plus lourd qu'une bataille d'explode et de foreach et de concaténation ^^

[phenix]

Ce que tu propose IGstaff n'est vraiment pas maniable... J'avais un système semblable au début (enfin c'était pas exactement sa mais sa s'en approchais) J'ai vite changer.

Pour un inventaire simple sa peut marcher, mais dès que tu ajoute des fonctions, ce genre de stratégie devient vite un poids et un gaspillage de ressource.

de même, avec ce système, si le joueur jete un objet au sol, comment tu fait ?

Tu dois select ton inventaire, l'explode, changer ton array et puis update ta base.
Avec un système comme le mien ou celui de keke (j'ai pas tout lu mais il semble que ce soit le même) tu fait un delete dans la base et hop...

Résultat pour une opération aussi banal que l'abandon d'un objet:
- Toi, tu as 2 requêtes (un select et un update), un explode, une boucle foreach (la plus lourde des boucles), et un list soit 5 opérations.
- Moi j'ai une requête, qui basé sur une clée primaire va prendre très très peu de ressource.

Et je te parle même pas de la vente d'un objet de l'inventaire...

Ensuite, imagine que l'utilisateur ai 1000 objet dans son sac :pleure2: tu fais un explode et tu obtient un tableau de 1000 composants ! Sa va faire lourd dans la mémoire tout sa...

Bref pourquoi faire compliquer ?

[Satevis]

IGstaff je propose juste une idée facile à mettre en œuvre et qui n'a quasiment aucune incidence ou presque sur le reste de son application.

En plus de ce qu'a développer phenix je rajouterai que sérialiser est rarement la solution (je crois qu'un thread en parlait récemment d'ailleurs), tu perd les avantages que peuvent te procurer la BDD.
Les BDD vaut les voir comme un restaurant, tu y va, tu commande un plat, on te sert le plat et tu n'as plus qu'a le manger au pire tu ajuste ton assiette ou tu rajoute des condiments mais c'est tout .
*Content de sa métaphore*
Ta solution ne fait économiser qu'une seul chose : l'espace disque, qui est à mon sens la dernière chose à optimiser.

[Ruz]

euh...IGstaff...
Ta solution résume ma solution actuelle, sauf que c'est du texte et pas une table.
en résumé: un lien entre un personnage et un objet. Sur ce lien, une info: soit une quantité (limité a 1 si l'objet a une barre d'usure), soit un taux d'usure. Mais plus de numéro ID pour chacun de ces liens.
Alors, vais faire simple:
le personnage équipe une armure dont il possède deux exemplaires. une abimé, l'autre pas. (bon, il l'équipe... sait deja pas comment il la choisi... mais bon). A l'affichage de l'inventaire... comment saurai-je quelle usure a son armure?
d'autre part, en combat, elle se dégrade... j'ajoute de l'usure à laquelle, sur quel critère??? (rien ne les différencie)

je reprends ton exemple:
objet 1: pièce
objet 123: armure de cuir
objet 268: épée courte
objet 8000: corde elfique de 2 mètres
je précise donc: 268 représente une épée courte pour tous les joueurs, pas une épée... TOUTES les épées. C'est mon "moule"

inventaire de ploucman:
1,8000;123,100;123,18;268,100;8000,1;
---- réfléchis en écrivant ----
ou alors, deux champs!
le premier avec l'inventaire, le second avec l'inventaire équipé.
et quand je choisi un objet à équiper, je dois passer l'usure avec, pour localiser celle choisie.

M'enfin, je repars sur de l'hybride...
casse tete ce truc...

[Ruz]

c'est à dire?

[phenix]

c'est à dire?

On ta montré un système simple, facile à mettre ne place et utilisé par beaucoup d'autres personnes.

Comme je suis bon je te remontre le système que j'ai moi mit en place:

Une table "Objet", elle contient toutes les informations sur les objet (Dégat, poind, prix etc...), c'est pratique car elle sert souvent, pas uniquement pour l'inventaire.

Une table "Inventaire" qui contient 4 champs:

id: Pour supprimé un objet bien précis.
id_objet: il relie inventaire et Objet.
id_joueur: pour relier l'objet au joueur.
equip: Vaut 1 quand l'objet est équipé et 0 quand il est dans le sac.

Si veux par exemple, gérer un système d'usure des objets, il suffit d'ajouté 1 champ 'usure' dans la table inventaire avec l'usure de l'objet...

C'est le meilleur système actuellement parce qu'il est léger et maniable.

[Cartman34]

Ce que j'ai proposé est simple et léger, car vous ne le faite qu'une fois et cela sera bien plus rapide que de sélectionner tous les objets d'une utilisateur parmis des milliers(ou des millions) surtout si vous utilisez des sessions.
J'en ai essayé d'autre, ce n'est pas la meilleure solution pour les objets prédéfinis(mine) dont on est sur que l'utilisateur va posséder mais dans le cas d'un inventaire c'est la meilleure solution, selon moi.
el[u]ox -> Erreur ! Vous faites un while pour chaque objet, je fais un foreach pour chaque objet...c'est équivalent. Tout le monde sait faire uen concaténation j'espère et le reste je l'ai donné.
phenix -> Aucune différence réelle de maniabilité, surtout en POO.

Ensuite, imagine que l'utilisateur ai 1000 objet dans son sac 65 tu fais un explode et tu obtient un tableau de 1000 composants ! Sa va faire lourd dans la mémoire tout sa...

Je sais pas si tu te rends compte de ce que tu dis...sélectionner 1.000 objets dans une table parmis des millions, tu crois que ca va etre plus rapide ?!

Satevis -> il est vrai que l'espace disque n'est pas vraiment ce qu'on paye cher en général, ce n'est pas le plus important pour moi. Seulement je pense cette solution beaucoup plus rapide pour le processeur, ca me parait en fait assez évident.