#Phase de conception
Il y a quand même quelques imprécision:
Comme tu as mis bâtiment sans s je suppose que c'est le bâtiment qui se développe (et non qu'il y a création de nouveau bâtiment). Par exemple par niveau (niveau qui pourront être retranscrit autrement ensuite)
Mais pour le reste on va dire qu'il doit être possible de savoir si son alliance est ennemis, allié ou neutre envers une autre.
#Création des tables
Ok maintenant que c'est décris un peu mieux il est possible, comme le propose Rodrik, d'attaquer la création des tables correspondant à ce système d'alliance.
#Le MCD
En théorie, quand on a une description comme tu l'as faites, il faut, pour pouvoir transformer çà en tables, faire le MCD (Modèle Conceptuel de Donnée).
Personnelement, je ne le fais désormais plus que pour les grosses bases, car à force d'erreur j'ai désormais des réflexes. Cependant je vais faire une exception.
Tout d'abord j'ai lu l'ensemble des besoin exprimés, puis je les ai pris de façon détaillé en les transcrivant en uml.
Comme une alliance contient des joueurs j'ai mis un lien entre les 2 classes.
Du coté joueur j'ai mis 1..* ce qui veux dire qu'il peux y avoir 1 à plusieurs joueurs dans une alliance. Si il y a 0 joueur il n'y a plus d'alliance donc.
Du coté alliance il y a un 0..1 ce qui signifie que j'ai considéré qu'un joueur ne pouvait être que dans une alliance à la fois.
NB: un attribut correspond souvent à une colonne et une méthode à une requête. Ici la requête serait du type
SELECT COUNT(*) FROM joueur WHERE id_alliance='$id_alliance'
NB: il y a une erreur c'est une relation (alliance) 0..1 - 1 (joueur)
Donc j'ai fait une classe `ligne_de_compte` et d'après le schéma chaque ligne de compte possède un `compte` débité et/ou un `compte` crédité. Si il n'y en a qu'un sur les 2 celà signifie que c'est de largent qui entre ou sort du jeu.
Une méthode solde() sur la classe compte permet de calculer la somme sur le compte en additionnant toutes les rentrée et en soustrayant les sorties.
Les alliances et les joueurs possèdent un compte d'où le trait entre leur classe respective et la classe compte. par contre un compte ne peux pas appartenir à une alliance et un joueur en même temps du coup on indique un XOR (OU exclusif).
NB: si une autre entité venait à pouvoir posséder un compte
Ainsi une alliance peut considéré comme ennemie ou allié d'autre alliance.
On ne créer pas de statut neutre cependant car dans ce cas on ne fait rien...
NB il y a un erreur aussi ici la relation c'est N à N et non 1 à N
#Le MLD
Maintenant qu'on a un MCD il faut traduire çà en modèle logique de donnée (donc sous forme de table presque)
On commence par la classe alliance:
On met les attributs de celle ci comme colonne.
On sait aussi qu'une alliance peux éventuellement changer de nom, donc on définit une clé artificiel (#id)
On a une relation (alliance) 0..1 - 1 (joueur) donc on choisis de le mettre du coté alliance(dirigeant=>joueur,) car sinon il y aurait des null pour tous les joueurs nétant pas dirigeant
Une alliance possédant un compte on définit aussi une clé compte qui sera le numéro du compte.
Pareil on met les attributs comme colonne
puis on met une colonne alliance car la relation était de type (alliance) 0..1 - 1..n (joueur) si on avait voulu mettre la colonne dans alliance nous n'aurions pas pus car une colonne ne contient qu'une valeur or une alliance à plusieurs joueurs
Idem pour le compte que pour alliance
On créé la table compte qui sert juste à répertorier les id de compte, pour l'auto incrément.
Les liens à ligne_de_compte ne peuvent être matérialiser dans compte à cause de la relation 1 à plusieurs. (c'est le même cas que pour la colonne joueur impossible à mettre dans alliance)
On met l'attribut somme comme colonne
Et on matérialise les liens aussi comme colonne
Et on créé 2 colonnes l'une pour l'alliance qui as définit un statut l'autre pour l'alliance qui fait l'objet de ce statut.
NB: ici il est possible qu'une alliance considère comme alliés une alliance qui la considérerai comme ennemie.
#Coder les actions possible
Il va donc falloir désormais coder les différentes fonctions représentant chacune une action, j'ai identifié dans ton texte:
- créer alliance
- indiquer un nouveau lien de forum
- changer la présentation de l'alliance
- augmenter le niveau du bâtiment de l'alliance
- lister les joueurs dans l'alliance et leur caractéristique
- compter le nombre de membre
- définir un statut sur une autre alliance
- Lister les statuts de l'alliance envers les autres
- écrire un message sur permanent
- adhérer à une alliance
- envoyer_message_à _alliance
- donner d l'or à l'alliance
- transférer de l'or d'un compte à un autre
- calculer le solde du coffre
Donc si tu code toutes ces actions, il ne te restera plus qu'à créer les affichage qui vont bien avec et ce sera quasiment dans la poche.
Il y a quand même quelques imprécision:
Citation :Une page "bâtiment de l'alliance" ou l'on ferait des dons afin qu'au bout d'un moment, a un certain niveau d'or atteint, on puisse la développer et en la développant, on pourrait recevoir plus de joueurs...L'or disparait quand on développe l'alliance? je suppose que oui.
Comme tu as mis bâtiment sans s je suppose que c'est le bâtiment qui se développe (et non qu'il y a création de nouveau bâtiment). Par exemple par niveau (niveau qui pourront être retranscrit autrement ensuite)
Citation :Edit: Si, je prévois des interactions diplomatiques, guerres, alliances, pna comme tu as dis, sont prévus aussi...Je sais pas ce qu'est pna...
Mais je ne compte pas coder quelque chose qui fait que deux membres d'alliances sous PNA ne puissent pas s'attaquer...
Mais pour le reste on va dire qu'il doit être possible de savoir si son alliance est ennemis, allié ou neutre envers une autre.
#Création des tables
Ok maintenant que c'est décris un peu mieux il est possible, comme le propose Rodrik, d'attaquer la création des tables correspondant à ce système d'alliance.
#Le MCD
En théorie, quand on a une description comme tu l'as faites, il faut, pour pouvoir transformer çà en tables, faire le MCD (Modèle Conceptuel de Donnée).
Personnelement, je ne le fais désormais plus que pour les grosses bases, car à force d'erreur j'ai désormais des réflexes. Cependant je vais faire une exception.
Tout d'abord j'ai lu l'ensemble des besoin exprimés, puis je les ai pris de façon détaillé en les transcrivant en uml.
Citation :Une page de présentation de l'alliance ou l'on peut entrer un texte d'à peut près 50 000 caractères (on leur demande pas un roman pour présenter leur alliance 34);Ici j'ai créer une classe nommée `alliance` avec un attribut présentation représentant ce fameux texte de 50 000 caractères... J'ai extrapolé et me suis dit que l'alliance avait certainement un petit nom.
Citation :ou il y a un résumé des choses principales de l'alliance, a savoir l'honneur actuel de l'alliance (l'honneur de tous les joueurs réunis dans l'alliance),Donc la j'ai modélisé la classe joueur, tu as certainement déjà créé la table qui lui correspond donc il faut considéré qu'il y a déjà tout les attribut indiqué dans ta table. Là tu parle de l'attribut honneur donc je l'ai ajouté.
Comme une alliance contient des joueurs j'ai mis un lien entre les 2 classes.
Du coté joueur j'ai mis 1..* ce qui veux dire qu'il peux y avoir 1 à plusieurs joueurs dans une alliance. Si il y a 0 joueur il n'y a plus d'alliance donc.
Du coté alliance il y a un 0..1 ce qui signifie que j'ai considéré qu'un joueur ne pouvait être que dans une alliance à la fois.
Citation :le nombre de membre de l'allianceLà j'ai créé une méthode à la classe alliance et pas un attribut, en effet on peut calculer le nombre de joueur appartenant à l'alliance grâce à la relation qui lie les 2 classes. Il n'y a donc nul besoin d'un attribut.
NB: un attribut correspond souvent à une colonne et une méthode à une requête. Ici la requête serait du type
SELECT COUNT(*) FROM joueur WHERE id_alliance='$id_alliance'
Citation :l'or donné à l'alliance, le nombre maximum de personnes que l'alliance peut compter et le lien vers le forum de l'alliancePour l'instant j'ai ajouté 2 attributs à alliance (mais j'y reviendrait par la suite)
Citation : (que le fondateur doit renseigner).Ah donc là il faut rajouter un lien entre la classe joueur et la classe alliance pour identifier celui qui dirige ou administre l'alliance.
NB: il y a une erreur c'est une relation (alliance) 0..1 - 1 (joueur)
Citation :Lorsque l'on fait parti de l'alliance, on peut envoyer des messages aux membres de cette alliance.Bon alors là j'ai juste mis une méthode dans joueur, j'ai considéré qu'un système de messagerie çà se définit, or la on a juste çà comme info. Il est notamment possible d'utiliser les classes du forum...
Citation :Une page ou, si on est membre de l'alliance, on peut voir tous les membres qui la composent ainsi que l'or qu'ils ont donné a l'alliance, leur honneur et leur niveau respectif.Bon j'ai rajouté l'attribut niveau à joueur, mais surtout j'ai viré or_recu pour créer une notion plus fine de compte.
Donc j'ai fait une classe `ligne_de_compte` et d'après le schéma chaque ligne de compte possède un `compte` débité et/ou un `compte` crédité. Si il n'y en a qu'un sur les 2 celà signifie que c'est de largent qui entre ou sort du jeu.
Une méthode solde() sur la classe compte permet de calculer la somme sur le compte en additionnant toutes les rentrée et en soustrayant les sorties.
Les alliances et les joueurs possèdent un compte d'où le trait entre leur classe respective et la classe compte. par contre un compte ne peux pas appartenir à une alliance et un joueur en même temps du coup on indique un XOR (OU exclusif).
NB: si une autre entité venait à pouvoir posséder un compte
Citation :Une page ou l'on enregistre certains messages que l'on veut garder pour toute l'alliance, la différence avec la sorte de messages en haut, c'est que eux restent, ceux plus haut, c'est qu'ils vont dans la boite de messages et sont supprimés au bout d'un certain temps. Il faut bien sur être membre de l'alliance afin de les poster...Idem que pour la boite de message j'ai considéré que c'était à créer en connaissance des tables du forum
Citation :Une page "bâtiment de l'alliance" ou l'on ferait des dons afin qu'au bout d'un moment, a un certain niveau d'or atteind, on puisse la développer et en la développant, on pourrait recevoir plus de joueurs...Donc là j'ai viré l'attribut limit_place pour un attribut niveau bâtiment. La limite de place pouvant être calculer en fonction de ce niveau. J'ai mis une méthode augmenter_niveau() qui créera la ligne débitante sur le compte de l'alliance et augmentera niveau_batiment
Citation :Edit: Si, je prévois des interactions diplomatiques, guerres, alliances, pna comme tu as dis, sont prévus aussi...Bon là j'ai mis une association sur la classe alliance, avec une classe d'association "statut"
Mais je ne compte pas coder quelque chose qui fait que deux membres d'alliances sous PNA ne puissent pas s'attaquer...
Ainsi une alliance peut considéré comme ennemie ou allié d'autre alliance.
On ne créer pas de statut neutre cependant car dans ce cas on ne fait rien...
NB il y a un erreur aussi ici la relation c'est N à N et non 1 à N
#Le MLD
Maintenant qu'on a un MCD il faut traduire çà en modèle logique de donnée (donc sous forme de table presque)
On commence par la classe alliance:
On met les attributs de celle ci comme colonne.
On sait aussi qu'une alliance peux éventuellement changer de nom, donc on définit une clé artificiel (#id)
On a une relation (alliance) 0..1 - 1 (joueur) donc on choisis de le mettre du coté alliance(dirigeant=>joueur,) car sinon il y aurait des null pour tous les joueurs nétant pas dirigeant
Une alliance possédant un compte on définit aussi une clé compte qui sera le numéro du compte.
Citation :alliance(#id,nom,présentation,niveau,lien_forum,niveau_batiment,dirigeant=>joueur,compte=>compte)
Pareil on met les attributs comme colonne
puis on met une colonne alliance car la relation était de type (alliance) 0..1 - 1..n (joueur) si on avait voulu mettre la colonne dans alliance nous n'aurions pas pus car une colonne ne contient qu'une valeur or une alliance à plusieurs joueurs
Idem pour le compte que pour alliance
Citation :joueur(#id,honneur,niveau,alliance=>alliance,compte=>compte)
On créé la table compte qui sert juste à répertorier les id de compte, pour l'auto incrément.
Les liens à ligne_de_compte ne peuvent être matérialiser dans compte à cause de la relation 1 à plusieurs. (c'est le même cas que pour la colonne joueur impossible à mettre dans alliance)
Citation :compte(#id)
On met l'attribut somme comme colonne
Et on matérialise les liens aussi comme colonne
Citation :ligne_de_compte(#id,debite=>compte|Null,credite=>compte|Null,somme)Comme on a une relation N à N on est obligé de créer une classe, comme il y a un élément (type) attaché avec une classe d'association on donne le nom de la classe d'association à la table.
Et on créé 2 colonnes l'une pour l'alliance qui as définit un statut l'autre pour l'alliance qui fait l'objet de ce statut.
NB: ici il est possible qu'une alliance considère comme alliés une alliance qui la considérerai comme ennemie.
Citation :statuts(#considérant=>alliance,#considéré=>alliance,type=ennemis|alliés)Bref maintenant on a presque nos table SQL, il ne reste plus qu'à définir les types,les contraintes (unicité) etc... et les valeurs par défauts.
#Coder les actions possible
Il va donc falloir désormais coder les différentes fonctions représentant chacune une action, j'ai identifié dans ton texte:
- créer alliance
- indiquer un nouveau lien de forum
- changer la présentation de l'alliance
- augmenter le niveau du bâtiment de l'alliance
- lister les joueurs dans l'alliance et leur caractéristique
- compter le nombre de membre
- définir un statut sur une autre alliance
- Lister les statuts de l'alliance envers les autres
- écrire un message sur permanent
- adhérer à une alliance
- envoyer_message_à _alliance
- donner d l'or à l'alliance
- transférer de l'or d'un compte à un autre
- calculer le solde du coffre
Donc si tu code toutes ces actions, il ne te restera plus qu'à créer les affichage qui vont bien avec et ce sera quasiment dans la poche.