+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Besoin d'avis pour un problème de table (/showthread.php?tid=2202)
Pages :
1
2
Besoin d'avis pour un problème de table - alfanor - 28-12-2007
Bien le bonjour à tous,
Je suis actuellement en train de mettre en forme ma BDD pour Eternal Battle V2, et je me vois confronté à un "problème" qui doit, je pense, ne pas être bien compliqué pour certains d'entres vous qui ont peut être déjà eu à faire ce choix.
Alors c'est assez simple, j'ai une table bâtiment de ce style :
- id_batiment
- id_race
- id_personnage
- id_ressource
- nom
- description
Et là, je dois dire le coût de ce bâtiment ainsi que les ressources nécessaire pour qu'il puisse tourner comme il faut (pour exemple, il lui faudrait 10 de minerai de fer et 5 de bois pour produire 5 de fer) et le problème qui se pose est donc de savoir s'il vaut mieux avoir une table cout_ressource du style :
- id_batiment
- id_ressource
- quantite
Ou bien un champ "cout" dans la table "batiment" qui serait formaté sous forme :
'id_ressource_1,quantite|id_ressource_2_quantite'
Et donc par la suite exploité avec des explode du côté PHP. Le problème pour les ressources nécessaire pour la production est donc le même.
Voilà si vous savez ce qui est le plus rapide/pratique merci bien de me le dire histoire que je ne m'embête pas à faire un truc qu'il faudrait modifier par la suite
RE: Besoin d'avis pour un problème de table - Asherah - 28-12-2007
Perso je metterais le cout diréctement dans la table batiments histoire de centraliser les données, ca seras plus pratique a manipuler et cela eviteras de faire 2 select si tu as besoins de plusieurs infos sur un batiment dont le cout.
Mais bon apres chacuns programme comme il veut.
RE: Besoin d'avis pour un problème de table - Mysterarts - 28-12-2007
Je ferai pareil aussi
Parfois il ne faut pas trop compliquer les choses...
Mysterarts
RE: Besoin d'avis pour un problème de table - naholyr - 28-12-2007
Je dirais que ça ne dépend que d'une chose :
- la liste des ressources possible est-elle elle-même dynamique ou fixe ?
Si tu n'as que 4 ressources (ex. fer, or, bois, charbon) et que cette liste est figée, alors autant ne pas t'emmerder et ajouter 4 colonnes à ta table "batiment".
Si ces ressources sont beaucoup plus nombreuses, ou que la liste est susceptible d'évoluer, alors il faudra travailler avec une table de liaison (c'est une liaison n-n, donc nécessitant une table intermédiaire).
La solution du champ avec la valeurs "collées", c'est de la bidouille à la mord-moi-le-noeud, à éviter à tous prix.
RE: Besoin d'avis pour un problème de table - alfanor - 28-12-2007
Effectivement les ressources sont évolutives, ce qui entraine aussi l'évolution des productions dans les bâtiments et l'évolution des ressources nécessaires pour la production. Enfin en gros tout est évolutif quoi.
Donc je vais essayer de faire cela avec des tables (enfin essayer ... pas bien compliqué lol)
Sinon pour "c'est de la bidouille ... à éviter à tout prix", c'est un avis personnelle ou c'est le résultat d'expériences ?
EDIT : Voilà, j'ai donc maintenant trois tables impliquées dans la construction d'un bâtiment, "batiment", "ressource" et "cout_ressource" (qui fais donc la liaison entre "batiment" et "ressource")
RE: Besoin d'avis pour un problème de table - alfanor - 29-12-2007
Bon j'ai donc fais cela avec des tables, mais maintenant j'ai un autre problème (pas lié aux ressource et bâtiment).
En fait mon jeu s'organise par planète, une planète possède des territoires (extensibles, en gros au départ une planète vide possède un territoire, après un joueur s'installe il y a donc deux territoires, celui du joueur et ce qui reste de celui de base qui est vide, et ainsi de suite si d'autres joueurs s'installent.), donc par définition un membre possède un certain nombre de territoire sur différentes planètes.
Le problème est donc ici la diplomatie. Je veux organiser cela comme il se doit, c'est à dire autre chose que les PNA/PT et autres trucs habituelles dénués de sens et d'intérêts sachant que la plupart du temps ils sont gérés humainement et donc très peut poussé au niveau gestion des relations.
Donc mon objectif est de rendre chaque entité "territoire" indépendante en plus d'avoir l'entité "membre" à côté, le but étant qu'un membre ai un statut par défaut diplomatique (par exemple considérer tout le monde comme allié si ceux-ci ne sont pas présent dans la liste des relations extérieurs) ainsi que des statut envers des joueurs (donc tout les territoires) et des statut envers des territoires (se soustrayant donc au statut principal envers le joueur). Donc je me retrouve avec trois tables.
- type_statut (membre y est lié afin de connaître la statut par défaut)
- statut_joueur (lié au type_statut pour connaître les différentes contraintes)
- statut_territoire (de même que statut_joueur)
Mais voilà ... comme les entités territoire et membre sont différentes, je me vois obligé (je crois) de faire 2 table "statut_joueur" et 2 tables "statut_territoire", une pour les relations des territoires et une pour les relations des membres ... Donc bien sûr cela m'ennuie quelque peu sachant que la structure de la table sera identique si ce n'est la table avec laquelle elle sera lié (une fois membre, une fois territoire).
Donc j'aimerai savoir si vous voyez une méthode pour n'obtenir que deux tables à l'arrivée en gérant indépendamment membre et territoire dans les statut diplomatique.
Voilà, si vous avez compris quelque chose, merci d'avance
RE: Besoin d'avis pour un problème de table - naholyr - 29-12-2007
Je ne comprends pas ton système diplomatique.
Si un joueur est en guerre contre le joueur J2, mais allié avec le territoire T1, le jour où J2 contrôle T1, il se passe quoi au niveau de tes statuts ?
Je ne pige pas le statut diplomatique d'un territoire en fait... Un territoire peut avoir une inimité pour un autre territoire, ou pour un autre joueur, sans que le joueur qui contrôle ce territoire n'ait rien à y redire ?
Pourrais-tu donner plusieurs exemples afin d'éclaircir les choses ?
Sinon si effectivement il y a 4 relations (Territoire->Territoire, Joueur->Territoire, Territoire->Joueur, Joueur->Joueur), il y aura 4 tables, ou une seule table générique à 5 champs :
(A [ID numérique], B [ID numérique], TypeA [joueur ou territoire], TypeB [joueur ou territoire], Statut [chaine ou nombre, dépend du reste de ta modélisation])
ou encore :
(JoueurA [ID], JoueurB [ID], TerritoireA [ID], TerritoireB [ID], Statut) où seul un champ *A et un champ *B doit être défini.
Mais dans tous les cas si j'ai bien compris ton truc, soit tu passes par 4 tables, soit la cohérence des données ne sera pas assurée par le seul schéma et devra donc être assurée par un outil de maintenance.
RE: Besoin d'avis pour un problème de table - alfanor - 29-12-2007
Mon système marche de cette façons :
Citation :Soit deux joueurs A et B en conflit.
A possède deux territoires T1 et T2
B possède deux territoires T3 et T4
Imaginons simplement que le territoire T2 est fraichement colonisé donc non apte à combattre sans aide de T1, pour protéger indirectement T2, le joueur A qui a comme relation diplomatique avec le joueur B "ennemi", mettra le statut diplomatique de T2 envers le joueur B comme "neutre" ou même "allié" afin de s'assurer que les soldats de T2 (soldats, vaisseaux, défenses terrestre & cie) ne tentent pas d'intercepter les armées du joueur B si elles venaient à passer dans la zone (une zone c'est une case de carte en gros) où est situé la planète sur laquelle T2 est présent.
Un autre exemple qui montre bien les possibilités d'un telle système est le suivant :
Citation :Soit deux joueurs A et B neutre entre eux (position diplomatique non définie ou bien définie comme "neutre").
A possède deux territoires T1 et T2
B possède deux territoires T3 et T4
Soit trois alliance C, D et E.
Le joueur A est membre de l'alliance D ainsi que de l'alliance E
Le joueur B est membre de l'alliance C
L'alliance D est neutre envers l'alliance C, mais l'alliance E déclare ennemi tout membre de l'alliance C et mandate le joueur A pour attaquer T3 appartenant au joueur B. Afin de faire son office sans pour autant trop risquer, le joueur A positionne T3 comme ennemi (et donc tout ce qui appartient à T3) mais positionne le joueur B comme neutre afin de ne pas engager de combat si ses troupes croisent des flottes de T4.
De plus il ne veut pas risquer de débarquement ennemi sur T1 et T2 et donc les places en "neutre" envers le joueur B afin qu'ils n'engagent pas le combat. (combat pouvant impliquer un débarquement des troupes du joueur B si celui-ci a paramétré l'armée en question pour qu'elle tente de prendre le contrôle de tout territoire tentant de l'intercepter (option risqué mais intéressante))
En gros bien que ce système puisse paraitre confus, il a pour but de rendre indépendant chaque territoire afin de pouvoir faire des guerres localisées au lieu de conflits aussitôt généralisées dès que A veut prendre un territoire à B et qu'il le palce donc en "ennemi" (ce qui implique des combats à chaque fosi que des troupes de A croisent des troupes de B).
Donc ce système est là pour permettre aux joueurs de gérer leur empire comme plusieurs entités séparées. (même si la plupart des joueurs mettront comme relation à appliquer par les territoires les relations définies par le joueur afin que toute entrée en guerre soit aussitôt généralisée.)
Pas sûr d'avoir été clair ^^
EDIT : Bon là en gros je me retrouve avec toutes ces tables pour gérer la diplomatie joueur/territoire :
- diplomatie_membre_membre
- diplomatie_membre_territoire
- diplomatie_territoire_membre
- diplomatie_territoire_territoire
Ces quatre là faisant appelle à :
- diplomatie_type_relation
Qui fait appelle à :
- diplomatie_effet_relation
Cette dernière permet de définir au niveau de l'administration du jeu ce qu'un type de statut diplomatique fait faire. (par exemple dire qu'en ennemi les marchands sont déclarés ennemi, mais dire qu'en neutre les marchands peuvent passer). Ça à l'origine je me suis dis que ce serait bien que les joueurs le gères eux mêmes que ça fasse de belles affaires de trahisons, mais je me suis dis que ça ferait vite foutoir pour pas grand chose donc je me limite à la gestion côté administration. Donc ça fait quand même 6 tables rien que pour la diplomatie, ça fait pas mal je trouve ... (en plus d'un champ "id_diplomatie_defaut" dans les tables territoires et membre pour établir la relation diplomatique à appliquer par défaut en cas de relation non établie (le joueur va pas s'amuser à mettre un statut diplomatique sur tout les joueurs))
RE: Besoin d'avis pour un problème de table - alfanor - 29-12-2007
Le but c'est justement que les petits malins, comme tu dis, (que je préfère nommer "joueur sachant jouer") parviennent à gérer comme il faut ce système pour éviter des combats, sauver la peau de leurs troupes ou tout simplement rendre ennemi deux entités neutre se croisant au même moment dont une est allié avec le petit malin qui est ennemi avec la deuxième.
Ce qui s'appelle justement du réalisme, c'est à dire autre chose que "gentil", "méchant" ("allié", "ennemi").
Sinon pour ton exemple, c'est ce que tu aimerais qu'il soit ou c'est parce que tu n'as pas compris mon exemple ? (car justement dans mon exemple tu es ennemi à T3 mais pas à T4).
Ce système est d'ailleurs surtout important pour les groupes armées afin de gérer les combats.
Après il est clair que je sais bien que seuls quelques joueurs sauront exploiter comme il faut ce système afin d'avoir des "avantages", les autres faisant bêtement appliquer la diplomatie "membre" à tout les territoires. (ce qui revient donc au système de n'importe quelle autre jeu et qui n'embête en rien le joueur vu qu'il a juste un clique à faire)
RE: Besoin d'avis pour un problème de table - alfanor - 29-12-2007
Justement non ! Il y a guerre et guerre. Les guerres 'totales' opposes tout un empire à un autre, mais les guerres les plus exploitées sont bien souvent celles politiques ou cachées (qui sont le plus souvent liées à la manipulation et au mensonge), c'est un point très important et il insiste sur le fait de ne pas savoir qui fait quoi comme par magie, en gros un joueur peut être attaqué sans savoir par qui il l'est, ce qui donne tout son sens à ce système de diplomatie qui sera donc très important tant au niveau de la stratégie qui deviendra tout autre que "foncer dans le tas" qu'au niveau des possibilités d'infiltrations grâce au fait que personne ne puisse tout connaître de nous sans notre accord direct (en gros un traité IG). (en gros quand on passe près d'une planète, c'est pas dis comme par magie "Joueur X contrôle cette planète !", c'est à eux de le découvrir par divers moyens (traités, espionnage, guerre ...), à part les territoires de bases (là où atterrit le joueur à son inscription) il n'y en a aucun où le dirigeant est connu comme par magie.
Bien sûr ça alourdit le jeu de gérer tout ce bazar, mais le but est d'obtenir quelque chose de différent et de compliqué, alors que ça prenne un jour ou un an à faire ça ne me dérange pas plus que ça ^^