18-12-2008, 02:34 PM
question: est-ce que le nombre de pays est limité ou pas ? (soit parce qu'il est fixe; soit parce que tu décide que y aura jamais plus de X pays actifs à un moment donné)
parce que si je comprends la manière dont ta conçu ton gameplay et donc la construction de ta bdd; le point critique c'est vraiment entre autre le nombre de pays (bien plus que le nombre de table).
Or si tu décide de rester en illimité tout en te payant le luxe de nombreuses tables de relation: n<->n, n<->m ou t'as n et m qui tend vers illimité (puisque fct direct du nombre de pays, ou objet auto généré par l'appli) tu pars pas gagnant. (pour n<->n, ok à 10 joueurs ça te fais de lordre de moins de 100 entrée, tranquille, à 1000 joueurs tu passe à un ordre de 1M ça devient déjà moins léger; si t'as le malheur de voir ton jeu devenir un hit à 100'000 d'inscrit tu vas commencer à être mal).
Le jeu à l'air super chindé au niveau de détail/complexité/réalisme du gameplay (ça donne envie de voir). Mais peut-être un peu trop^^ ? C'est peut-être pas la conception des tables qu'est bancale, mais le concept du jeu qu'est trop gros pour ce que tu peux t'offrir.
sinon y a des trucs: t'as une table:
id_diplo / diplopaysa / diplopaysb / score
1 / Espagne / France /75(%)
2 / Espagne / Portugal /21(%)
3 / France / Portugal /56(%)
si t'as d'autre du même genre avec les mêmes "clés" n<->n (la je parle pas de ton id_diplo; mais de ta vrai clé discriminante pour ton entrée (qui détermine donc les nombre max d'enregistrements dans ta table: càd id_pays1 + id_pays2) tu devrais pour rationaliser ta bdd regrouper tes tables sur ces mêmes "clés". (après le soucis sera les lock de ta table si t'as bcp d'écriture et que t'es en mysql avec le moteur myisam)
(parce qu'apparemment c'est possible^^ genre distance entre pays -bon sauf que là je pense pas que mon exemple soit au point, vu que la distance tu l'as par coordonnées des 2 pays; c'est pour le principe-)
si tu peux pas gagner grands chose avec ça; y aura pas de miracle (tu peux toujours optimiser la taille de chaque champs de tes tables aussi; mais au final tu ne résoudra pas le problème premier: ta conception)
comme tu le dis "y a énormement de possibilités"... et c'est bien ça le soucis; c'est que tu as conçu ton gameplay de sorte que tu te retrouve pas seulement à avoir énormément de possibilités; mais surtout c'est que tu dois stocker toutes ces possibilités. C'est là t'as plus grosse erreur.
je sais pas si je suis claire ? Je vais prendre les échecs: t'as un nombre de cases limités (64); un nombre de pièces limités aussi (2*16 et encore moins si on compte par type de pièces). Chaque type de pièces à un nombre de déplacement possible assez limité. Et au départ d'une partie il n'y a qu'une seule disposition possible et que 2 joueurs. ça n'empêche pas que le nombre de parties distinctes possibles soient astronomiques. (aucunes idées de la taille de base de données qu'il faudrait pour toutes les stocker, mais ça doit être mastocke
)
Ton problème majeur est donc de faire le contraire; tu n'as pas optimisé ton jeu pour maximiser l'efficience des possibles. T'es parti du "plus j'aurais de bidules" plus mieux ça sera.(et tu semble restreindre au max le champs des possibles: la diplo entre 2 pays ce sera "juste ça" et tu conclusur le concept de stocker autant de possibilité que possible).
d'après moi t'as zapé dans ta conception (ton gamedesign) le point ressources techniques et matérielles disponibles^^ (je vais te dire que t'es pas le seul; moi ça me saoule quand je conçois mes petits truc d'y consacré du temps; je me le répète à chaque fois que je me fais avoir: l'optimisation ça commence pas quand on code, mais quand on conçoit).
enfin bon je suis pas le mieux pour juger; j'en suis qu'à la conception de mon premier jeu ... je risque de faire moins le malin dans quelque temps ^_^'
parce que si je comprends la manière dont ta conçu ton gameplay et donc la construction de ta bdd; le point critique c'est vraiment entre autre le nombre de pays (bien plus que le nombre de table).
Or si tu décide de rester en illimité tout en te payant le luxe de nombreuses tables de relation: n<->n, n<->m ou t'as n et m qui tend vers illimité (puisque fct direct du nombre de pays, ou objet auto généré par l'appli) tu pars pas gagnant. (pour n<->n, ok à 10 joueurs ça te fais de lordre de moins de 100 entrée, tranquille, à 1000 joueurs tu passe à un ordre de 1M ça devient déjà moins léger; si t'as le malheur de voir ton jeu devenir un hit à 100'000 d'inscrit tu vas commencer à être mal).
Le jeu à l'air super chindé au niveau de détail/complexité/réalisme du gameplay (ça donne envie de voir). Mais peut-être un peu trop^^ ? C'est peut-être pas la conception des tables qu'est bancale, mais le concept du jeu qu'est trop gros pour ce que tu peux t'offrir.
sinon y a des trucs: t'as une table:
id_diplo / diplopaysa / diplopaysb / score
1 / Espagne / France /75(%)
2 / Espagne / Portugal /21(%)
3 / France / Portugal /56(%)
si t'as d'autre du même genre avec les mêmes "clés" n<->n (la je parle pas de ton id_diplo; mais de ta vrai clé discriminante pour ton entrée (qui détermine donc les nombre max d'enregistrements dans ta table: càd id_pays1 + id_pays2) tu devrais pour rationaliser ta bdd regrouper tes tables sur ces mêmes "clés". (après le soucis sera les lock de ta table si t'as bcp d'écriture et que t'es en mysql avec le moteur myisam)
(parce qu'apparemment c'est possible^^ genre distance entre pays -bon sauf que là je pense pas que mon exemple soit au point, vu que la distance tu l'as par coordonnées des 2 pays; c'est pour le principe-)
si tu peux pas gagner grands chose avec ça; y aura pas de miracle (tu peux toujours optimiser la taille de chaque champs de tes tables aussi; mais au final tu ne résoudra pas le problème premier: ta conception)
comme tu le dis "y a énormement de possibilités"... et c'est bien ça le soucis; c'est que tu as conçu ton gameplay de sorte que tu te retrouve pas seulement à avoir énormément de possibilités; mais surtout c'est que tu dois stocker toutes ces possibilités. C'est là t'as plus grosse erreur.
je sais pas si je suis claire ? Je vais prendre les échecs: t'as un nombre de cases limités (64); un nombre de pièces limités aussi (2*16 et encore moins si on compte par type de pièces). Chaque type de pièces à un nombre de déplacement possible assez limité. Et au départ d'une partie il n'y a qu'une seule disposition possible et que 2 joueurs. ça n'empêche pas que le nombre de parties distinctes possibles soient astronomiques. (aucunes idées de la taille de base de données qu'il faudrait pour toutes les stocker, mais ça doit être mastocke
)Ton problème majeur est donc de faire le contraire; tu n'as pas optimisé ton jeu pour maximiser l'efficience des possibles. T'es parti du "plus j'aurais de bidules" plus mieux ça sera.(et tu semble restreindre au max le champs des possibles: la diplo entre 2 pays ce sera "juste ça" et tu conclusur le concept de stocker autant de possibilité que possible).
d'après moi t'as zapé dans ta conception (ton gamedesign) le point ressources techniques et matérielles disponibles^^ (je vais te dire que t'es pas le seul; moi ça me saoule quand je conçois mes petits truc d'y consacré du temps; je me le répète à chaque fois que je me fais avoir: l'optimisation ça commence pas quand on code, mais quand on conçoit).
enfin bon je suis pas le mieux pour juger; j'en suis qu'à la conception de mon premier jeu ... je risque de faire moins le malin dans quelque temps ^_^'