Discussion :

[tse_jc]

Bonjour

@Sereine
Quelques précisions s'il vous plaît, pour les nains, s'agit-il de maîtrise de la force ou maîtrise de la forge? car pour ce dernier cela sous-entends la spécialisation d'un rôle (modèle de françois) en 1 ou plusieurs métiers avec encore des compétences spécifiques.

@françois
votre modèle ne tiens pas compte de la notion de niveau, il me paraît donc inexact sur ce point.
Il me paraît également dangereux dans votre modèle de ne plus faire apparaître la dépendance fonctionnelle entre une classe et une race. En effet, dans le contexte où les caractéristiques de base d'un assassin elfe peuvent être différent d'un assassin nain, il faudrait alors rétablir cette dépendance fonctionnelle au niveau de l'entité caractéristique sous peine de ne pouvoir distinguer techniquement un assassin elfe d'un assassin nain les deux se retrouvant alors avec le même identifiant de classe, chose que vous ne faites pas, toujours selon votre modèle.

@sereine
Ensuite concernant l'ajout de points en fonction du niveau du joueur pour ses caractéristiques, deux cas de figure
1) Soit ce nombre de points à ajouter est constant quelque soit le niveau, et il n'est pas nécessaire de le modéliser
2) Soit il peut être variable (ce qui me paraît plus logique) et alors il est nécessaire de les intégrer dans votre modèle.

Merci donc de confirmer votre besoin à ce niveau, car si le 2) permet de gérer tous les cas de figure, choisir le 1er cas empêche toute modification du cahier des charges à postériori.

++

[frm013]

Bonjour Jean-Christophe,

Mon message s'est croisé avec la réponse de Camille

Effectivement, pour l'instant, Camille n'a pas préciser de règle concernant les niveaux, je n'en ai donc pas tenu compte.

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

Mon schéma est à corriger sur ce point après les précisions apportées par Camille.
Je souhaitait faire démarrer le débat avec un premier modèle partiel sur le point qui la gène le plus. Ses critiques permettront de mieux comprendre.
Il faut qu'elle s'approprie le schéma, n'allons pas trop vite

Nouveau schéma donc :



Dans l'attente de vos remarques Camille,
François

[Sereine]

oulala merci ! , même si ça de vient un peu compliqué pour moi ^^'.

Il s'agit bien de maîtrise de la forge, j'entends par là qu'il y aura des notions de craft, et je n'ai encore aucune idée de son fonctionnement. En fait j'aimerais que mon jeu soit évolutif et qu'on puisse ajouter des modules, comme le craft, plus tard.
Là, vu que je sais pas encore comment je compte faire fonctionner le craft, je ne l'ai pas mis dans le modèle.

Pour le modèle de françois, je ne comprend pas trop ce que signifie 'rôle' ?

Pour l'ajout de point par niveau, ça va être simple, ce sont les points de la classe + race qu'on ajoute à chaque niveau pour augmenter les caractéristiques primaire du personnage, + des points à distribuer, que le personnage peut allouer à ces caractéristiques. Ces caractéristiques auront donc une limite, histoire d'obliger le joueur à répartir ses points
Pour le moment je le vois comme ça.

[frm013]

Role = personnage dans votre schéma.

Maintenant que vous en parlez, on aurais put avoir ROLE en haut:

Personnage est un type de role, monstre est un type de role.
C'est peut-être plus logique, à vous de voir.

[Sereine]

Ah ok je comprend mieux ^^
Avec quoi faites vous vos schéma? j'aime bien le votre, françois.


J'essaierais de refaire tout ça avec.

[frm013]

J'utilise, JMerise, mais c'est par défaut d'autre chose, il n'est pas complètement au point ou ergonomique sur certains points.
Ce n'est pas une critique, car développer ce genre d'outil gratuitement n'est pas un boulot simple

Je ne fais pas suffisamment de modélisation pour justifier le prix de logiciels comme PowerAMC ou WinDesign.

Et vous quel est le votre à propos?

N'hésitez pas à me poser vos questions si mon schéma n'est pas clair à vos yeux.

