Structure de ma base de données

[MyREroS]

Bonjour bonjour,

Je viens vous voir car on s'est lancé dans la création d'un jeu en php avec un ami, je suis plus ou moins le seul programmeur, mais certainement un mauvais programmeur.

Le but de ce projet étant d'apprendre tout en se divertissant, je ferai tout mon possible pour aller au bout.

Mon problème actuel, un problème très bête,
Je ne sait pas du tout comment créer ma bdd (MySQL)

Je vais d'abord vous présenter la chose:
- Création d'un Wargame.

Vous allez me dire pourquoi un Wargame ça existe de partout et tralala, le choix est justement là, on fait ça pour le plaisir d'apprendre et de coder, donc partir d'une idée existante aide beaucoup.

Pour l'instant, pas d'unité, pas de général, pas de défense, rien de tout ça: on veut gérer un système économique, et seulement après viendra le côté wargame.

Je n'ai vu nulle part des exemples de bdd pour jeu multijoueurs.
Pour la gestion: Comment structurer ma base?

Données à stocker:
- Joueur
- Ressources (eau, nourriture, bois, etc...)
- Bâtiments (silo, maison, sotckage eau, etc..)(avec montée de lvl)
- Technologies
- Paysan (sachant qu'on peut en recruter des nouveaux, qu'ils ont chacun un moral propre qui est modifié suivant les actions effectué)

Voila,
Donc pour créer mes tables, des millions de possibilités sont présentes et je ne sait pas quoi faire.

Ma première intuition était de créer les tables comme indiqué ci-dessus avec une ligne par joueur dans chaque table.
J'ai ensuite pensé qu'il était mieux de faire une table propre à un joueur.
Maintenant ce que je pense, c'est que je suis perdu.
J'espère que c'est clair, et vous remercie d'avance pour vos réponses.

[Globe]

Il n'y à pas de sujet dédié parce que la structure d'une BDD dépend fortement du jeu. Par exemple au lieu de n'avoir qu'une table bâtiments ou autre je partirais sur deux, une qui contient les infos du bâtiment, id, nom, description, cout en ressources, cout de construction... Et une qui contient l'id du joueur, celui du bâtiment, et son niveau du bâtiment du joueur. Pareil pour les unités pourquoi faire une table pour les paysans alors que tu pourrais sur le même principe expliqué précédemment faire deux tables qui à elles deux géreraient tous les types d'unités.

[NicoMSEvent]

je reprends tes idées, et j'y ajoute ce que je pense bon pour ton projet (ce n'est p-e pas le cas, ajuste ça comme tu veux, selon tes besoins)


