Gestion Des Tables, optimisation

Bonjour à tous

Je me suis décidé à apprendre le PHP car depuis plusieurs mois j'ai très envie de réaliser un jeu de stratégie multijoueur et je me suis enfin décidé.

Bien que mon apprentissage soit à ses débuts il y a une question que je me pose depuis que j'ai lu le topic sur les maps => l'organisation des tables.

Je m'explique :

le jeu se joue avec un damier : les unités sont donc dessus et se déplacent en X et Y.
Je souhaite que dans le jeu, il y ai un côté 'exploitation des ressources'. Donc pour chaque case se trouve une certaine quantité de ressource. exemple : sur la case (31;25) il y a 20 tonnes de charbon, 10 tonnes de fer, et 2 tonnes d'or et sur la case voisine (32;25) se trouve 5 tonnes de souffre, et 1 tonne de charbon

J'avais donc pensé qu'il suffisait de créer une table 'lieux' dans laquelle je mettais tous les noms des lieux et pour chacun serait attribué une quantité d'or , de charbon, de fer, et de souffre etc.

Etant donné que ces valeurs changent au fil du temps ( si un joueur extrait une ressouce d'un lieu) la table sera sans cesse en mouvement.

Vaut il mieux cette table unique ? ou créer autant de table qu'il existe de ressources et pour chacune remettre la liste des lieux et ce qu'il y a comme quantité de ressource dessus. -> c'est à dire une table charbon, une table souffre etc, et dans chaque table mettre 'lieu 01,01 : 2 tonnes' etc ??

Je (re)précise que je débute en PHP, donc ne soyez pas effrayé devant tant d'ignorance
J'apprend avec le bouquin 'Php et mysql pour les nuls' (bouh la honte)

En espérant que vous m'ayiez compris ;o)

Il faut réduire au maximum la redondance d'information, donc tout mettre dans une table dans ton cas.

Pour les curieux, allez voir des cours sur les bases de données relationnelles, où l'on parle de schéma relationnel, formes normales, ...
(http://cerig.efpg.inpg.fr/tutoriel/bases-d...es/sommaire.htm chapitre 5 par ex)

Heu, je me trompe peut-être mais tu n'es pas déjà le (co)créateur de Shadow of Destiny ???

Je répond a la question : je te conseil 2 tables pour ne pas trop avoir de problème (surtout si tu bouge beaucoup dans celle ci).

Combien fait ta carte en longueur et largeur tout d'abord?

Sinon fait une autre table avec : X | Y | ressources A | ressources B | ect...
Mais ca dépend du nombre de ressource que tu a, sinon tu implode dans un seul enregistrement.

Mais c'est vrai que c'est étrange comme question pour quelqu'un qui a un jeu.
@+

telecharge smiles war pour avoir une type de base de tables (regarder ma signature pour le lien)

dedans tu y trouvera une base pour les personnages (je crois qu'il n'y a pas d'obejts...) mais il suffit d'ajouter un table carte avec id,x,y,koi et d'ajouter un petit while dans la génération de carte

Personnellement, je verrai une table décrivant chacune de tes cases (j'imagine qu'il y a autre chose que des ressources sur ces fameuses cases, une description par exemple), une table de ressources type | CODE RESSOURCE | LIBELLE RESSOURCE | et une table d'association entre les cases et les ressources ( |X|Y|CODE RESSOURCE|QUANTITE|)dans laquelle tu exprimes les quantités ainsi, l'ajout d'une éventuelle nouvelle ressource se ferait facilement

Perso, je ferais :

une table avec :
- id_ressource
- nom_ressource

et une autre avec :
- coord_X
- coord_Y
- id_ressource
- qt_ressource


donc, si y'a 20 charbon et 10 fer sur la case [13;7] ça ferais :
- 1, charbon
- 2, fer
.. dans la première table et

- 13, 7, 1, 20
- 13, 7, 2, 10
... dans la deuxième

Comme ça, le jour ou tu ajoutes un nouveau type de ressource, tu ne seras pas obligé de changer ton shéma de base.

.. vous en pensez quoi de mon idée ?

je crois qu'on est d'accord

Je te conseillerais plutot de scinder tes ressources par tables. Ce n'est peut être pas tres élégant au niveau conceptuel mais lorsque tu auras 36000 cases tu y gagnera grandement au niveau des performances (même avec 3 requêtes l'une apres l'autre).

Et aussi, je ne sais pas quelle bdd tu utilise mais tu peut aussi bien créer une seule et même vue qui exploite tes 3 tables pour ne pas te faire chier dans tes requêtes de sélection.

Bien sinclair, tu viens de réinventer la roue
sinclair et magauss: je pense que les ID ressource était clair, sa question était pas comment gerer les ressources (il est évident qu'il faut une table de ressource, comment gerer ca sinon?) mais comment gerer les ressources par table.
@+

Je trouve discutable le fait de créer un table ressources, cela dépend du jeu, en particulier si effectivement la liste des ressources est amenée à évoluer très fréquemment.

Mais même dans ce cas, je ne pense pas que rajouter une colonne à une table et le bout de code PHP soit très long à faire, et surtout ça va éviter des jointures dans tous les sens

X Y nom_lieu Ressource_A Ressource_B Ressource_C ...

Merci pour ces réponse

Euh oui je suis 'déjà' le (co)créateur de Shadows of destiny
Je cherche pas à créer le jeu de stratégie ultime, juste un truc qui tourne ;o) et qui m'aura appris le php/ sql (j'trouve ca plus amusant que créer un portfolio intéractif)

Concernant la carte je vise quelque chose d'assez grand : 300 cases * 300 ( il faut que le jeu puisse accueillir plusieurs centaine de joueurs ayant chacun differentes unités, occupant chacune une case.. a raison de 40 unités par joueurs, si y a 200 joueurs ca fait 8000 / 90 000 cases - je reconnais que c'est très relatif comme calcul, mais ca donne une idée de l'ambition)

Pour ce qui est des ressources, j'en voyais une petite vingtaine différentes.
Donc j'ai bien noté la manière de procéder sachant qu'une fois les ressources fixés, ca risque sans doute pas de changer.

Mais bon, je le reredis, j'en suis pas encore à ce stade, c'était à titre de clarification

merci à tous

hum ... je sens un brin d'ironie là non ?

Figure toi que ces principes sont peut-être évidents pour les pros de sql comme toi, mais c'est loin d'être intuitifs pour nous qui débutons.

Bref, plutot que de te moquer, tu nous aiderais plus en disant si c'est une bonne ou une mauvaise idée.

... et si notre manque d'expérience t'irrite à ce point, tu devrais plutot aller dans le coin des MJ, car justement, le forum technique a été créé pour qu'on embête plus les pros comme toi avec nos questions bêtes.

Ophiucus, quand tu sera plus avant reviens nous en parler pour voir si ca ne corespond pas a ton dévelloppement futur.

Sinclair, calme toi, j'ai jamais dis que j'était un pro en SQL, mais les questions que tu pose d'habitude resulte d'une grande fénéantise. Tu nous pose des questions de base qui auraient pu être trouver en 5 minutes dans un livre ou sur le net. La encore tu nous sort un concept de base dont tu est le seul a douter. Loin de moi de critiquer ton niveau, mais plutot ta façon de faire le minimum. D'ou je me suis permis cette petite pique, et tu verra qu'au bout de 4 ou 5 tu cherchera plus (et tu verra tu trouvera) avant de poser des questions qui se trouve dans le chapitre 1 du php pour les nuls.
Je ne veut pas te rabaisser mais te pousser a être plus autodidacte, si tu ne sais pas (ou ne veut pas) le devenir, tu peut déjà arreter maintenant, ce n'est pas nous qui allons faire ton travaille

Et si je n'aimais pas aider, je répondrais pas... sois pas bêtes.
@+