Discussion :

[Olorin]

Bonjour,
jusqu'à présent je faisais mes bdd mysql assorties de scripts php de façon totalement intuitive au fil du vent.

j'ai aujourd'hui un projet de site web de jeu qui me semble conséquent et justifier de la rigueur dans la démarche, j'ai donc entrepris de faire un MCD fonctionnel de ma base avant de m'intéresser ensuite au framework symfony pour tisser l'architecture de mon jeu en ligne...

voilà pour la petite histoire...

je rencontre une difficulté assez rapidement dans mon modèle :

j'ai deux entités : mobiliers et immobiliers où sont enregistrées les données relatives à ces objets (propriétaire, localisation...)

j'ai bien créer une association "posséder" avec une entité personnage pour poser le "propriétaire" de l'objet, là ça semble coller facilement, le problème vient de la localisation.

j'ai créé une entité lieu afin de recenser les différents lieux et par association ce qui s'y trouve, j'ai donc créé des associations du genre localiser mobilier, localiser immobilier, localiser personnage (je devrai peut-être d'ailleurs ne faire qu'une association localiser).

bref il se trouve que les "lieux" sont soit des "immobiliers" soit des "mobiliers" (conteneur)

j'ai donc pour résumer en prenant le cas du mobilier :

une entité mobilier, une entité lieux et deux associations reliant ces entités : une "localiser" et une autre "contenir"

mais j'ai l'impression de m'enliser à ce niveau, comment feriez vous pour modéliser le fait qu'un "bateau" faisant partie de l'entité "mobilier" peut contenir des "paniers" de la même entité mobilier, pouvant contenir lui aussi des "objets" faisant partie du "mobilier" ???

merci pour votre aide, désolez pour mon manque de clareté, je vais essayer de poster une vue de mon modèle

[CinePhil]

comment feriez vous pour modéliser le fait qu'un "bateau" faisant partie de l'entité "mobilier" peut contenir des "paniers" de la même entité mobilier, pouvant contenir lui aussi des "objets" faisant partie du "mobilier" ???

Autrement dit, tu as le schéma : Mobilier -0,n----Contenir----0,1- Mobilier C'est du même style que les chapitres contenant des sous-chapitres ou tout autre forme d'arborescence de données. Tu peux aller lire le tuto de SQLPro sur la modélisation des arborescences.

[Olorin]

Merci beaucoup effectivement la gestion par intervalles me semble une solution efficace pour ma table "Mobilier", un peu complexe à mettre en oeuvre surtout avec les procédures stockées avec lesquelles je suis peu à l'aise, mais on va s'y faire ;-)

en terme de MCD, comment le faire apparaitre dans mon schema ?

ci joint mon premier jet bordélique de MCD, des suggestions ? (ou des questions ? dès fois ça aide à voir les incohérences)

[CinePhil]

Remarques sur le MCD :
1) Compétences perso correspond en fait à une association entre pj et compétences.
pj -0,n----SaitFaire----0,n- competences
Ce n'est pas une entité et n'a donc pas d'identifiant propre. La clé primaire de la future table sera composée des clés des deux tables entrant en jeu dans l'association : idpj et idcomp.

2) Idem pour actionsperso.
A peut-être un bémol près : si un même perso peut faire plusieurs fois la même action, ou bien on ne mémorise que la dernière si c'est une association, ou bien on la transforme en entité si on veut mémoriser toutes les actions identiques.

Je vois par contre que la cardinalité côté pj est de 0,1 donc on n'enregistre que la dernière action du joueur ? En ce cas c'est vraiment idem 1).

3) Il manque la cardinalité côté lieux sur l'association locperso.
Idem côté mobiliers pour les associations locmobilier et contenumob

4) Les cardinalités côté pj sont difficiles à attribuer aux associations ; il semble y avoir un décalage.

5) Je trouve bizarre qu'une récolte puisse ne pas être localisée !
Idem pour un animal et un immobilier !

6) Un lieux ne peut localiser qu'un seul immobilier ?

