[réglé] Un peu d'organisation... pour les performances

[uriak]

Bonjour,

J'en suis actuellement dans la phase de conception théorique de mon jeu, -ô originalité - un MMO. J'ai une expérience assez solide du C++ et donc de la programmation OO ,et des bases de php/mySQL, mises à l'érpeuves il y a quelques années de cela et que je vais rafraichir et renforcer pour l'occasion. Je pense avoir des idées assez claires sur la manière d'employer des BDD, mais je connais mal les limites du langage, et les problèmes de performances. Comme il s'agit de ne pas se faire suprendre au moment de concevoir les mécanismes clefs de mon jeu, je suis venu demander humblement quelques conseils ^^ afin d'organiser tout ça au mieux avant d'attaquer la phase programmation.

Donc une questions que je me pose est la suivante : Quelle genre de répartition des infos faut-il privilégier, dans les examples suivants ?
J'ai un abre de compétences. Une compétence n'est accessible qu'à condition d'en réunir plusieurs autres. Vaut-il mieux alor avoir une table comp_relations avec pour champ, une compétence, celle dont elle dépend, et le dégré de cette dernière? Ce qui donnerait du coup
comp_relations
{
Snipe , Tir, 3
Snipe, Observation, 2
}
pour définir que la compétence 'Snipe' nécessite Tir au lvl 3 et Observation au lvl 2
ou générer une table de dépendences pour chaque compétences, par exemple :
snipe_relations
{
Tir , 3
Observation 2
}
En bref vaut-il mieux insérer autant de liens que l'on veut dans une table unique, ou éclater des informations en plusieurs tables ? Ou plutôt à partir de quelle quantité (genre si une compétence en nécessite une dizaine d'autres, ou si j'ai une 60aine de compétences...)

Dans ce cas ce n'est pas trop critique. Mais imaginons le cas d'une map divisées en zones, appartenant à différentes régions. Vaudra-t-il mieux dans le cas de nombreuses zones(imaginons un monde de 1000 * 1000) et quelques régions (20-25..) :
Avoir une table de zones avec un champ région ?
Avoir 20-25 tables de régions avec leurs zones respectives ? Si je choisis ce dernier cas, il vaut mieux que toutes les informations relatives à une zone soient stockés par les éléments qui s'y trouvent, joueurs, ennemis, structures... Retrouver le type d'une zone devient plus complexe (il faut parcourir l'ensemble des tables de régions jusqu'à dénicher le champ). Est-ce que cela vaut la peine pour éviter une table à 1000 000 d'entrées ? :heuuu:

Merci d'avance. Je pense que j'aurais d'autres question d'organisation pour une prochaine fois :bounce:

[Roworll]

Bonjour.

Tout d'abord, je te conseille d'aller te présenter à la communauté dans la partie appropriée.
On apprendra à te connaitre un peu mieux et en plus tu verras plein de gens sympas passer te souhaiter la bienvenue.

Ensuite, pour ton premier problème de table, je choisirai sans hésiter une table de relation de type
Comp / Dépendance / niveau (comme ta première proposition en fait).
Plus souple et plus modulable.

Pour ta seconde question, j'ai un peu de mal à cerner ton problème.
Aurais-tu un ou deux exemples plus pratiques pour que l'on puisse se faire une petite idée ?

[uriak]

merci, je suis allé me présenter.

Pour la seconde question elle rejoint un peu la première ^^
vaut-il mieux une table du genre
zoning (id, x, y, land, other stuff...)
{
1, 0, 0, "startzone", ...
2, 1, 0, "startzone", ...
...
15728, -38, 227, "red mountains", ...

}

ou une série de tables par régions
startzone_terrain (id case, x, y)
{
1 ,0 ,0
2,1 0
...

28,8,6
}

En fait je ne sais pas ce qui est le plus long en sql, fouiller plusieurs petites tables ou faire des query dans des gros blocs. Et aussi si le fait d'avoir des informations redondantes est plutôt pratique ou gênant (dans le cas des compétences, par ex, la table unique oblige à citer n fois le nom de la compétence dont on donne les dépendances, alors qu'il est sous entendu dans le système de tables par compétence)

merci en tout cas

[Loetheri]

Pour les informations redondantes, DamEn a écrit un tutoriel dessus. Je te conseille d'aller le lire.

Pour ce qui est de grosses tables ou de plusieurs petites, il vaut mieux, à mes yeux, des tables moyennes (mouahahaha) où il y a de bons index ;-)

[Roworll]

Je dirais que ça dépends...

Déjà, conceptuellement, si tu dois avoir une répétition de quelques valeurs littérales dans une table avec des milliers d'enregistrement, mieux vaut faire une table de référence.
Pour reprendre ton exemple, je transformerai

Code :

zoning
id       x      y  land             other stuff
1        0      0  "startzone"      ...
2        1      0  "startzone"      ...
...
15728  -38    227  "red mountains"  ....

en

Code :

zoning
id     x      y  land   other stuff
1      0      0  1      ...
2      1      0  1      ...
...
15728  -38  227  12     ...

