Discussion :

[Sereine]

Bonjour, il y a quelques temps je me suis embarquée dans un petit jeu en php. Le problème c'est que plus j'avance, plus c'est fouillis, du coup je reprend à la base pour refaire quelque chose de propre.

J'ai mis sur papier tout ce que mon site/jeu va faire, et j'en ai fait une conception MCD. Si j'ai bien tout pigé, c'est l'étape qui précède la création de la base de donnée. Et le diagramme de classe.

Voilà le schéma, il doit surement être bourré de fautes ^^' si vous pouviez me donner un coup de main pour me les pointer du doigt, se serait sympatoche.

(l'image étant grande je met un lien)
http://nsa33.casimages.com/img/2013/...2617809300.png

[frm013]

Bonjour Sereine,

Je n'y connais pas grand chose en matière de jeu, j'ai donc du mal à interpréter votre diagramme.

J'ai mis sur papier tout ce que mon site/jeu va faire

Ce serait pas mal de le publier, cela permettrait, je pense, de comprendre plus vite.

Je vous suggère également de faire figurer un dictionnaire des attributs utilisés dans votre MCD. Du moins ceux qui doivent l'être:

Classe_nom on voit bien, classe_dex beaucoup moins

Quelques règles de gestion pour expliquer comment doivent interagir les entité-type de votre diagramme me plairait assez

Exemple:
RG01 : Un utilisateur écrit peut écrire zéro ou plusieurs annonces.
et ainsi de suite...

Il y a un expert Merise qui passe souvent dans cette partie du forum, je pense qu'il en aura besoin. Il s'appelle François aussi, ne confondez pas, je ne suis pas expert en la matière. Mais si je peut aider, je le ferai avec plaisir.

Cordialement,
François

[Sereine]

Bonjour et merci pour le commentaire, ça fait plaisir.
j'avais quelques erreurs que j'ai corrigé après une relecture, je modifie le lien plus haut: http://nsa33.casimages.com/img/2013/...2617809300.png

Pour la lecture du document:

Seul certains comptes pourront créer des annonces (les admins, mais je ne l'ai pas spécifié pour le moment, juste qu'une annonce est écrite par un utilisateur, mais tous les utilisateurs n'ont pas forcément écris d'annonces. Celle ci a une catégorie et images associés.

Un utilisateur créera des logs à chaque action. et lorsqu'il se connecte tout simplement.

Un utilisateur pourra créer un personnage, et un personnage appartient forcément à un utilisateur. Les utilisateurs ne sont jamais détruit, tandis que les personnages peuvent être supprimés.
(pour libérer les noms notamment)

Ce personnage est caractérisé par des attributs (int, str, dex, vit, ce sont des caractéristiques correspondant à l’intelligence, la force, dextérité, vitalité). Il est forcément associé à une race, cette race va lui permettre d'accéder à 2 skills raciaux, ce sont des compétences comme pour les skills de classe, mais spécifique à la race.
En choisissant une race, cela permet d'accéder au choix de certaines classe. (donc toutes les races ne permettent pas d'accéder aux même classe, les classe sont par exemple ninja, mage, ect ... les races: elfes, humains, ...)
(un personnage orc pourra devenir guerrier, berserker, ou lancier par exemple, mais ne pourra pas devenir prêtre, ninja, .. tandis qu'un humain le pourra .. )

Une fois la classe et la race choisis, le personnage aura accès à un panel de compétences, mêlant skills raciales aux skills de classe.

Le personnage pourra avoir des quêtes, durant le jeu, il y a donc un suivi de quête. Une quête attribué au personnage portera un status, en cours, terminé, ...

Un personnage aura un inventaire, cet inventaire pourra contenir des items. Certains items pourront être portés, comme les armures, armes, ils seront indiqué comme étant is_wear dans l'inventaire.

Dans le jeu, le personnage aura à combattre des monstres, ces monstre ont une certaine force, point de vie, et ils peuvent droper, à leur mort, certains items, et de l'argent.

Dans le jeu, il y aura une carte, cette carte est découpé en zone. Le personnage est donc attribué à une zone et pourra se déplacer de zones en zones.
Dans les zones, il y aura des lieux, ces lieux peuvent être des lieux de chasses, des habitations, grottes, ou des villes. En allant dans une ville, le personnage pourra acheter certains items à certains prix.

voilà, je pense avoir tout dis, il manque des choses, mais pour le moment ceci est la base du jeu, j'aimerais partir d'une base propre déjà ^^.

[tse_jc]

Bonjour,

Concernant tout d'abord vos dernières remarques, le besoin de suppression de personnage(s) pour libérer des noms sous entends le caractère unique d'un nom de personnage, chose n'apparaissant pas au niveau de votre modèle.

Ensuite, concernant les monstres il me semble que ce sont à la base des personnages qui sont censés avoir des attributs qui leur sont propres et qui ont la particularité d'être "non joueurs" ou PNJ comme on dit. Ces attributs seront essentiels de manière à déterminer un rapport de force entre deux personnages et un gagnant lors d'un combat, enfin me semble-t-il.

Concernant les skills (aptitudes/capacités) elles n'ont visiblement pas de modèle propre concernant la façon dont elles agissent sur les caractéristiques d'un personnage: Créent-elles de nouveaux attributs spécifiques ou agissent-elles comme un modificateur de caractéristiques existantes? Ceci n'apparaît pas dans votre modèle ainsi que les relations pouvant exister entre elles et les caractéristiques de l'entité personnage.

Concernant les quêtes, votre modèle ne renseigne pas s'il existe des quêtes récurrentes (journalières par exemple) ou d'autres non récurrentes pouvant être exécutées par le personnage qu'une seule fois ou plusieurs fois malgré tout.

Concernant les relations entre les personnages, les races et les classes, rien ne garantie dans votre modèle qu'un personnage ait une classe autorisée par sa race et d'ailleurs la dépendance fonctionnelle entre une race et une classe n'apparaît pas dans votre modèle.

Je pense que de mettre à plat toutes vos règles de gestion comme il vous a été demandé de fournir - vu leur étendue potentielle - ne serait pas superflu et vous aiderait à y voir plus clair, et nous permettrait de pouvoir contrôler la pertinence de votre modèle à notre niveau.

Jc

PS: Il y aurait beaucoup à dire sur la gestion des items également, mais je pense qu'il y a déjà suffisamment de choses avec ce qui précède dans un premier temps.

[tse_jc]

Bonjour,

Si vous me permettez de plus un conseil, pour ce genre de projet d'envergure, je définirais pour le moins deux modèles de données, l'un servant de référentiel à l'autre que l'on pourrait appeler "modèle de production" par exemple.

++

[Sereine]

Bonjour,

Concernant tout d'abord vos dernières remarques, le besoin de suppression de personnage(s) pour libérer des noms sous entends le caractère unique d'un nom de personnage, chose n'apparaissant pas au niveau de votre modèle.

Ensuite, concernant les monstres il me semble que ce sont à la base des personnages qui sont censés avoir des attributs qui leur sont propres et qui ont la particularité d'être "non joueurs" ou PNJ comme on dit. Ces attributs seront essentiels de manière à déterminer un rapport de force entre deux personnages et un gagnant lors d'un combat, enfin me semble-t-il.

Concernant les skills (aptitudes/capacités) elles n'ont visiblement pas de modèle propre concernant la façon dont elles agissent sur les caractéristiques d'un personnage: Créent-elles de nouveaux attributs spécifiques ou agissent-elles comme un modificateur de caractéristiques existantes? Ceci n'apparaît pas dans votre modèle ainsi que les relations pouvant exister entre elles et les caractéristiques de l'entité personnage.

Concernant les quêtes, votre modèle ne renseigne pas s'il existe des quêtes récurrentes (journalières par exemple) ou d'autres non récurrentes pouvant être exécutées par le personnage qu'une seule fois ou plusieurs fois malgré tout.

Concernant les relations entre les personnages, les races et les classes, rien ne garantie dans votre modèle qu'un personnage ait une classe autorisée par sa race et d'ailleurs la dépendance fonctionnelle entre une race et une classe n'apparaît pas dans votre modèle.

Je pense que de mettre à plat toutes vos règles de gestion comme il vous a été demandé de fournir - vu leur étendue potentielle - ne serait pas superflu et vous aiderait à y voir plus clair, et nous permettrait de pouvoir contrôler la pertinence de votre modèle à notre niveau.

Jc

PS: Il y aurait beaucoup à dire sur la gestion des items également, mais je pense qu'il y a déjà suffisamment de choses avec ce qui précède dans un premier temps.

Tout d'abord, merci pour la réponse.
Ensuite, le logiciel que j'utilise est très basique, il permet pas de faire apparaitre un champ comme étant unique. Donc oui, le nom du personnage doit être unique, de même pour l'identifiant de l'utilisateur.

Pour les monstres, oui c'est une sorte de personnage en simplifié (pas de race, classe, ni de dex, vit ect ... juste des dégats et point de vie) mais je me vois mal mélanger les joueurs et les monstres

Alors je l'ai pas spécifié, mais il y a des branches de mon schéma qui ne sont pas très développé, car je voulais rester dans le simple, histoire que déjà ce qui est en place soit correct.

Donc oui, comme tu as pu le constater, pour les skills, j'ai juste mis bêtement un bloc skill, car justement, la gestion des actions d'un skill, ou d'un item consommable par exemple est un petit peu farfelu, ce que j'avais fait à l'époque, j'avais mis un bloc 'attribut', dans lequel il y avait le nom de l'attribue, le 'buff_time', histoire de savoir si c'est un skill avec action immédiate ou sur plusieurs tour, et "action" qui était la méthode qui allait être appliquée lors de l'utilisation de cet attribut. Le bloc skill aurait eu la propriété en plus 'value_attribut' un truc comme ça, où on aurait la valeure du skill. J'ai rien trouvé de mieux que ça :/
Donc un skill peut être du dégat brut, un skill passif qui va modifier des attributs sur une durée limitée, ect ect ...

Je n'ais pas encore réfléchis à comment faire évoluer les compétences, enfin j'ai plusieurs systèmes en tête, je laisse ça de côté pour le moment. j'ajouterais ça comme une "évolution", lorsque je me serais décidé.

Pour les quêtes, pour le moment je souhaite mettre des quêtes très simples qui se déclenche au passage de niveau du personnage, donc non répétable, ni de quête journalière.


"Concernant les relations entre les personnages, les races et les classes, rien ne garantie dans votre modèle qu'un personnage ait une classe autorisée par sa race et d'ailleurs la dépendance fonctionnelle entre une race et une classe n'apparaît pas dans votre modèle."
C'est ce qui me posait problème, comment je fais apparaitre la relation?

Deux modèles, je veux bien, mais j'ai aucune idée de ce dont vous parlez?

[tse_jc]

Bonjour,

La tâche est ardue et il est important de rester dans le contexte de réalisation d'un MCD qui se doit de se contenter de définir les caractéristiques primaires de chaque entité qui le compose et de définir le type et la nature des relations existants entre ces mêmes entités.

Pour ce faire il est important au préalable de bien définir la mécanique de votre jeu, comme par exemple votre système de combat. Est-il à tour (round de combat) unique ou peut-il y en avoir plusieurs (le combat se termine dès qu'un personnage n'a plus de vie)? S'il y en a plusieurs par exemple la notion de caractéristique primaire appliquée à votre entité skill pourrait être:

- id du skill
- nom du skill
- Type de skill (buff/debuff/sort)
- Casting time (temps de lancement, t=0 correspondant à un skill instantané)
- Duration (la durée exprimée dans l'unité de temps primaire de votre système de combat)
- Cooldown (le temps de recharge exprimé dans la même unité de temps que la durée) correspondant au temps nécessaire pour que le skill soit à niveau disponible.
- type de dégâts (physique, magique, mixte)

Ensuite si vous introduisez une notion d'energie (le mana pour les magiciens, la rage pour les guerriers par exemple), une autre caractéristique primaire pour l'entité skill pourrait être les points d'energie requis à son utilisation.

Si votre système de combat change, la définition d'une telle entité doit être adaptée en conséquence. Comment vous dire donc tant que les règles de gestion de votre jeu en amont de l'entité skill ne sont pas en place, si votre modèle est cohérent? difficile vous vous en doutez.

Dans ce genre d'application, comme dans beaucoup d'autres types d'applications, un schéma servant de référentiel aux entités de production est plus que salutaire, donc le plus souvent indispensable. Dans un tel schéma par exemple vous définissez toutes les valeurs de référence de votre application (paramétrage):

exemple: les valeurs des caractéristiques de base des personnages en fonction de leur race, classe et niveau, idem pour les objets (items) et les types d'objets (communs, rares, épiques, légendaires par exemple).

Ensuite à partir de là, au niveau du schéma de production, seules sont conservées les caractéristiques primaires (représentant des valeurs calculées à partir du schéma de référence) définies pour le jeu ex: Azmodée, personnage non joueur de classe X et de race Y et de niveau Z.

J'espère avoir éclairé votre lanterne suffisamment sur ces points.

[Sereine]

Oui, je me doute qu'il faut tout poser à plat avant de commencer quoi que ce soit, mais, avant de pousser mon schéma plus loin, j'aimerais que la base soit déjà bien solide, j'ai déjà un soucis avec le noeud 'classe, race, skill', j'ai un peu du mal à voir comment faire pour que ma relation soit comme je l'entends.

Pour ce qui est du combat, il s'agit d'un combat tour par tour avec un choix à chaque tour pour l'utilisateur d'effectuer une attaque simple, d'utiliser une compétence, d'utiliser un objet, ou de fuir le combat.

Pour le bloc skill j'imaginais bien quelque chose comme ça.

En faite je voulais mettre en place une base solide, que je complexifie au fur à mesure. (vu que déjà rien qu'avec cette base là je fais des erreurs .. )

[frm013]

Bonjour Camille,

Je comprend un peu mieux les choses.

j'ai déjà un soucis avec le noeud 'classe, race, skill', j'ai un peu du mal à voir comment faire pour que ma relation soit comme je l'entends.

A ce sujet, il y a des choses que je ne comprend pas.

Un personnage, une race ou une classe comportent les même attributs ( intelligence, la force, dextérité, vitalité ).

Cela veut dire que sans avoir choisi de race, un personnage possède déjà ces caractéristiques? Ca ne me semble pas logique.

Puisque que ces attributs se retrouvent dans race et classe, comment gérez vous cette redondance quand ils sont associés? Une moyenne, une addition, la plus forte valeur?

Le fait de choisir d'intégrer les caractéristiques au sein des entités-type ( personnage, race et classe) ne sera-t-il pas limitant par la suite si vous souhaitez en rajouter?

D'autre part comment gérer les niveaux mini maxi de ces caractéristiques?
Il s'agit bien de nombres si j'ai bien compris?

Quand est-il de tout ça?

A bientôt,
François

[tse_jc]

Bonjour,

Les questions de frm013 sont fondées et je pense sincèrement qu'à ce stade sereine n'a pas encore pris de décision à ce niveau.

Sinon pour répondre à la question de la relation entre les personnages, races et classes voici comment je verrais les choses pour une première approche.



Une autre approche viable consisterait à intervertir la race et la classe dans chaque branche (les noms pas leur définition), avec pj_race_nom qui devient pj_classe_nom et classe_nom qui devient race_nom. Ainsi au lieu d'associer à un personnage une classe à travers sa race, on lui associerait une race à travers sa classe tout en conservant dans les deux cas les dépendances fonctionnelles souhaitées.

EDIT: je fournis tout de même le nouveau MCD correspondant à la nouvelle association

[tse_jc]

D'autre part comment gérer les niveaux mini maxi de ces caractéristiques?

Personnellement j'opterais pour une contrainte de domaine.

[frm013]

Bonjour,

Just une petite question...
Jean-Christophe, que sont les entités-type PJ et PNJ ?

Cordialement,
François

[tse_jc]

Bonjour,

Oui excusez-moi, j'ai oublié de préciser, PJ corresponds à personnage joueur (entité personnage modèle initial de camille) et PNJ personnage non joueur (entité monstre modèle initial de camille).

++

[frm013]

D'accord, j'y avais pensé, mais je n'étais pas sûr.

Je pense que ces schémas anticipent beaucoup sur la pensée de Camille

Mais effectivement, nous aurons peut-être à généraliser ces deux entités-type.

J'attends que Camille nous en dise un peu plus sur le domaine étudié.

A bientôt,
François

[Sereine]

Bonjour, désolé je suis pas trop sur le pc le week end ^^.

Alors, tout d'abord merci pour vos réponses.

En ce qui concerne les attributs: str, int, ... en gros une race possède des attributs qui lui son propre, de même pour la classe, et lorsqu'un personnage est caractérisé par une classe et une race, on lui ajoute les attributs de la classe et de la race. Et vu qu'à chaque niveau il gagnera des points d'attribut à distribuer, je voulais pas alourdir le code avec trop de calcul et je préfere donc que soit noter les attributs du personnage, dans le bloc personnage.

Ensuite, le problème était plus situé dans la relation avec les skills.
Du coup là, la table skill, vous la mettez comment? car j'ai pas envie que ce soit hyper redondant.

Par contre je comprend pas trop le noeud d'héritage entre personnage et pnj, c'est une façon d'écrire, mais le résultat de la base de donnée sera le même que ce que j'avais mis non? après rajouter à un pnj une race et une classe, .. j'en vois pas l'utilité =x

Pour les niveaux mini et maxi des caractéristiques, la gestion se fera dans le code, je vois pas comment le mcd peut gérer ça?!

[tse_jc]

Bonjour,

en gros une race possède des attributs qui lui son propre, de même pour la classe, et lorsqu'un personnage est caractérisé par une classe et une race, on lui ajoute les attributs de la classe et de la race. Et vu qu'à chaque niveau il gagnera des points d'attribut à distribuer, je voulais pas alourdir le code avec trop de calcul et je préfere donc que soit noter les attributs du personnage, dans le bloc personnage.

Je vous rappelle qu'il s'agit ici de la modélisation conceptuelle de vos données, on en est pas à travailler au niveau du code applicatif pour le moment. Il n'y a donc pas de calcul à prendre en compte mais à définir comment les caractéristiques d'un personnage sont définies ainsi qu'à définir leur relations avec les différentes entités de votre modèle applicatif.

Ensuite, si ce sont les seules raisons qui vous ont fait placer les caractéristiques dans l'entité personnage, ce sont de mauvaises raisons.

En effet, dans le postulat suivant

...Et vu qu'à chaque niveau il gagnera des points d'attribut à distribuer...

cette notion de niveau est actuellement totalement absente de votre modèle. Or on ne sait pas par exemple si ces points à attribuer se font en fonction de la race ou de la classe, tout comme votre modèle actuel ne permet pas de déterminer les relations existantes entre la race, la classe et un personnage au niveau de ces caractéristiques.

Ensuite, en ce qui concerne la détermination des valeurs minimum et maximum de ces caractéristiques, elles peuvent parfaitement être définies et contrôlées au niveau de votre modèle mais sous forme de règles de gestion (définition/validation) uniquement à ce stade et qui seront exprimées en SQL (contraintes/triggers) au niveau de votre Modèle logique.

Ensuite, le problème était plus situé dans la relation avec les skills.
Du coup là, la table skill, vous la mettez comment? car j'ai pas envie que ce soit hyper redondant.

Déjà si votre crainte est d'avoir de la redondance, j'ai bien peur que vous n'ayez que mal compris le but du modèle conceptuel de données et donc de l'exercice actuel : il s'agit de normaliser vos données et par voie de conséquence d'éliminer toute redondance en son sein, faut-il encore que votre modèle respecte la FNBC (forme normale de Boyce-codd). Je vous invite à vous documenter sur ce forum sur le sujet à travers les cours de SQLpro ou de fsmrel.

En ce qui concerne la table skill, si vous ne savez pas encore comment représenter l'héritage en SQL je vous invite à consulter ce cours de SQLpro
http://sqlpro.developpez.com/cours/m...tion/heritage/ qui reste très bien fait.

après rajouter à un pnj une race et une classe, .. j'en vois pas l'utilité

L'intérêt est pourtant majeur. Il permet d'uniformiser les règles de votre système de combat ainsi que de l'intégrer à votre modèle. Si vous ne faites pas ainsi, comment allez-vous gérer les éventuels skills spécifiques de vos monstres dans un combat? au niveau applicatif?

Pour les niveaux mini et maxi des caractéristiques, la gestion se fera dans le code, je vois pas comment le mcd peut gérer ça?!

Une contrainte de domaine peut être définie et déclarée au niveau du dossier conceptuel détaillé associé à votre modèle, puisque l'ensemble des règles de gestions doivent y être définies.

++

[frm013]

Bonjour,

Je commence à y voir plus clair et pouvoir vous proposer quelque chose

Une petite question, une CLASSE peut-elle être associée à plusieurs RACEs ?

A bientôt,
François

[Sereine]

Oui, une classe peut appartenir à plusieurs races.

Je vais donner un exemple concret, se sera plus simple.

On va dire qu'il y a 3 races et 5 classes disponible.

Races: Nain, elfes et humains
classes: gardiens, berserker, mage, prêtre, assassin.

Races choisis: Nain
Classe disponible: Gardien, berserker, assassin

Race choisis: Elfe
Classe disponible: mage, prêtre, assassin

Race choisis: Humain
classe disponible: prêtre, gardien, berserker, mage, assassin

(c'est un exemple)

Et pour les skills, admettons:

skill raciaux (qui sont des skills passif affectant des caractéristiques ou aptitude):

Nain
- Maitrise de la forge
- Petite taille

Elfe
- Sagesse
- Ami de la nature

Humain:
- Protecteur
- Force


Et pour chaque classe:

prêtre:
- Soin
- Bénédiction
- Epée de la lumière
gardien
- Bouclier impérial
- Charge
- Cri de guerre
berserker
- Berserk
- Epée renforcée
- Vive attaque
mage
- Boule de feu
- Bouclier glacial
- Torrent de glace
assassin
- Furtif
- Embuscade
- Morsure du serpent

Ainsi un nain - gardien aura comme skill:
- maitrise de la forge
- petite taille
- Bouclier impérial
- Charge
- Cri de guerre

[frm013]

Dans l'affirmative, voilà ce que je peux proposer comme ébauche.

J'ai conservé l'héritage pour les montres, je pense que nous en aurons besoin par la suite.

Une RACE est spécialisée en une ou plusieurs CLASSEs
Une CLASSE est caractérisée par un ou plusieurs ATTRIBUTs (intelligence, force, dextérité, vitalité ) ayant une valeur initiale propre à cette classe.
Chaque ATTRIBUT possède une valeur minimale et maximale.

Au cours du jeu un ROLE gagne de la valeur sur une ou plusieurs caractéristique de sa CLASSE.



J'ai supprimé l'association entre ROLE et CLASS qui, pour moi, est redondante car on peut connaitre la RACE d'un ROLE par sa CLASSE.

J'ai un doute concernant la méthode Merise, peut-on ajouter des attributs a l'identifiant d'une entité-type héritée...
Si des spécialistes passe ici...

Des remarques?

François

[dimesto]

monstre-gold me semble mal placer également il sous entend que pour chaque item un montre dropera une certaine somme d'argent en supplément.
pourquoi pas le metre directement dans monstre comme vous l'avez fais pour personnage. de plus je soutien l'idée d'un héritage si cela vous gène utiliser une chaine de charactère comme clé primaire avec une première lettre comme déterminant .
example P pour personnage, M pour monstre.

de plus avec un héritage le drop des monstre peut être représenté par un inventaire . ce qui est en soit logique .