Version imprimable du sujet Cliquez ici pour voir ce sujet dans son format original

Forum TourDeJeu > Programmer > Gestion Des Tables

Ecrit par: Ophiucus Mercredi 22 Décembre 2004 à 19h46

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)

Ecrit par: Haiken Mercredi 22 Décembre 2004 à 20h54

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-de-donnees/sommaire.htm chapitre 5 par ex)

Ecrit par: Nonothehobbit Mercredi 22 Décembre 2004 à 22h13

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

Ecrit par: khiguard Jeudi 23 Décembre 2004 à 00h13

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. @+

Ecrit par: gorgu Jeudi 23 Décembre 2004 à 05h36

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

Ecrit par: Magauss Jeudi 23 Décembre 2004 à 10h24

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

Ecrit par: Sinclair Jeudi 23 Décembre 2004 à 10h58

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 ?

Ecrit par: Magauss Jeudi 23 Décembre 2004 à 11h05

QUOTE (Sinclair @ 23 Dec 2004, 10:58 ) 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

Ecrit par: Rataflo Jeudi 23 Décembre 2004 à 11h06

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.

Ecrit par: khiguard Jeudi 23 Décembre 2004 à 12h15

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. @+

Ecrit par: Haiken Jeudi 23 Décembre 2004 à 12h51

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 ...

Ecrit par: Ophiucus Jeudi 23 Décembre 2004 à 13h35

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

Ecrit par: Sinclair Jeudi 23 Décembre 2004 à 23h27

QUOTE (khiguard @ 23 Dec 2004, 12:15 ) Bien sinclair, tu viens de réinventer la roue 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.

Ecrit par: khiguard Vendredi 24 Décembre 2004 à 02h20

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. @+

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)