7) Associations conteneurX.
Je pense qu'il s'agit de la partie du modèle qui te pose problème ?
Comme dit dans mon message précédent, pour le mobilier on a plutôt :
Mobilier -0,n----Contenir----0,1- Mobilier
Ce n'est donc pas une association entre lieux et mobilier.
Si un immobilier peut contenir d'autres immobiliers, c'est la même chose.

8) Un immobilier ne peut-il contenir un mobilier ?
Il pourrait y avoir une association entre immobiler et mobilier :
Immobilier -0,n----Contenir----0,1- Mobilier
A moins que ce soit implicite par le lieu.

9) Types des attributs.
Caractère variable (255) pour un sexe, n'est-ce pas exagéré (ou prétentieux ) ?
Ca me semble aussi beaucoup pour un nomperso ou un pseudojoueur.
Il manque probablement des attributs dans les entités animaux, mobiliers et immobiliers ?

10) Typage des animaux, des mobiliers et des immobiliers.
Tel que tu as fait ton MCD, un animal, un mobilier ou un immobilier n'existent qu'une fois. Il n'y aurait donc par exemple qu'un chat, qu'un chien, qu'une vache... dans ton jeu.
Ne faudrait-il pas typer ces entités ?
animaux -1,1----Typer----0,n- Race
mobilier -1,1----Typer----0,n- TypeMobilier
immobilier -1,1----Typer----0,n- TypeImmobilier

Bon courage pour la suite !

[Olorin]

pour les remarques 1 et 2, j'ai fait ainsi car :

un personnage peut avoir plusieurs compétences
il ne peut avoir qu'une action active à la fois

néanmoins je pense que tu as raison, en fait j'ai trop détaillé...

3- les cardinalités était mal affichées...

4- je n'ai pas bien compris ?

5- j'ai éviter les cardinalités minimales à 1 car poweramc a tendance a aouter des constraint à tout va ensuite, mais en toute logique effectivement à ce stade, un élément quel qu'il soit ne peut pas ne pas être localisé.

6- j'ai un dilemme là-dessus, dois-je faire qu'un lieu = un immobilier ou pas... that is the question lol, en soi cela ne serait pas genant je n'ai créé l'entité lieu que pour pouvoir localisé mes autres entités et établir des chemins entre les lieux, je dissocie les deux car il y a des immobiliers posséder par des personnages alors qu'un lieu ne l'est pas forcément

peut-être serait-il plus simple de fusionner les entités lieu et immobilier en une seule et que je crée un personnage "maitre du jeu" par exemple qui possède les lieux/immo non possédé par un personnage joueur...

ou tout simplement un attribut dans l'entité "immobilier" pour différencier les immo "joueur" des immo "non-joueur"

7 - 8 - même réflexion, me serait-je compliquer le modèle ;-)

9 - c'est de la fainéantise, j'ai pas vraiment raisonné mes attributs juste mis une valeur par défaut ne générant pas d'erreur à ce stade

10 - c'est pas fini mais effectivement c'est prévu

ci-joint le mcd "mis à jour"

une question (encore), ai-je une bonne démarche dans ma conception ?

[CinePhil]

pour les remarques 1 et 2, j'ai fait ainsi car :

un personnage peut avoir plusieurs compétences
il ne peut avoir qu'une action active à la fois

néanmoins je pense que tu as raison, en fait j'ai trop détaillé...

C'est mieux maintenant.

3- les cardinalités était mal affichées...

4- je n'ai pas bien compris ?

C'était un problème d'affichage pour le 4 aussi je pense, maintenant c'est bon.

5- j'ai éviter les cardinalités minimales à 1 car poweramc a tendance a aouter des constraint à tout va ensuite, mais en toute logique effectivement à ce stade, un élément quel qu'il soit ne peut pas ne pas être localisé.

C'est normal qu'il ajoute une clé étrangère avec une cardinalité maximale à 1 ! Ce n'est pas la cardinalité minimale qui pose problème ici, sauf que la colonne correspondante sera NOT NULL, ce qui est logique aussi.
En quoi cela serait-il gênant par la suite ?

