Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Discussion: Modélisation d'un MMORPG [MCD]

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut Modélisation d'un MMORPG

    Bonjour,

    Je suis en train de faire un brouillon pour ma base de données, c'est pour un jeu type mmorpg.
    D'après ce que j'ai vu sur le net, j'ai par exemple ceci comme tableaux :

    "Joueurs"
    -joueur_id

    "Items"
    -item_id

    "Inventaire_des_Joueurs"
    -joueur_id
    -item_id
    -place_de_l_item_dans_l_inventaire (slot_nbr)

    Et donc je me retrouverais avec un tableau "Inventaire_des_Joueurs" qui recenserait tous les items dans les inventaires de tous les joueurs et le fait que la table soit indexée fera que me requête trouvera plus facilement les objets d'un joueur en particuliers, c'est bien ça ?
    Quelqu'un peut m'éclaircir la dessus ?
    Est-ce qu'il y a d'autres méthodes pour lier deux tableaux entre eux ?

    Merci.

  2. #2
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Disons que je ne sais pas vraiment comment bien organiser la hiérarchie de ma base de données.

    Par exemple pour un personnage, je peux avoir :
    -headgear_id
    -armor_id
    -legs_id
    -gloves_id
    -boots_id

    Et donc, est-ce qu'il est mieux d'avoir un tableau pour chaque type d’équipement ?
    Ou est-ce que j'dois faire juste un tableau pour tous l'équipement et l'ajouter au personnage en fonction de l'id aussi ?
    Ou est-ce que j'dois faire un tableau pour regrouper l'équipement du joueur et ensuite l'ajouter au joueur ?
    Les pièces d'équipement sont aussi des items, dans quelles mesure je les différencie des items non équipable ? (un booléan est suffisant mais concrètement dans la base, je ne sais pas encore comment l'organiser hiérarchiquement)
    Combien bien utiliser les indexes là dedans ?

    Je pense que je dois trouver le bon compromis entre le nombre de tableaux utilisés mais aussi le nombre de variables qu'un tableau pourra contenir si je veux optimiser les performances dans le cas où il y aurait pleins de joueurs mais comme je débute, je ne connais pas trop les meilleurs méthodes ou comment la base de données peut se comporter selon telle ou telle conditions.
    Je n'utilise pas de 3D pour mon jeu donc il y a des calculs avec lesquels je n'ai pas besoin de me prendre la tête mais comme la base de donnée sera aussi utilisé pour la persistance du monde, ça me laisse perplexe.

  3. #3
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    Bonjour,

    J'ai l'impression que ton problème est un cas typique d'héritage de données.

    Tous les items ont au moins un identifiant en commun et les différents types d'items ont des propriétés propres (matière du gant, rapidité des jambes, force des armes...).

    Donc on modélise de cette manière...

    1) Règles de gestion des données
    R1 : Un gant est un item et un item peut être un gant.
    R2 : Une arme est un item et un item peut-être une arme.
    ...

    2) Modèle conceptuel de données (MCD)
    Gant -(1,1)----être----0,1- Item
    Arme -(1,1)----être----0,1---|
    ...

    3) Tables de la BDD (et non pas tableau)
    te_item_itm (itm_id, [colonnes communes à tous les types d'items])
    th_gant_gnt (gnt_id_item, [colonnes spécifiques aux gants])
    th_arme_arm (arm_id_item, [colonnes spécifiques aux armes])
    ...
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  4. #4
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 467
    Points : 11 088
    Points
    11 088
    Billets dans le blog
    1

    Par défaut

    Bonsoir,

    Sujet original, qui nous change un peu, du coup je lui souhaite longue vie

    D'accord avec ce que propose CinéPhil, j'ajoute que l'emplacement appartient à un contenant ou sac
    OBJET 1,1 --- situer --- 0,n EMPLACEMENT (1,1) --- appartenir --- 1,n CONTENANT

    Ci-dessus, je propose d'utiliser l'identification relative de l'emplacement par rapport au contenant : sans contenant, pas d'emplacement, l'emplacement est donc une entité-type dite "faible" (d'où les parenthèses autour des cardinalités)

    Et une remarque d'ordre général : si la BDD est développée et maintenue par des francophones, alors utilisez des termes français (objet, arme, gant, conteneur) si elle est sous la responsabilité d'anglophones, utilisez des termes anglais (item, weapon, glove, container). Ne mélangez pas anglais et français. Ici je parle des objets de la BDD (entités-type et associations qui deviendront des tables, attributs qui deviendront des colonnes).

    Concernant les noms des objets affichés dans le jeu, c'est un autre sujet, il faudra, le cas échéant, prévoir une traduction dans chacune des langues des pays dans lesquels vous prévoyez une diffusion du jeu.
    Nous n'en sommes pas encore là

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    J'y vois un peu plus clair mais je n'ai pas encore tout compris.
    Faut que je fasse des essaies sur papier ou avec MySQL workbench, ça fait beaucoup de liaisons logiques possibles mais comme on peut les établir de différentes manière, je m'y perds un peu entre le factuel et le dynamique.


    Je mets tout en anglais dans la db, j'ai beaucoup de choses à prévoir avant de penser à une traduction.
    Citation Envoyé par CinePhil
    3) Tables de la BDD (et non pas tableau)
    Et je me demandais si on le traduisait ou pas. lol

    Merci.

  6. #6
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 467
    Points : 11 088
    Points
    11 088
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par noals Voir le message
    Faut que je fasse des essaies sur papier ou avec MySQL workbench
    Attention : MySQL Workbench ne permet pas de réaliser un MCD mais seulement un MLD, pas idéal donc pour valider les règles de gestion


    Citation Envoyé par noals Voir le message
    Je mets tout en anglais dans la db, j'ai beaucoup de choses à prévoir avant de penser à une traduction.
    En ce cas ce que vous avez mentionné dans votre 1er message n'est pas cohérent (au passage, les noms des entité-types doivent être au singulier : une entité-type caractérise toutes les occurrences d'entité )
    Citation Envoyé par noals Voir le message
    "Joueurs" PLAYER
    -joueur_id Player_id

    "Items"
    -item_id

    "Inventaire_des_Joueurs" PLAYER_INVENTORY
    -joueur_id Player_id
    -item_id
    -place_de_l_item_dans_l_inventaire (slot_nbr)

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Après réflexion, je vais designer mon inventaire comme ceci :

    avec un contenant A:
    Player_X_items
    -item_id
    -item_nbr

    Je fais une nouvelle table pour l'inventaire de chaque joueurs, ça sera plus simple pour récupérer les infos du coté de mon serveur et ça évitera des calcules inutiles pour le moteur de postgresql.
    exemple simplifié :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    string Player_X_item = "Player_" + player_id + "_item";
    SELECT * FROM Player_X_item;
    Pour l'équipement d'un joueur, je n'ai pas de problème car le nombre de slot d'équipement est assez limité mais je n'ai pas spécialement l'intention d'imposer une limite de taille à l'inventaire d'un joueur.

    avec un contenant B:
    Players_Item
    -player_id
    -item_id
    -item_nbr

    Ça m'embête parce que je vais me retrouver avec une table qui comprend tous les items de tous les joueurs et comme l'on se sert d'un inventaire plutôt régulièrement dans un jeu, j'ai l'impression que ce serait trop de calcules pour le moteur de postgresql à cause du manque d'organisation que ces lignes auront dans la table et la fréquence à laquelle le programme devra y accéder.
    D'où peut-être l'utilisation d'indexes mais je n'ai toujours pas bien compris leur utilité.


    avec un contenant C:
    Player_Item
    -player_id
    -item_1
    -item_2
    -item_3
    -item_n

    Et là, j'ai en gros une table avec pour colonnes tous les items existants dans le jeu et l'inventaire du joueur est défini de cette manière dans la db:
    "player_id= 123; item_1=0, item_2=1; ...; item_13=20; item_n=2;"
    pour récupérer les items du joueurs, je n'ai qu'à récupérer toute les valeurs non null en gros mais pareil, j'trouve pas ça vraiment optimisé, ça ferait beaucoup de colonnes pour une table.


    Disons que j'essaye de penser le plus possible à minimiser les calcules que le moteur de postgresql devra effectuer parce qu'il devra aussi se charger d'une partie de la persistance du monde.
    Qu'en est-il pour les indexes ?

  8. #8
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 467
    Points : 11 088
    Points
    11 088
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par noals Voir le message
    Je fais une nouvelle table pour l'inventaire de chaque joueurs, ça sera plus simple pour récupérer les infos du coté de mon serveur et ça évitera des calcules inutiles pour le moteur de postgresql.
    Soit vos propos sont mal formulés, soit vous vous engoufrez dans une impasse : une table par joueur serait une hérésie !

    Citation Envoyé par noals Voir le message
    Ça m'embête parce que je vais me retrouver avec une table qui comprend tous les items de tous les joueurs et comme l'on se sert d'un inventaire plutôt régulièrement dans un jeu
    Vous mettez la charrue avant les boeufs, ou plutôt les tables avant la conceptualisation.
    Vous devez commencer par les règles de gestion, inspirez vous de la réponse n°3 de CinéPhil dans laquelle il en a mentionné quelques unes.
    Une fois que ce sera fait, il sera facile d'établir le MCD dont on dérivera sans effort le MLD c'est à dire les tables

  9. #9
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    Je fais une nouvelle table pour l'inventaire de chaque joueurs
    Et si vous avez un jour 100 000 joueurs... vous aurez 100 000 tables ? Totalement irréaliste !

    Ne soyez pas inquiet des "calculs" à faire par PostgreSQL. Les SGBD travaillent de manière ensembliste sur des masses de données qui peuvent être considérables (plusieurs millions, voire dizaines de millions de lignes dans une table) sans difficultés à condition que la BDD soit correctement modélisée et correctement indexée.

    Les index, on verra plus tard. Pour le moment, concentrez-vous sur la modélisation des données !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Les SGBD travaillent de manière ensembliste sur des masses de données qui peuvent être considérables (plusieurs millions, voire dizaines de millions de lignes dans une table) sans difficultés à condition que la BDD soit correctement modélisée et correctement indexée.
    ha d'accord parce que oui, je vois le problème de cette manière. Par exemple j'ai 1000 joueurs, qui ont chacun 100 items différents bah ça fait déjà 100000 lignes dans ma table qui ne sont pas ordonnées et qui de plus nécessite un calcul supplémentaire pour chaque requête dans le sens où je récupère mon infos grâce à l'id du joueur alors que je l'aurai déjà en mémoire en quelque sorte, j'ai trouvé ça énorme et comme la méthode de merise parle de n'utiliser que le strict nécessaire, j'ai trouver ma solution logique.
    Je récupère une simple liste des ids des items avec leur quantité et je peux très bien avoir une copie de la liste des items coté client pour faire la correspondance.
    Je considère que c'est une approche plus synergique par rapport au reste de mon application mais je comprend l'hérésie d'avoir des tonnes de tables à utilisation restreinte. ^^

    Je vais continuer à designer ma db avec le "contenant B" pour les inventaires du coup, je reposterais plus tard pour montrer le résultat et en savoir plus à propos des indexes.

  11. #11
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    À titre d'exemple... Il y a une dizaine d'années, j'ai créé une base de données à l'INRA pour un thésard qui étudiait le marché des bovins. Il avait récupéré 2 années de mouvements de bovins (naissance, ventes...) en France.
    Dans mes tables, il y avait 65 millions de mouvements de plusieurs millions de bovins et quelques milliers d'éleveurs et intermédiaires du marché.
    Avec cette BDD correctement modélisée, des requêtes avec de multiples jointures et des calculs ne prenaient au plus que quelques petites secondes sur un simple PC portable de l'époque. La BDD était sous MySQL qui est loin d'être la plus performante.

    Donc pas d'inquiétude. 100 000 lignes dans une table, c'est petit pour un SGBDR.


    Donc...
    1) Règles de gestion des données
    2) MCD
    3) MLD
    4) Création de la BDD
    5) Développement de l'application.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Il y a quoi comme bons logiciels gratuits pour effectuer des MCD ?
    Et si possible qui fonctionne avec postgresql et qui tourne sous windows et linux.

    J'en ai vu quelque uns et ce n'est pas la première fois que la question est posée sur le forum mais si je dois donner mon nom, prénom, mail, numéro de tel ou je ne sais quoi d'autre pour pouvoir télécharger un logiciel gratuit, ça ne donne pas vraiment envie donc autant que ce soit avec Le bon logiciel si vraiment je dois le faire.

    Merci.

    edit : Je vais tester looping qui ne fonctionne pas avec linux mais au moins je peux en faire ce que je veux, j'avais téléchargé db-main mais quand j'ai vu que la licence n'était valable que 1 mois, je l'ai désinstallé.

  13. #13
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    En vrac et rapidement...

    JMerise ( pas tout à fait gratuit maintenant mais très peu cher)
    DBMain
    Open Modelsphere (s'il existe encore)
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  14. #14
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Oui, j'ai vu le sujet après sur le forum.
    Looping ne fonctionne pas sous linux (ou alors avec wine) mais je peux toujours récupérer les requêtes sql donc ça me convient, merci.

  15. #15
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Je me pose une question par rapport à ça :
    Citation Envoyé par CinePhil
    3) Tables de la BDD (et non pas tableau)
    te_item_itm (itm_id, [colonnes communes à tous les types d'items])
    th_gant_gnt (gnt_id_item, [colonnes spécifiques aux gants])
    th_arme_arm (arm_id_item, [colonnes spécifiques aux armes])
    ...
    en résulat, j'ai donc une table comme ça ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    item_id | gloves_id | boots_id
    0            0            NULL
    1            1            NULL
    2            NULL         0
    3            NULL         1
    J'ai besoin de différencier 17 type d'item en 4 catégories car je m'y perd un peu avec les variables qui peuvent définir les items.

    Actuellement, j'avais dans l'idée de faire mes catégories, donc 4 tables comme ceci
    i_usable
    -id (0-999)
    i_weapon
    -id(1000-8999)
    i_key_item
    -id(9000-9999)
    i_armor
    -id(10000-16999)

    Comme ça, si dans le jeu, un joueur reçois un item, l'item est reconnaissable par son id.
    Je peux faire une fonction dans mon programme genre:
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    if(item>=0 && item<999) item=i_usable;

    Le truc, c'est que j'ai pas mal de différences possible entre items de différentes catégories mais que les items d'une même catégories ont bien sur des point communs.
    Par exemple une weapon aura toujours une valeur d'attaque, ce qui ne se retrouve pas dans les autres catégories.
    Je ne sais pas si avoir une table intermédiaire pour regrouper tous les items me sera forcément utile, j'essaye de m'en tenir au strict minimum.
    Qu'en pensez-vous ?

  16. #16
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 4 467
    Points : 11 088
    Points
    11 088
    Billets dans le blog
    1

    Par défaut

    Bonjour,

    Citation Envoyé par noals Voir le message
    en résulat, j'ai donc une table comme ça ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    item_id | gloves_id | boots_id
    0            0            NULL
    1            1            NULL
    2            NULL         0
    3            NULL         1
    Certainement pas !
    l'identifiant des gants ou des bottes n'est bien sur pas commun à tous les objets...
    Ce qui peut être commun c'est : le nom de l'objet, son niveau d'équipement, le nombre d'emplacements occupés...
    Avec l'héritage, la notion d'identifiant de gants, de bottes ou de tout autre type d'objet n'existe pas. Avec l'héritage, l'identifiant du sous-type est le même que celui du sur-type, en l'occurrence item_id.
    Autre chose qui pourra être vue ultérieurement : il est fréquent dans les jeux que les équipements puissent bénéficier d'un "bonus de set" : plusieurs équipements d'une même collection ont une valeur supérieure si équipés simultanément.
    Gardez cette notion sous le coude pour l'instant


    Citation Envoyé par noals Voir le message
    J'ai besoin de différencier 17 type d'item en 4 catégories car je m'y perd un peu avec les variables qui peuvent définir les items.

    Actuellement, j'avais dans l'idée de faire mes catégories, donc 4 tables comme ceci
    i_usable
    -id (0-999)
    i_weapon
    -id(1000-8999)
    i_key_item
    -id(9000-9999)
    i_armor
    -id(10000-16999)

    Comme ça, si dans le jeu, un joueur reçois un item, l'item est reconnaissable par son id.
    Je peux faire une fonction dans mon programme genre:
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    if(item>=0 && item<999) item=i_usable;
    Vous vous préoccupez prématurément des tables et des fonctions.
    Procédez avec méthode, d'abord les règles de gestion, puis le modèle conceptuel, puis les tables et en toute fin, les traitements.

  17. #17
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Ça devient vite le bazar si j'essaye d'écrire toutes les règles dont j'ai besoin, ça m'aide d'avoir un visuel un peu plus concret.

    J'étais pas trop mal parti, j'utilisais simplement une colonne "item_type" pour définir le type d'item donc oui, par rapport aux sets d'équipement dans les autres jeux, ça tombe sous le sens mais c'est mes "skill" et "effect" par item qui m'ont perturbé à cause des "script" car je sais pas encore comment je vais scripter mes "skill" ou "effect" dans le jeu donc oui, j'm'y perd un peu à cause des fonctions dont je me préoccupe.
    Si je prend exemple sur la db de planetshift, ils ont une table "item_stats" avec une soixantaine de colonnes mais je ne sais pas comment ils gèrent leurs fonctions ingame donc ça me perturbe.

    Si je devais écrire une règle de gestion ce serait un truc du genre :
    factuel 1,1 être 0,1 dynamique (1,n) être 0,1 fonction ingame

    Je vais continuer sur ma lancé, écrire m'aide toujours à y voir plus clair dans tous les cas, merci.

  18. #18
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    Si je devais écrire une règle de gestion ce serait un truc du genre :
    factuel 1,1 être 0,1 dynamique (1,n) être 0,1 fonction ingame
    Ce n'est pas une règle de gestion !
    C'est, à la rigueur, un morceau de MCD sous forme texte.

    Une règle de gestion décrit la nature de l'association entre deux éléments. C'est une phrase !

    Exemples :
    R1 : Un personnage possède un à plusieurs items et un item peut appartenir à plusieurs personnages.
    => La règle R1décrit l'association entre personnage et item.

    R2 : Une arme est un item et un item peut être une arme.
    => La règle R2 décrit l'association entre item et arme. Il s'agit ici de la description d'une association de type spécialisation qui entraînera un mécanisme d'héritage de données.

    Donc, une fois de plus, commencez par écrire des règles de gestion claires selon les exemples ci-dessus et revenez nous voir avec quelques règles de gestion. On passera ensuite au MCD. Chaque chose dans l'ordre, quand on débute, sinon vous allez droit au chaos !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  19. #19
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2007
    Messages
    117
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2007
    Messages : 117
    Points : 19
    Points
    19

    Par défaut

    Oui, je me suis trompé mais j'avais bien "règles de gestion" en tête quand j'ai écrit :
    Ça devient vite le bazar si j'essaye d'écrire toutes les règles dont j'ai besoin, ça m'aide d'avoir un visuel un peu plus concret.
    Je veux bien écrire quelques règles mais y'en a beaucoup trop, ça m'embrouille plus qu'autre chose.


    un item peut être une weapon (8 types d'armes différents...) une weapon peut être une épée, une hache, un arc, etc...
    une weapon peut être une arme à deux mains (qui occupe les deux emplacement d'arme à la place d'un seul)
    un item peut être une armure (7 types différents..)
    un item peut être un key_item
    un item peut être un usable
    un item peut être équipé
    une weapon peut avoir une skill
    une weapon a un effect (j'entend aussi par là, un modificateur de stat, ou une valeur d'attaque)
    un effect peut être temporaire
    une armure peut avoir une skill
    une armure a un effect
    un usable peut avoir une skill
    une skill peut avoir un effect

    c'est sans fin....

    disons que comme vous dites, une règle de gestion décrit la nature de l'association entre deux éléments mais alors quand il y a un lien entre 3 ou 4 éléments ?
    y a-t-il une limite qui dit que justement, si il y a trop de liens c'est que la hiérarchie est mal définie ?

    avec un visuel, je vois ce qui cloche, les valeurs qui se répètent ou les incohérences, c'est pour ça que j'ai les fonctions en tête mais des fois ça m'embrouille aussi.

    Nom : db_test.png
Affichages : 112
Taille : 59,1 Ko

    ci joint mon premier brouillon (j'en fait un deuxième en ce moment) mais déjà là, c'est trop grand pour que ça tienne à l'écran et que ça reste visible alors si je commence avec les règles de gestion de tout ça, j'vais jamais m'en sortir.

    edit: le truc coupé en haut, c'est les "skill" et justement, je me demandais si c'était pertinent ou pas d'en faire une seule table avec les "effect" car ils ont a peu près la même utilité mais il y a beaucoup de paramètres à prendre en compte donc ça me laisse aussi encore un peu perplexe pour l'instant.

  20. #20
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 122
    Points : 32 104
    Points
    32 104
    Billets dans le blog
    6

    Par défaut

    un item peut être une weapon (8 types d'armes différents...) une weapon peut être une épée, une hache, un arc, etc...
    Vous allez encore un peu trop vite !

    un item peut être une weapon
    => Il manque la contraposée : ... et une weapon est un item.

    Ce qui permet de construire le morceau de MCD suivant :
    weapon -(1,1)----être----0,1- item

    Il s'agit d'un héritage de données.
    Les cardinalités entre parenthèses indiquent une identification relative. C'est à dire que weapon n'a pas d'identifiant propre ; elle hérite de l'identifiant de item. le weapon 12 sera l'item 12 et vice versa.

    (8 types d'armes différents...)
    Si ces différents types d'armes ont des propriétés différentes, alors vous pouvez de nouveau faire un héritage de ce type...

    Règles de gestion :
    Une sword est une weapon et une weapon peut être une sword.
    Une axe est une weapon et une weapon peut être une axe.
    ...

    Revoyez les explications détaillées dans mon message #3 pour savoir si l'héritage est utile et pertinent ou s'il faut seulement typer les items, s'ils ont tous les mêmes propriétés (futures colonnes de la table des items).

    D'après votre MCD, il semble que tous les items soient munis de la même collection d'effets. Est-ce vraiment le cas ?

    un item peut être un key_item
    C'est quoi un "key_item" ?

    un item peut être équipé
    "équipé" semble être une propriété d'un item (de certains types d'items) et non pas un type d'item au même titre que sword, axe... Il n'y a donc aps de règle de gestion décrivant une association à écrire pour ça. Il faut juste ajouter la propriété "equiped" à item si ça s'applique à tous les items ou à weapon si ça s'applique à tous les weapons mais pas aux autres types...

    une weapon peut avoir une skill
    Idem... skill est une propriété de weapon et non pas un type de weapon à distinguer des autres. S'il y a une liste définie et limitée de skills, alors il faut créer une entité type pour skill dans votre MCD et écrire complètement la règle de gestion puis le morceau de MCD pour l'assication entre weapon et skill.

    Règle de gestion :
    Une weapon peut avoir une skill et une skill peut être possédée par plusieurs weapons.

    MCD :
    weapon -0,1----avoir----0,n- skill

    un effect peut être temporaire
    Il semble que "temporaire" ce soit une propriété d'un effect. Donc il faut ajouter "temporary" à votre entité-type "effect".

    Bref, j'espère que vous comprenez le principe.

    Repartez de zéro en y allant très progressivement. Tant que ce ne sera pas plus clair, il sera difficile de vous aider efficacement.


    Autres remarques sur votre schéma...
    1) Nommez vos entités-types au singulier.
    Ça évitera des ambiguïtés évetuelles et une entité-type est la symbolisation d'UNE chose de votre domaine de données.
    Dans les règles de gestion, on considère chaque entité-type au singulier : Une weapon (...) et un item (..)

    2) Pas de multiples propriétés pour la même notions (color1 à color5 dans hero).
    Écrivez la règle de gestion :
    Un hero est colorié de 5 colors et une color peut colorier plusieurs heros.

    => MCD :
    color -0,n----colorier----5,5- hero (s'il y a bien 5 colors obligatoires pour tout hero).

    3) Ne mettez pas les clés étrangères dans le MCD (ex. hero_id dans user).
    Les clés étrangères n'arrivent qu'au moment de la génération du Modèle Logique de Données (MLD) qui représentera vos tables.

    4) De la même façon, ne créez pas vos "tables associatives" dans le MCD (ex. hero_skill).
    Mais vous pouvez avoir des associations porteuses de données comme c'est le cas pour l'exemple cité.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 4 1234 DernièreDernière

Discussions similaires

  1. Réponses: 1
    Dernier message: 18/07/2018, 21h34
  2. [Toutes versions] Comment lier deux Combobox entre eux ?
    Par létudiant_access dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 22/02/2013, 14h27
  3. Lier deux combobox entre eux
    Par zabdaniel dans le forum Windows Forms
    Réponses: 2
    Dernier message: 23/02/2009, 10h06
  4. Filtrer une table en comparant deux champs entre eux
    Par damene dans le forum Débutant
    Réponses: 13
    Dernier message: 12/04/2008, 19h10
  5. Réponses: 14
    Dernier message: 13/11/2007, 19h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo