JeuWeb (JeuPHP) - Crée ton jeu par navigateur

Mais ça évite les jointures que l'on te dit

Rohhh ta finis de te moquer, méchant .

Je crois que tu as bien compris IGstaff .

IGstaff a écrit :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

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.

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.

Voilà ce que je ferais...et sans aucune autre table cependant tu peux toujours enregistrer la liste des objets dans une table et/ou ajouter d'autres informations dans cette chaîne.

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

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 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 ?

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.

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...

Casse tête simplement parce que tu ne veux pas avoir un modèle de données propre et éprouvé