6- j'ai un dilemme là-dessus, dois-je faire qu'un lieu = un immobilier ou pas... that is the question lol, en soi cela ne serait pas genant je n'ai créé l'entité lieu que pour pouvoir localisé mes autres entités et établir des chemins entre les lieux, je dissocie les deux car il y a des immobiliers posséder par des personnages alors qu'un lieu ne l'est pas forcément

peut-être serait-il plus simple de fusionner les entités lieu et immobilier en une seule et que je crée un personnage "maitre du jeu" par exemple qui possède les lieux/immo non possédé par un personnage joueur...

ou tout simplement un attribut dans l'entité "immobilier" pour différencier les immo "joueur" des immo "non-joueur"

Tout dépend ce que tu appelles "lieu". Sans connaître ton jeu, j'imagine la chose suivante :
- Lieux : Village, Campagne, Ville, Mer, Montagne
- Immobilier : Maison, Ferme, Appartement, Château...

D'ailleurs il s'agirait ici plutôt de types de lieux et de types d'immobilier qu'il faudrait ensuite instancier en objets distincts.
- Lieux : (Villages) Vatan, Trifouills les oies, Montcuq ; (Campagnes) Pays de Caux, Pays de Bray, Comminges, Lauragais...
- Immobiliers : Maison1, Maison2... Ferme1, Ferme2...

7 - 8 - même réflexion, me serait-je compliquer le modèle ;-)

Je pense que mon modèle est plus simple, et surtout plus adéquat pour les mobiliers.
Pour reprendre ton exemple de ton premier message, un Bateau est localisé en Mer Méditerrannée et contient un Pannier contenant des Oeufs. ce ne sont pas les oeiufs qui sont localisés dans le bateau (sinon ils vont se casser au premier roulis ! )

9 - c'est de la fainéantise, j'ai pas vraiment raisonné mes attributs juste mis une valeur par défaut ne générant pas d'erreur à ce stade

10 - c'est pas fini mais effectivement c'est prévu

OK

une question (encore), ai-je une bonne démarche dans ma conception ?

Ben ça me semble pas mal parti.
Ceci dit, tu pourrais commencer par écrire tes règles de gestion qui t'aideront à faire ton MCD. Là j'ai l'impression que tu tatonnes pour faire ton MCD au fur et à mesure que les idées te viennent.

[Olorin]

en fait les règles de gestion sont déjà posées mais pas fermées, en rédigeant le MCD, cela me permet de voir si les "règles" étaient ou pas cohérentes et de les modifier dans le cas contraire...

par exemple, j'aurai pu créer des "types d'objets" et faire une association "posséder" avec pour attribut "quantité", sauf que chaque objet sera unique par sa durée de vie afin de les supprimer quand durée de vie max atteinte...

au début je pensais que ce serait le personnage qui me generait en terme de données et en fait c'est son environnement car pour qu'il soit le plus cohérent et donc intéressant possible je me retrouve avec des données quasi similaires, associées de pleins de façon, c'est là que malgré les règles de gestion je m'emmêle les pinceaux ;-) (d'où ma présence ici d'ailleurs lol)

ton exemple pour lieux et immobiliers est correct par rapport au jeu visé, en fait en te lisant je réalise que mes lieux sont comme mes mobiliers, en arborescence...

dans l'absolu (je cherche à faire un moteur de jeu générique multi-univers), j'aurai :