et

zone_name
id   land
1    startzone
...
12   red mountains

Ca évitera la redondance du libellé des zones.

Ensuite, faire une grosse table avec tout dedans ou plusieurs petites, bah comme j'ai dit, ça dépends.
Une grosse table sera plus propre et plus standard que plein de petites calquées sur le même modèle après, ils faut voir les performances.

Mon premier projet comprenait des cartes de 30x30 réparties en une 20aine de zones. (18 0000 cases en gros).
Rien de monstrueux mais la table était soumise à tellement de modifications (je rappelle que MySQL 4.0 en myIsam fait des tablelock pour les ajouts/update) que j'ai du éclater cette grosse table en plusieurs petites.

Avec une version/moteur plus performant, il n'est pas sur que ce problème survienne.

[uriak]

Je vois. Dans mon cas spécifique j'aurais probablement besoin d'afficher les environs de la position du joueur donc typiquement le tas de 11*11 cases centré sur lui. Comme c'est une action récurrente et probablement demandée par quantités de joueurs à intervalles proches, la présence d'une grande table unique peut poser problème....
Est-ce que cela vaudrait la peine d'instaurer un des mécanismes suivants ?

- division de la table des zones par grands secteurs (carrés de 100*100 par exemple) et faire la requête en deux temps : 1 chercher le(s) secteur(s) contenant toutes les cases dans le voisinage du joueur. 2 faire les queries sur les secteurs concernés donc 1 à 4 tables de 10000 entrées. Ce système assure que toute query se fera au maximum sur 4% du total des cases.
- travailler par différence pour les déplacement. Si un joueur change son abscisse de 1, je charge juste la colonne de cases d'abscisse x+11 pour pouvoir l'afficher. J'imagine que je peux garder les infos utiles sur les autres à l'aide d'une array.

Ho et une dernière chose. Dans les cas de projet faisant appel à de nombreuses fonctions php, j'imagine qu'on utilise des "simili-headers" soit des pages php contenant des définitions de fonctions regroupées par thème, et qu'on inclut dans les pages nécessaire. Ou est-ce qu'il y a de meilleures méthodes pour s'organiser ?

[uriak]

Aller je relance un peu Je ne cherche pas LA solution à tel ou tel problème, mais suis à la recherche de "bonnes pratiques"

Donc sujet de débat : je cherche à gérer des arbres de compétences ("graphe" étant plus exact")
On me propose la table suivante :
Relations (id_comp, id_subcomp, dep_value) (identifiant compétence, compétance requise, level de requis)
{
3,0,1
4,1,2
4,0,1
}

couplée avec une table de compétence possedant la cled servant aux id
Mais si maintenant j'introduit un arbre de technologies, qui entraînent d'autres dépendances :
exemple : "forge : acier sanglant" nécessite "forge" et "technologie : alliages supérieurs"

devrais-je m'orienter vers deux tables : dépendances comp, dépendances tech ?
ou une table unique de la forme ?
Relations (id_comp, id_dep, type_dep, level_dep)
avec un short/char/petit entier type_dep qui me donne le type de dépendance et donc le type d'identificateur contenu dans id_dep (qui peut donc être une compétence ou une techno).

Pire si je veux que les techno dépendent de techno ET de compétences (ha que je veux faire un jeu subtil, moi ^^ ) Si je choisis une table unique cela donnera :
Relations (id_rel, id_dep, type_dep, level_dep) avec cette fois id_rel ET id_dep pouvant se référer à une compétence OU une techno et type_dep donnant toujours le type de relation et donc la nature de id_dep et id_rel. par ex :
0 : comp -> comp
1 : comp -> tech
2 : tech -> comp
3 : tech -> tech

donc à votre avis une telle implémentation est-elle à privilégier plutôt que celle de 4 tables de relations ?

Et une dernière chose : dans le cas de joueur avec un inventaire, une liste d'amis, de comp, etc... vous auriez tendance à faire une table par joueur, ou faire des tables de relations semblables à celles dont j'ai parlé ? Dans le cas des tech/comp, ce sont des données sous contrôle des admins, alors que les joueurs s'inscrivent et évoluent à leur gré, donc les chiffres sont incontrôllables...

[Pouipoui]

Hello!
Pour tes tables comps-tech, je ne saurais pas trop que te conseiller, mais je ne pense pas que cela change grand chose, à mon avis, tu peux faire comme tu préfères.

Par contre, pour tout ce qui est inventaire, liste d'amis,etc....là, il faut faire des tables de relations.
Une table par joueur, ça va être l'horreur avec un grand nombre de joueurs.

[uriak]

merci, c'est également ce que m'a conseillé un ami ^^

concernant la manière de relier telle ou telle compétence avec la classe/foction correspondante je pensais déclarer une série de classes du type :

Code PHP :

<?php 

class comp_x

{

 public function execute($args...)

{...}

} 

[elazard]

bah oui jusque là c'est la base de la poo après évidement ca dépend ce que tu mettra dedans .