Liste des tables:
- Joueur + Ressources (champs : eau, nourriture, bois, etc...) ->parce que les ressources sont bien définies (par d'ajout de type de ressources) et sont liées à un joueur
- Bâtiments (silo, maison, sotckage eau, etc..-> ici ce sont des lignes, et pas des champs différents) : dans une table séparée, pcq c'est plus flexible pour ajouter un nouveau batiment dans ton jeu
- Batiments par joueur (avec lvl)
- Technologies
- Technologies acquises par joueur (avec lvl éventuel)
- Paysan (par joueur) -> 1 ligne par paysan (avec un champ moral)


quand je dis : "par joueur", ça signifie qu'il y a un champ qui reprend l'identifiant du joueur, pour savoir a qui ces données appartiennent.

voilà les tables que je verrais bien dans ton projet...


PS : une petite présentation dans la section appropriée serait la bienvenue
et p-e, quand ton projet sera mieux balisé, une présentation du projet

[MyREroS]

Donc il faudrait partir du principe qu'on a une table Bâtiment "Général" qui ne changera presque pas sauf "maj" et qui regroupe les bâtiment existant (je pensait mettre les coûts directement sur le code, on va voir ça) et une table batiment-joueur, où j'aurait un champ batiemnt, joueur, lvl.
Ca me plait, et en même temps que je réfléchis à ce que je viens de lire, la base se construit tout doucement dans ma tête, j'en déduis que vous m'avez donné les infos que je cherchait

Je vais voir ça sur papier, et je vous tiendrai au courant si je vais au bout ou si je bloque une nouvelle fois.
Merci!

Edit: une petite question dans liste des tables, quand tu dis "Paysan (par joueur)" c'est une table de paysan par joueur, ou plutôt une table avec un champ joueur et une ligne par paysan?
Globe: Pour le moment, on a que des paysans, car on s'applique pour la gestion de l'économie, afin que ce ne soit ni facile, ni trop difficile.
Et vu la gestion des paysans avec le moral (il faudra dire quel péon va travailler ici ou là, ou se reposer), je vais surement les séparer, car les armées auront plutôt un moral général des troupes.

[NicoMSEvent]

Une table = un type de données

une petite question dans liste des tables, quand tu dis "Paysan (par joueur)" c'est une table de paysan par joueur, ou plutôt une table avec un champ joueur et une ligne par paysan?

avec ce que je viens d'écrire, je pense que j'opterais pour la 2eme solution ^^

Dans un projet, les tables se définissent au début. On ne créer pas des tables "au vol", pour le plaisir.

La modélisation du projet est très importante, de même que la structure de tes tables. C'est le squelette du jeu sur lequel les fonctions vont se baser (on va comparer les fonctions a des muscles), donc, les fonctions vont s'articuler autour de tes données. Si le squelette n'est pas bon/pas solide, tu vas vite rencontrer des limitation, parfois blocantes! Penses-y a deux fois avant de créer une table

Donc, quand tu me dis que tu compte créer une table par paysan, je vois ça comme "ajouter un bras a chaque fois que tu souhaite faire autre chose" (faire la vaisselle, balayer, ranger, dire bonjour avec la main, ...)... tu serais vite un mille patte ^^

[Ter Rowan]

une remarque concernant

Paysan (sachant qu'on peut en recruter des nouveaux, qu'ils ont chacun un moral propre qui est modifié suivant les actions effectué)

Certes, cela veut dire autant de ligne d'enregistrement que de paysan.

Maintenant, pour un wargame, est ce utile ?
On ne gèrera pas les paysans un à un (je demande à gertrude, raoul, boromir legolas et oxman d'aller nettoyer les chiottes), mais par grande population (j'affecte 10 paysans à X, 50 à Y, etc...)

sinon on n'est pas dans un wargame mais dans une gestion de petite communauté d'individus (une sorte de sim)

si derrière tu veux avoir un mix gestion de royaume et grande bataille, je pense qu'il faut que tu abandonnes l'idée de gérer les individus du royaume

Qui plus est si

un Wargame ça existe de partout et tralala, le choix est justement là, on fait ça pour le plaisir d'apprendre et de coder, donc partir d'une idée existante aide beaucoup.

alors n'ajoute pas de complexité là dessus, cela retardera la réalisation de ton projet

du coup je proposerai plutôt une table du type :

id joueur / type population / quantité

avec type de population = paysan, bucheron, unité militaire 1, unité militaire 2, unité militaire 3, etc...

ainsi :
[ joueur 1 ] / paysan / 15
[ joueur 2 ] / paysan / 30
[ joueur 2 ] / bucheron / 10

veut dire que [joueur 1] possède 15 paysans, que [ joueur 2 ] possède 30 paysans et 10 bûcherons, etC...

après quoi en fonction de tes souhaits tu pourras faire évoluer :

l'affectation :

id joueur / type population / affectation / quantité

[ joueur 1 ] / paysan / champ de blé / 10
[ joueur 1 ] / paysan / champ d'orge / 5
[ joueur 2 ] / paysan / champ de blé / 20
[ joueur 2 ] / paysan / pré à vaches / 10
[ joueur 2 ] / bucheron / forêt du nord / 5
[ joueur 2 ] / bucheron / forêt du sud / 5


pour le moral c'est la même chose finalement (mais je pense sincèrement que c'est moins utile pour un premier essai de jeu)