Pays --> Villes (alpha, beta, ...) --> Quartiers (lieux n'appartenant à personne)

ensuite chaque quartier contiendra des immobiliers posséder par les joueurs

toutes mes difficultés se situe bien sur les notions de localisation et de conteneur, prenons l'exemple d'une donnée :

une récolte de type blé se situe soit dans :
- 1 immobilier (grenier)
- 1 mobilier (sac)

(l'ensemble de ces éléments sont possédés par un joueur)

le grenier est contenu dans un immobilier : la ferme A du joueur
le sac de blé peut lui être contenu dans d'autres immobiliers (entrepot, étal sur le marché) ou d'autres mobiliers (caisse, bateau, charrette)

ces différents éléments sont localisés dans différents lieux (quartier des fermes, quartier du marché, etc. ), eux mêmes localisés dans une ville, localisé dans un pays et dans l'absolu ensuite dans un monde...

voilà pour ce que me disent mes règles de gestion, du coup je me dis woaw ça fait un truc super compliqué en terme de données, car si j'ai bien suivi, il faut :
- que je différencie l'association "localiser" de celle "contenir"
- que je gère mes données par intervalles afin de tenir compte de l'arborescence que font mes données

est-ce que si je pose cela ainsi, je ne serai pas sur le bon chemin ?

types objets - 0,n --- définir obj --- 1,1 - objets - 0,n --- Contenir --- 0,1 - objets

types lieux - 0,n --- définir lieu --- 1,1 - lieux - 0,n --- Localiser --- 0,1 - lieux


j'ai l'impression d'avoir du mal à chaque fois qu'il y a une donnée qui doit interagir avec une donnée du même type, j'ai envisagé de séparer les "objets" contenant des objets "contenus", mais des contenants peuvent être aussi des contenus...

je crois que le premier lien que tu m'as donné résumé ma solution, il faut que je hiérarchise mes éléments mobiliers, récoltes, animaux, immobiliers en une seule entité "OBJETS" ce que j'avais fait au début d'ailleurs, idem pour les LIEUX, ensuite je verrai comment modéliser en MCD, d'abord faire l'arbre des contenu/contenants et celui des lieux

ce qui m'inquiète c'est la taille de ma table "objets"

bon j'arrête de réfléchir ici, je vais essayer de reposer mon schema en tenant compte des précieux conseils et observations que j'ai eu

[CinePhil]

prenons l'exemple d'une donnée :

une récolte de type blé se situe soit dans :
- 1 immobilier (grenier)
- 1 mobilier (sac)

Donc il y a aussi une association "Contenir" entre "récolte" et "lieu".

(l'ensemble de ces éléments sont possédés par un joueur)

Soit le joueur 1, le l'immobiler 2, le mobilier 3 et la récolte 4, il y aura les enregistrements suivants :
Dans la table immobilier (idimmo = 2, idpj=1...)
Dans la table mobilier (idmobilier=3, idpj=1...)
Dans la table récolte :
- soit (idrecolte=4, idpj=1, idimmobilier=2, idmobilier=NULL...)
- soit (idrecolte=4, idpj=1, idimmobilier=NULL, idmobilier=3...)

le grenier est contenu dans un immobilier : la ferme A du joueur
le sac de blé peut lui être contenu dans d'autres immobiliers (entrepot, étal sur le marché) ou d'autres mobiliers (caisse, bateau, charrette)

ces différents éléments sont localisés dans différents lieux (quartier des fermes, quartier du marché, etc. ), eux mêmes localisés dans une ville, localisé dans un pays et dans l'absolu ensuite dans un monde...

Je pense que tu commences à voir le principe, à toi de continuer sur ce chemin.

car si j'ai bien suivi, il faut :
- que je différencie l'association "localiser" de celle "contenir"

Ce n'est pas la même sémantique (localiser <> contenir). Mais le processus est le même.
Cependant, dans les deux cas, il va falloir peut-être gérer aussi les possibilités et où les incohérences :
- une voiture ne peut pas être contenue dans un tiroir (sauf si c'est un modèle réduit).
- une planète ne peut pas être localisée dans une ville
- une récolte ne peut pas être localisée dans la mer (ou alors elle est tombée du bateau et est perdue)

est-ce que si je pose cela ainsi, je ne serais pas sur le bon chemin ?

types objets - 0,n --- définir obj --- 1,1 - objets - 0,n --- Contenir --- 0,1 - objets

types lieux - 0,n --- définir lieu --- 1,1 - lieux - 0,n --- Localiser --- 0,1 - lieux

Ca me semble une bonne approche mais peut-être, comme je viens de le souligner, faut-il aussi prévoir la gestion des possibilités, un peu comme tu as fait pour les compétences des pj :
TypesLieux -0,n----PouvoirLocaliser----0,n- TypesLieux
TypesObjets -0,n----PouvoirContenir----0,n- TypesObjets
TypesObjets -0,n----PouvoirLocaliser----0,n- TypesLieux

ce qui m'inquiète c'est la taille de ma table "objets"

Tu verras ça à l'usage mais avant que ta table objets contienne des centaines de milliers d'objets, je crois que tu auras le temps de voir venir. Ca voudra dire que ton jeu a du succès et que tu auras les moyen de te payer un nouveau serveur plus performant.

[Olorin]

bon après réflexion, j'ai donc re-fusionné tous les objets en une seule entité puisque les attributs sont communs de toute façon

et lieux est bien une entité distincte car il ne sert qu'à localiser et non à contenir ou à être proprio

en tenant compte des remarques ça donne le mcd ci-joint...

c'est loin d'être fini car il me reste :

- l'historisation des actions et de pas mal de choses d'ailleurs, les joueurs aiment les stats et les historiques
- une entité batailles, 0,n joueur pouvant y participer et 2 joueurs pouvant la "coacher", l'idée est un peu celle d'une partie d'échec, seul deux joueurs coach les autres sont les pièces participantes...
- une entité quêtes qui doit faire intervenir des lieux, des personnages et des objets.

bref encore beaucoup de boulot

là j'espère déjà que le modèle joint me permettra de mettre en oeuvre la partie "économique" du jeu, les échanges donc, un petit e-commerce en ludique lol

[CinePhil]

Remarques sur ce nouveau MCD :
1) Association LocaliserObjet
Si un objet A est contenu dans un objet B qui est situé dans lieu L, le MCD impose (cardinalité 1,1) que l'objet A soit lui aussi situé dans le lieu L.
Il faudra y penser en programmation sous peine d'avoir des incohérences, ou alors changer la cardinalité en 0,1 de façon à ce qu'un objet contenu dans un autre ne soit pas situé.
Si par exemple je prends une hache située dans une ferme et que je la met dans mon camion, la situation de la hache doit passer à NULL puiqu'elle dépend directement de celle du camion qui va probablement se déplacer ailleurs qu'à la ferme où à été prise la hache. Pour que la situation de la hache puisse être à NULL, il faut une cardinalité 0,1.

2) Association ConduireA
Ces cardinalités 0,1 impsoent qu'un lieu ne peut conduire à un autre qu'une seule fois.
Je pense qu'il faut plutôt des cardinalités 0,n.

[Olorin]

merci effectivement, cela rajoutais encore des soucis ;-)

là j'ai commencé à ajouter des entités au modèle, en espérant que cela ne devienne pas une usine à gaz, je posterai le mcd étendu pour avis dès qu'il aura bien avancé.

je repense aux soucis d'incohérence, effectivement je vais devoir ajouter sans doute une entité/association "peut contenir" car j'avais anticipé la notion de taille un camion ne peut être contenu par un panier, chaque objet ayant une caractéristique TAIlle, je comptais poser un test lors du déplacement d'objet qui devait comparer si TAI du contenu =< TAI dispo du contenant, mais tu as soulevé une autre incohérence non lié à la taille mais à la nature de certaines relations...

un liquide ne peut être contenu dans un panier par exemple, cependant logiquement si je pose la structure hiérarchique des objets par intervalle, je poserai ça par ordre de TAI et je peux aussi trier par type de contenant/contenu, exple :

niv A : 1 caisse 20
niv B : 2 panier 15 | 16 sac 17 | 18 jarre 19
niv C : 3 fruits 4 | 5 légumes 6 | 7 céréales 8 | 9 farine 10 | 11 lait 12 | 13 vin 14

si j'ai bien compris les histoires d'intervalle...

ainsi si je pose (je ne sais où) qu'un niv supérieur peut contenir un niveau inférieur mais pas l'inverse, ça devrait résoudre les soucis d'incohérence non ?

faut-il le faire apparaitre dans le MCD et si oui sous quelle forme ?

edit : faisant un break sur mes données je me suis penché sur la question de mon code à venir et comme je compte utiliser le framework symfony (php) je me suis intéressé à UML et je me demande du coup si je n'aurai pas intérêt à modéliser mon application web en uml ? (je n'en ai jamais fait mais bon si c'est mieux ;-) )

[CinePhil]

ainsi si je pose (je ne sais où) qu'un niv supérieur peut contenir un niveau inférieur mais pas l'inverse, ça devrait résoudre les soucis d'incohérence non ?

Bien que j'aie trouvé la technique très intéressante, je n'ai encore jamais eu à utiliser les intervalles de SQLPro. Mais, de mémoire, je pense en effet que ça devrait pouvoir fonctionner sans peine avec ce principe.

[/quote]faut-il le faire apparaitre dans le MCD et si oui sous quelle forme ?[/quote]
J'ai l'impression qu'on approche plutôt du côté dynamique, ce qui n'est pas représentable dans le MCD.
Par contre, rien n'interdit d'ajouter du texte au MCD pour formuler certaines contraintes (unique, > telle valeur...).

edit : faisant un break sur mes données je me suis penché sur la question de mon code à venir et comme je compte utiliser le framework symfony (php) je me suis intéressé à UML et je me demande du coup si je n'aurai pas intérêt à modéliser mon application web en uml ? (je n'en ai jamais fait mais bon si c'est mieux ;-) )

J'ai voulu moi aussi m'initier à Symphony il ya quelques temps, après avoir assisté à une conférence démo, mais j'ai trouvé ça trop lourd pour ce que je voulais faire. Je ne suis pas encore mû pour les framework je crois !

Quant à UML, je maîtrise un peu le diagramme des classes mais quasiment pas le reste alors pour le moment, Merise me suffit bien.

[Olorin]

yep je crois que je vais me borner également au diagramme de classes qui devrait me suffire pour mes objets php ensuite...

bon bé je continue sur ma lancée alors ;-)