François

[Sereine]

Je suis en train de refaire le schéma avec Jmerise (qui est bien pratique), je comprend mieux le fonctionnement de l'héritage.

Par contre, ce que je comprend pas, c'est son utilité dans ce cas précis.

En gros, au lieu d'avoir juste 2 tables avec des colonnes commune, j'ai 3 tables, dont une table qui rassemble les colonnes commune.
Pour le MCD c'est joli, propre ect, mais en utilisation, ça va me faire modifier 2 tables à chaque fois? En faite j'aimerais qu'on m'explique ce qui est optimisé dans ce cas là avec l'héritage.

Je m’aperçoit d'un autre soucis qui me semble bizarre lorsque je passe du mcd au mld.
Le compte User est crée avant le personnage, un User peut exister sans personnage donc. En revanche un personnage ne peut pas exister sans compte User. d'où la relation 0,1 --- 1,1
Et dans le MLD, dans la table User, il m'affiche comme clé étrangère, la clé primaire de l'identity assosié au personnage (player). Du coup bah je suis bloquée, à la création de compte, il va me demander une clé étrangère qui n'existe pas?
Je comprend pas pourquoi il me met ça?

[tse_jc]

Bonjour,

Tout simplement car pour maintenir la relation

User 0,1 --> 1,1 player

il vous faut placer la référence de l'utilisateur dans la table player au niveau MLD et non pas l'inverse.

Si vous souhaitez plus tard donner la possibilité à vos clients d'avoir plusieurs players, et donc transformer la relation 1,1 en 1,n, il vous faudra passer par une table de jonction.

++

[frm013]

Bonjour Camiile,

Concernant l'héritage, dans un projet comme le votre il y a de grande chances qu'il y ait des règles ou attributs communs aux personnages et aux monstres, d'ou la généralisation en Role (entity dans votre schéma).
Mais je pense que Jean-Christophe et moi-même sommes allé trop vite.

Consultez au besoin l'article de SqlPro au sujet de la modélisation par l'héritage

Pour le MCD c'est joli, propre ect, mais en utilisation, ça va me faire modifier 2 tables à chaque fois? En faite j'aimerais qu'on m'explique ce qui est optimisé dans ce cas là avec l'héritage.

Cela se gère bien avec des vues, mais j'ai bien peur que si vous utilisez MySql ( ce qui je pense est le cas ) ce soit plus difficile, je ne connais pas MySql assez bien pour ce cas.

Je m’aperçoit d'un autre soucis qui me semble bizarre lorsque je passe du mcd au mld.

Je n'utilise plus JMerise pour générer des MLD, mes première tentatives se sont révélées désastreuses.
En général je passe au MLD manuellement.

Nous devrions pour la suite ne pas tenir compte de l'héritage et vous comprendrez vite le principe lorsque cela s'avèrera nécessaire.

Nouveau MCD sans héritage :



Qu'en pensez vous par rapport aux règles de votre jeu?

François

[Sereine]

ok ok.
Pour ce qui est des caractéristiques et attributs, est ce vraiment nécessaire de faire des tables spécifiques? là je vois que ça me permet d'ajouter des caractéristiques, mais c'est un aspect du jeu que je ne compte pas vraiment changer au fil du temps.
Car ça pourrait bouleverser trop de choses.
Une fois que les caractéristiques de bases sont mise en place, elles ne bougeront plus.

Et oui j'utilise MySql.

[frm013]

Qui peut le plus peut le moins non ?

Je ne connais pas les jeux de rôles en général donc pas le votre en particulier, mais peut-être aurons nous besoin de définir des règles de combats fonction de la valeur de ces attributs ?

Ex: si vitalité > X alors arme Y inefficace.
Ou telle arme fait perdre X point à telle caractéristique.

Pure hypothèse, j'en conviens, car je ne connais pas vos règles à ce propos, ni s'il y en a.

[Sereine]

Oui, les attribut vont varié en fonction du combat, mais je comprend pas pourquoi le mcd a besoin de s'occuper de ça? je comprend pas non plus ce qu'est 'val_rôle'?