id joueur / type population / affectation / moral / quantité

avec moral = 0 = déprimé; 1 = malheureux; 3 = heureux
là je lis que joueur 1 à 10 paysans dans le champ de blé, que 5 sont déprimés, 3 malheureux et 2 heureux

Enfin, pour développer proprement tu n'utiliseras pas des chaines de caractères pour les types de population, affectation etc, mais des codes, ou id

exemple 1 = paysan, 2 = bucheron, du coup ta table (sans l'aspect moral), à lire donnera :

1 / 1 / 1 / 10 => le champ de blé du joueur 1 a pour code 1
1 / 1 / 2 / 5
2 / 1 / 3 / 20 => le champ de blé du joueur 2 a pour code 3 (id automatique quand tu créeras le champ)
2 / 1 / 4 / 10
2 / 2 / 5 / 5
2 / 2 / 5 / 6

au lieu de

[ joueur 1 ] / paysan / champ de blé / 10
[ joueur 1 ] / paysan / champ d'orge / 5
[ joueur 2 ] / paysan / champ de blé / 20
[ joueur 2 ] / paysan / pré à vaches / 10
[ joueur 2 ] / bucheron / forêt du nord / 5
[ joueur 2 ] / bucheron / forêt du sud / 5

[gameprog2]

la premiere idée qui me vient c'est une table joueur, dont chaque ligne est en plus d'autres champs)

Nom du joueur/paysans/fantassins/cavaliers/artilleurs etc...
ça donnerait :

Pseudo : MyReros
Paysans : 25
Fantassins : 15
Cavaliers : 10
Artilleurs : 5

Mais sache que je suis débutant en DB donc je donne juste ma version de débutant

Si tu gere le moral paysan il y a aussi le moral fantassins etc... donc il te faudrait une table rien que pour les troupes :

Type/moral
Paysan : 25
Fantassin : 95

etc...

[MyREroS]

Maintenant, pour un wargame, est ce utile ?
On ne gèrera pas les paysans un à un (je demande à gertrude, raoul, boromir legolas et oxman d'aller nettoyer les chiottes), mais par grande population (j'affecte 10 paysans à X, 50 à Y, etc...)

En fait il n'y aura ni de grande population, ni différent types de travailleurs (bucheron, fermier, ou je ne sait quoi d'autres)

On souhaite avoir des paysans polyvalents, pour reprendre l'idée depuis le début, notre jeu se basera sur une petite escouade de bonhommes en plein milieu du désert dont le but est 1. de survivre, 2. d'évoluer.
La gestion économique est d'autant plus importante qu'il n'y a que peu de ressources dans le désert (je sait pas si cette phrase est écrite en français mais ça devrait le faire pour le comppréhension )

Et le wargame consistera à la recherche et protection de ces mêmes ressources dans un monde parfois sans pitié.
Ca me fait justement réfléchir sur les unités militaires, elle seront forcément en quantité limité. je vais voir ca de suite.

Sinon, les "paysans" seront limités à 20 ce qui laisse une gestion moyennement simple pour le joueur lambda.

On à le temps d'y réfléchir donc ne pas s'inquiéter pour la complexité. J'aime galérer, ca veut dire que j'apprend (ou pas).

La modélisation du projet est très importante, de même que la structure de tes tables. C'est le squelette du jeu sur lequel les fonctions vont se baser (on va comparer les fonctions a des muscles), donc, les fonctions vont s'articuler autour de tes données. Si le squelette n'est pas bon/pas solide, tu vas vite rencontrer des limitation, parfois blocantes! Penses-y a deux fois avant de créer une table

J'avais bien compris, c'est pour ça que je suis là

Merci encore!