[Olorin]

je m'interroge toujours sur mon modèle, notamment sur les objets car j'ai le sentiment que je ne réponds pas à tout avec le modèle général précédemment joint.

voici un copier-coller de mon listing non-exhaustif des "définitions" du jeu

- un joueur peut créer un personnage et un seul, il peut s'authentifier pour accéder/personnaliser à son interface de jeu et gérer son personnage

- un personnage peut agir : discuter (mp, chat... ambigu avec action du joueur), échanger des objets, combattre, embaucher/travailler pour un autre, récolter des objets, fabriquer des objets, se déplacer, prier

- un objet = immobilier, mobilier, personnage non joueur
- un immobilier = ressources naturelles, résidence, atelier, ferme, étal de marché, stockage, bâtiments publics

* ressources naturelles = différents noms selon la ressources a récolter
* résidence = différents noms selon la taille de la demeure (tente au palais)
* atelier = différents noms selon l'objet fabriqué (boulangerie, vannerie, boucherie, etc.)
* ferme = différents noms selon l'objet produit (céréales, animaux)
* étal de marché = étal de marché
* batiments publics = différents noms partageant le propriétaire : administration

- un mobilier = le produit d'un immobilier par l'action d'un personnage qui est possédé par un personnage
- un personnage non joueur = un personnage non joueur