[Sereine]

Bon du coup j'ai refais et modifier avec les héritages.
edit: mince c'est le mld, je réédite

[frm013]

CARACTERISTIQUE, recense la valeur de chaque attribut pour l'association d'une RACE et d'une CLASSE.

Comme chaque personnage peut avoir des valeurs des ses caractéristiques qui deviennent différentes en fonction de avancement dans le jeu il faut bien constater cela.

VAL_ROLE, mémorise donc la valeur gagnée ou perdue de chaque caractéristique d'une {race, classe}.

La valeur du personnage P1 ( humain et mage ) pour la vitalité égale donc
{humain, mage, vitalité}.valeur +/- {P1, humain, mage, vitalité}.val_supp

Avec {humain, mage, vitalité} les pseudos valeurs des clés primaires de CARACTERISTIQUE
et {P1, humain, mage, vitalité} celles de VAL_ROLE

Je vois que vous avez poster pendant mon post, je regarde ça.

[Sereine]

bah durant un combat, les seules choses qui vont varier véritable c'est la vie, les golds et l'inventaire du personnage. (et si gain de level = caractéristiques de la classe-race qui s'additionne aux caractéristiques de base du personnage)

Tous le reste, le boostage ou le contraire des caractéristiques, ne sera pas inscrit en dur dans la base de donnée, en gros, si le joueur quitte le combat brutalement, il aura perdu des points de vie, mais même si il avait subit un sort qui abaisse sa force, en quittant le combat, le sort n'est plus en action.

[frm013]

Je ne peux que vous conseiller de mettre toutes les règles de votre jeu sur papier.

En effet plus haut dans ce fil vous me disiez:

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.

Cela sous-entendais que la valeur des attributs pouvait varier au cours du jeu.

Je vous prie de croire que le fait d'éliminer l'entité-type ATTRIBUT peut / va vous emmener vers des impasses. Notamment celle qui vous a conduit à une erreur dans votre MCD : tous les PLAYERs de la même RACE+CLASSE partage les même caractéristiques


Ne vous focaliser pas trop sur la question de mémoriser en base de données, un MCD ne fait qu'étudier le quoi pas le comment.
Il doit vous permettre d'éclaircir vos idées.
Le fait de mettre en phrases construites vos idées vous aidera beaucoup.

ex:
Un player est caractérisé par des attributs, la valeur de ces attributs dépendent de sa race ainsi que de la classe de sa race.
La valeur d'une attribut peut évoluer au cours du jeu grâce au points gagnés par un player.
Une race doit avoir une classe de comportement parmi un choix pour cette race,
Une classe peut être présente dans les choix de plusieurs races.

Ce sont les phrases qui peuvent correspondre à mon schéma.
Regardez comme les mots en gras conditionnent les choix faits dans mon modèle. Et je ne dis pas qu'il est parfait, mais c'est comme cela que j'ai éliminer cette redondance de caractéristiques.

(et si gain de level = caractéristiques de la classe-race qui s'additionne aux caractéristiques de base du personnage)

C'est une règle importante que j'aurais aimé connaitre

il aura perdu des points de vie, mais même si il avait subit un sort qui abaisse sa force, en quittant le combat, le sort n'est plus en action.

Pourquoi l'un et pas l'autre ? vous devez vous poser la question, vous nous avez dit vouloir mettre tout à plat parce que :

Le problème c'est que plus j'avance, plus c'est fouillis

Il y a une chose que ne gère pas l'informatique, c'est le p'tet ben qu'oui p'tet ben qu'non.

Allez Camille, courage !

[Sereine]

Le soucis c'est que j'arrive pas à écrire mon projet de façon claire et structuré, ça part dans tous les sens et je m'y retrouve pas :/

je me suis trompé pour les caractéristiques, c'était

race_classe 1,1 ---- 0,N characteristic 0,N -------- 1,1 Player

Comme ça dans caractéristiques j'aurais des lignes de caractéristiques spécifiques aux race-classe et des lignes spécifiques aux joueurs.

Les caractéristiques sont modifiés lors de la montée de niveau d'un joueur, celui ci rajoute les caractéristiques de sa race-classe à ses propres caractéristiques à chaque niveau. (la plafond étant la limite de niveau).
Et à chaque niveau le joueur distribue des points de caractéristiques en plus (un nombre fixe, le même à chaque niveau), qui iront modifier sa ligne de caractéristiques.


En gros, un Nain-Gardien a pour caractéristiques de base:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
id_char | int | Str | Vit | Dex
    1       1     3      4     2

Mon personnage qui est Nain-gardien lvl 1 va rajouter une ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
id_char | int | Str | Vit | Dex
    1       1     3      4     2
    2       1     3      4     2

Celui ci monte de niveau:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
id_char | int | Str | Vit | Dex
    1       1     3      4     2
    2       2     6      8     4

Et il distribue ses 3 points de caractéristiques qu'il a de disponible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
id_char | int | Str | Vit | Dex
    1       1     3      4     2
    2       2     7     10     4

et pour les points gagnés à chaque niveau, je l'avais déjà dis plus haut, mais peut être mal formulé

(pour le reste je relirais demain, là je suis un peu morte x) ) Merci beaucoup en tout cas !

[frm013]

Le soucis c'est que j'arrive pas à écrire mon projet de façon claire et structuré, ça part dans tous les sens et je m'y retrouve pas

Je vous assure que c'est mon cas aussi
Je me force à le faire, et d'autre part, j'essaie de modéliser en segmentant le modèle, tour en ayant une vision globale. En effet, la modélisation d'une partie, risque de modifier la façon de voir le reste.

En se concentrant sur une partie du modèle, on peut arriver à le rendre générique ( en fonction des règles bien sûr ).

D'ou mon entité-type ATTRIBUT.
Qui dit que vous n'aurez pas à référencer un attribut individuellement ?

race_classe 1,1 ---- 0,N characteristic 0,N -------- 1,1 Player
Comme ça dans caractéristiques j'aurais des lignes de caractéristiques spécifiques aux race-classe et des lignes spécifiques aux joueurs.

Ouuuuuh làààà! quel mélange! C'est typiquement le genre de choses à éviter.
C'est un des buts de la normalisation.

A bientôt
François

[Sereine]

oui mais j'ai vraiment pas envie d'avoir des attributs dynamique comme ça, je veux qu'ils soient fixe, je compte pas ajouter ou enlever des attributs sans arrêt par la suite.

Du coup, est ce que quelque chose comme ça, avec des caractéristiques fixe, ça irait?

[frm013]

Bonjour Camille,

Vous revenez quasiment à votre premier MCD.

En effet :

L'association "caractériser" porte les cardinalités 1,1 sur chacune de ses pattes, ce qui revient à fusionner les entités-type de ses extrémités, à savoir PLAYER et CARACTERISTIQUE_PLAYER.

Idem pour RACE_CLASSE et CARATERISTIQUE_BASIQUE.

A quoi sert l'attribut player_points de CARACTERISTIQUE_PLAYER ?

oui mais j'ai vraiment pas envie d'avoir des attributs dynamique comme ça, je veux qu'ils soient fixe, je compte pas ajouter ou enlever des attributs sans arrêt par la suite.

J'avais compris, mais qu'est ce qui vous empêche des les garder fixes ? même s'ils peuvent varier...

Vous voulez remettre à plat un modèle qui vous pose problème, mais vous bloquez sur une décision arbitraire avant de modéliser.

C'est la modélisation de vos règles qui vous mènera à des solutions d'implémentations, pas l'inverse. Camper sur les décisions arbitraires qui vous ont amenées sur ce forum ne vous fera pas avancer.

Encore une fois, ma proposition n'est qu'une ébauche, je n'ai pas la prétention quelle soit la vérité absolue.

Décrivez votre jeu comme si vous l'expliquiez à un ami, à ce propos, il faudra bien fournir les règles aux joueurs non ?

A suivre...
François