Si tu es dans un FPS avec des joueurs qui ont tous les mêmes statististiques (ou à peu près), ok, ta méthode du "1 zone doit être plus grande que la distance de vue maximale de n'importe quel joueur" est acceptable.
Mais si tu as un RTS, dans lequel il y a de nombreux types d'unités, qui ont chacune une distance de vue différente (certaines voient à 10u, d'autres à 100u), alors, tu vas être obligé d'afficher 100u quelque soit l'unité traitée. En d'autres mots, un joueur (ou unité) avec une faible distance de vue pèsera aussi lourd qu'une unité qui a une grande distance de vue, et tu perds un peu de l'intérêt de l'optimisation. En effet, si tu multiplies le rayon de visibilité par 10, alors tu multiplie la surface par 100, et statistiquement, tu multiplies (en moyenne) le nombre d'unités par 100 aussi.
Donc, avec ton schéma "zone > distance_de_vue_maximum", l'optimisation ne sera pas 'optimale' si la distance de vue des unités est trop variable.
Oui, le joueur K qui voit J sans que J ne voit K va faire que le serveur "demandera" la position de J, mais sans dire à J pourquoi le serveur a besoin de cette position. Et oui, ce n'est pas un remède miracle: tout comme l'octree, un découpage tel que proposé ne fait que "dégrossir" le calcul, derrière, il faut checker chaque joueur, mais dans une zone beaucoup plus restreinte et donc, avec beaucoup moins de joueurs.
Or, les algorithmes qui traitent une paire d'objets dans un ensemble donné sont généralement quadratiques (la durée de calcul est proportionnelle à N², où N est le nombre d'objets dans l'ensemble, aka le nombre de joueurs). Donc, si tu divise par 10 le nombre de joueurs à traiter (N/10), tu divises presque par 100 le temps de calcul. L'optimisation n'est vraiment pas négligeable (par exemple, dans un autre cas, j'avais 1.000.000 de sommets sur un modèle 3D et je devais "souder" les sommets qui sont 2 à 2 "assez proche", c'est à dire souder toute paire de sommets qui sont distants de moins de R, constante fixée; sans octree aka sans découpage, cela prendrait 10h, avec découpage, cela a pris 10minutes).
Enfin, tout ce qui est du ressort du réseau est "infiniment" lent face à un calcul sur une machine. Un check du genre "Si joueur assez proche de", voir même "si joueur peut voir joueur2" se déroulera en quelques microsecondes, voir quelques ms. Une durée sur un réseau flotte plutôt autour de la seconde...
Mais si tu as un RTS, dans lequel il y a de nombreux types d'unités, qui ont chacune une distance de vue différente (certaines voient à 10u, d'autres à 100u), alors, tu vas être obligé d'afficher 100u quelque soit l'unité traitée. En d'autres mots, un joueur (ou unité) avec une faible distance de vue pèsera aussi lourd qu'une unité qui a une grande distance de vue, et tu perds un peu de l'intérêt de l'optimisation. En effet, si tu multiplies le rayon de visibilité par 10, alors tu multiplie la surface par 100, et statistiquement, tu multiplies (en moyenne) le nombre d'unités par 100 aussi.
Donc, avec ton schéma "zone > distance_de_vue_maximum", l'optimisation ne sera pas 'optimale' si la distance de vue des unités est trop variable.
Oui, le joueur K qui voit J sans que J ne voit K va faire que le serveur "demandera" la position de J, mais sans dire à J pourquoi le serveur a besoin de cette position. Et oui, ce n'est pas un remède miracle: tout comme l'octree, un découpage tel que proposé ne fait que "dégrossir" le calcul, derrière, il faut checker chaque joueur, mais dans une zone beaucoup plus restreinte et donc, avec beaucoup moins de joueurs.
Or, les algorithmes qui traitent une paire d'objets dans un ensemble donné sont généralement quadratiques (la durée de calcul est proportionnelle à N², où N est le nombre d'objets dans l'ensemble, aka le nombre de joueurs). Donc, si tu divise par 10 le nombre de joueurs à traiter (N/10), tu divises presque par 100 le temps de calcul. L'optimisation n'est vraiment pas négligeable (par exemple, dans un autre cas, j'avais 1.000.000 de sommets sur un modèle 3D et je devais "souder" les sommets qui sont 2 à 2 "assez proche", c'est à dire souder toute paire de sommets qui sont distants de moins de R, constante fixée; sans octree aka sans découpage, cela prendrait 10h, avec découpage, cela a pris 10minutes).
Enfin, tout ce qui est du ressort du réseau est "infiniment" lent face à un calcul sur une machine. Un check du genre "Si joueur assez proche de", voir même "si joueur peut voir joueur2" se déroulera en quelques microsecondes, voir quelques ms. Une durée sur un réseau flotte plutôt autour de la seconde...