- un lieu = un monde -> des pays -> des villes -> des zones (résidentielle, productive, échange, administrative)

l'entité objet partage bien des attributs communs pour les trois grands catégories que j'ai isolé, immobilier, mobilier et pnj mais il y a des associations avec le personnage qui sont distinctes par contre et j'ai un peu peur à la complexité du modèle au final

ne serait-ce pas là une situation pour créer trois entités par héritage de l'entité objet ?

ainsi je pourrai créer les associations spécifiques :

un personnage ne peut combattre qu'un pnj parmi les objets
il ne peut récolter qu'un mobilier

on en revient aux risques d'incohérence évoqués précédemment si je ne me trompe ?

soit je fais des distinctions dans le mcd, soit je continue dans la logique de tri par intervalles et de règles associées ?

ça me perd un peu cette histoire d'intervalles même si ça semble totalement adapté ;-)

[Olorin]

j'ai essayé d'ajouter mes dernières réflexions à mon modèle, ça tient la route ?

[Olorin]

plutôt que d'ouvrir un nouveau sujet je continue ici ;-)

nouvelle interrogation, lié au mcd précédent :

- j'ai une entité objet, chaque objet étant unique
- une entité type d'objet pour désigner les objets uniques par leur type

jusque là rien d'inhabituel mais, un petit exemple :

