Il est clair que l'utilisation d'un tableau, avec toutes une série de concaténation et la solution la plus simple à mettre en oeuvre mais alors dès qu'il s'agit de manipuler ses données cela va vite devenir un enfer et je vous parle pas de l'intégrité des données. De plus, la structure de contrôle foreach est la plus longue en terme de temps de traitement; pour atteindre le temps de traitement d'un while ou d'un for vaut mieux utiliser cette combinaison : while(list($key, $value, ...) = each())
Comme le dit Oxman, les données sont dynamiques, de ce fait la base de données est la solution la plus sûre et surtout la plus évolutive et manipulable.
Toutefois, discuter, argumenter, contre-argumenter pour ceci et pour cela n'est pas suffisant. Je ne vois aucunement de modélisation de toutes ses argumentations, les dessins sont tellement plus facile à comprendre :haha:
Commençons par structurer l'idée :
On a besoin d'un objet Joueur, forcément sans joueur pas de jeu.
On a besoin d'un objet Inventaire, pour stocker les objets que ramassera le joueur.
On a besoin d'un objet Objet, forcément sans objet pas d'inventaire.
A partir de ce moment là, Ruz, on remarque une chose c'est que tu as fait un amalgame entre inventaire et équipement.
On a donc besoin d'un objet Equipement pour gérer ce que porte le joueur et surtout gérer plus aisément l'usure des objets.
On se retrouve donc, avec 4 tables pour la base de notre modélisation.
Joueur(id, nom, email)
Objet(id, type, `sous-type`, crc1, crc2, etc...)
Inventaire(id, #id_Joueur, #id_Objet, quantite, usure)
Equipement(id, #id_Joueur, #id_Inventaire, usure)
Vous me direz mais comment gère-t-on les dégâts car c'est bien là le problème du sujet initiale.
Tout d'abord posons-nous la question de comment nous allons reconnaitre cet objet usé d'un autre même objet non usé, cela se fait de façon simple, les objets pouvant comporter de l'usure ne sont pas empilable car sinon la distinction devient impossible. Ce qui revient à dire les armures et les armes ne doivent pas être empilable.
Modélisation :
![[Image: exemple_u1218195124.png]](http://upload.jeuweb.org/uploaded/exemple_u1218195124.png)
Maintenant, est-ce que cette démarche répond au problème ?
Comme le dit Oxman, les données sont dynamiques, de ce fait la base de données est la solution la plus sûre et surtout la plus évolutive et manipulable.
Toutefois, discuter, argumenter, contre-argumenter pour ceci et pour cela n'est pas suffisant. Je ne vois aucunement de modélisation de toutes ses argumentations, les dessins sont tellement plus facile à comprendre :haha:
Commençons par structurer l'idée :
On a besoin d'un objet Joueur, forcément sans joueur pas de jeu.
On a besoin d'un objet Inventaire, pour stocker les objets que ramassera le joueur.
On a besoin d'un objet Objet, forcément sans objet pas d'inventaire.
A partir de ce moment là, Ruz, on remarque une chose c'est que tu as fait un amalgame entre inventaire et équipement.
On a donc besoin d'un objet Equipement pour gérer ce que porte le joueur et surtout gérer plus aisément l'usure des objets.
On se retrouve donc, avec 4 tables pour la base de notre modélisation.
Joueur(id, nom, email)
Objet(id, type, `sous-type`, crc1, crc2, etc...)
Inventaire(id, #id_Joueur, #id_Objet, quantite, usure)
Equipement(id, #id_Joueur, #id_Inventaire, usure)
Vous me direz mais comment gère-t-on les dégâts car c'est bien là le problème du sujet initiale.
Tout d'abord posons-nous la question de comment nous allons reconnaitre cet objet usé d'un autre même objet non usé, cela se fait de façon simple, les objets pouvant comporter de l'usure ne sont pas empilable car sinon la distinction devient impossible. Ce qui revient à dire les armures et les armes ne doivent pas être empilable.
Modélisation :
Maintenant, est-ce que cette démarche répond au problème ?
![[Image: mielwar.ban.png]](http://mielwar.z3d-conception.com/img/special/mielwar.ban.png)