un sac de blé est un type d'objet, chaque sac de blé est identifié (idobjet) et a un propriétaire lambda

lambda possède 50 sacs de blé...

je vais ajouter une entité "échanger objet" cf MCD ci-joint

mais du coup si je continue mon exemple :

lambda va échanger 25 sacs de blé (dont les identifiants sont totalement dispersés dans la table objet), il va en demander X qté d'un type d'objet...

quand la transaction va être validé je vais devoir scripter une recherche par idunique de chaque objet faisant partie du lot de 25 (idem pour l'acheteur d'ailleurs)

ça fait pas une usine à gaz un tel modèle ?

et quel modèle serait si c'est le cas adapté à la possibilité d'échanger des objets uniques en eux-même mais multiple par leur type ?

[CinePhil]

Ca me semble effectivement une usine à gaz !

Je distinguerais les objets uniques (arme spéciale, véhicule immatriculé, trésor unique dans le jeu, maison...) des objets multipliables (sacs de blé, pièces, tomates, oeufs, litres de carburant...).
Ainsi il suffit de mémoriser la quantité des objets multipliables au lieu de l'id d'un objet unique ou existant en petite quantité limitée dans le jeu et donc identifiable individuellement.

Ainsi, s'il n'y a que 3 bateaux dans le port et que 5 joueurs veulent se rendre sur l'île en même temps, il faut bien identifier individuellement chaque bateau.

Par contre je fais le plein de carburant pour le bateau en achetant 100 litres de gasoil pour une somme de 200 pièces par exemple.

Si tu connais les jeux du type Age of Empire ou Pharaon Reine du Nil, c'est un peu le principe : Tu disposes de ressources multipliables pour construire des bâtiments uniques ou des navires uniques qui ont leur vie propre (ils peuvent se dégrader, brûler..., de manière individuelle).

Pour en revenir au modèle et selon le principe que je viens de décrire, j'ajouterais un attribut au TypeObjet disant s'il est unique ou multipliable. Ensuite, les objet de type unique sont identifiables par un id et les objets multipliables mémorisent la quantité possédée par le joueur au lieu de l'id. Dans les deux cas c'est un entier.

[Olorin]

ma réflexion me menait effectivement dans cette direction, mon dilemme vient surtout du fait que chaque objet a une durée de vie qui lui est propre afin de disparaitre quand son temps est venu ;-)

de plus je souhaite que la monnaie soit aussi un objet, histoire de bien compliquer les choses

du coup tes suggestions me solutionne l'affaire (encore merci)

dans type d'objet je vais créer un attribut pour unique ou multiple et un autre pour périssable ou pas et dans objet les attributs vie et quantité ne seront actifs que si le type le précise...

ainsi mes 25 sacs de blé s'ils ont été créé au même moment feront un objet "sac de blé" "périssable:vie=..." "multiple:qté=..." et lors d'un échange le propriétaire pourra mettre à l'échange tout ou partie de ce lot

dans le cas de pièces de monnaie qui n'auront pas l'attribut périssable, je pourrai ainsi juste augmenter la quantité sans ajouter un nouvel objet

ça me semble tenir la route ?


(ps : mon jeu est un mixte des age of empire, pharaon-like et jeu de role que j'ai pratiqué autrefois sur table ;-) )

[CinePhil]

ça me semble tenir la route ?

[Olorin]

j'ai changé de logiciel car à l'épreuve de la conversion en bdd poweramc bof bof

j'ai donc opté pour open model sphere que j'aurai utilisé dès le début si je l'avais connu car il est open source donc moins cher que poweramc et m'a l'air plus puissant et surtout plus à jour que poweramc 11 que j'avais dans un coin ;-)

bref ça donne l'image jointe mais le vérificateur d'intégrité me donne des avertissements qui me chiffonne car les cardinalités me semblaient bonnes

un peu de temps pour me relire ?

* AVERTISSEMENTS

________________________________________________________________________________________
Les relations binaires suivantes ont des erreurs (avertissements) de navigabilité.
________________________________________________________________________________________
définir lieu* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
localiser item* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
localiser personnage* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
coacher A* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
coacher B* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
posséder item* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.