Les problèmes que j'entrevois pour un jeu en WS

[Xenos]

Comme le dit Ter Rowan.
Si tes zones sont trop petites, c'est pas grave. Admettons, ton joueur voit à 110 unités de distance (rayon de vue), chaque zone fait 25 unité de coté (zones carrées, formant un damier). Donc, le joueur peut voir des unités qui sont à 4, voire 5 zones de distance.
Le joueur est dans la zone [X,Y]. On cherche donc l'ensemble des zones potentiellement visibles par le joueur: ce sont toutes les zones de [X-5;Y-5] à [X+5,Y+5], bornes incluses. Donc, il faut traiter ces 11*11 zones (121).

Ce sera toujours plus rapide que de traiter toutes les zones, et de dire, pour chaque zone "est-ce que je peux voir cette zone?".

La position des ennemis qu'on ne peut pas voir n'est pas intéressante, et elle pousse à la triche, car le client reçoit les données des joueurs qu'il n'est pas censé voir, donc, on est tenté de hacker le jeu pour voir quand même ces ennemis !
Si ton joueur J ne peut pas voir un joueur K, alors K est totalement ignoré pour J, en d'autres mots, si J ne peut pas observer K, K n'existe pas pour J.
Si K émet des sons audibles par J (bruits de pas par exemple), alors on peut soit considérer que K existe pour J (on ne voit pas K, mais on l'entend), soit considérer qu'il faut créer un nouvel objet, "emetteur-sonore", placé en K, et qui existe pour J (mais K n'existe pas pour J: seul l'objet qui représente une émission sonore existe).

Donc, je ne vois pas pourquoi ce n'est pas un luxe que d'envoyer à J les données d'un objet (joueur ou autre) K totalement hors de la portée de vue et d'ouïe de J. Pour moi, c'est inutile...
Après, attention: J peut ne pas voir K (et donc, J ne reçoit pas les données de K), mais K peut voir J, et donc, K doit recevoir les données de J.

[Argorate]

Ah ok, je pensais que le principe c'était de prendre juste la zone courante + les adjacentes.
En fait faut définir la vision max, définir une taille de zone comme on veux et calculé en fonction de ça jusqu’à combien de zone de distance alentour on doit vérifier.
Mais du coup faire tout ça est plus long, pourquoi ne pas faire comme je disais et du coup on a pas a chercher les zones à vérifier, on sait que c'est 1 de distance max et voilà?

PS: dans ton exemple, tu prends juste le cas de la vision du joueur courant, sauf qu'un autre joueur peut peut être (selon le GP du jeu) voir un joueur sans que la réciproque soit vrai, du coup faut quand même checker chaque joueur un par un dans la liste des zones restreintes.



Évidement que c'est inutile, sauf que qq push en plus sans aucun calcule/algo (dans un monde où les joueurs irait pas cheater), ça serait sans doute plus rapide que de devoir filtrer pour chaque joueur vis a vis de chaque autre ce qu'on doit pusher. Tu vois ce que je veux dire? M'enfin c'est parlé pour rien dire, on est pas dans ce monde là^^

[Xenos]

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

[Argorate]

oui je parlais dans le cadre de mon exemple type fps.

Sinon les échange réseau c'est en ms aussi, dans un jeu pour etre bien faut avoir < 100 ms de ping. Mais je vois ce que tu veux dire, après le problème c'est que le serveur n'a pas que ça a calculé et c'est le cumul qui me fait peur. A tester ...

[Maks]

Moi je pense que tu te poses trop de questions, fait et voit

[Argorate]

Je pense qu'il faut un minimum évalué si c'est faisable avant de faire. Quand on voit le temps que ça prend, si c'est pour se rendre compte que ça suit pas techniquement c'est un peu dommage.

C'est pour ça que j'ai hâte de voir où on est ton projet par exemple^^

[Dexyne]

Si tu veux tu peux regarder le jeu Grits (et les sources) qui est une sorte de FPS en vu RTS.

L'auteur a d'ailleurs fait des vidéos dessus (ex: https://www.youtube.com/watch?v=Prkyd5n0P7k) où il explique comment il a procédé (dont le problème de latence et de découpage en zone par exemple).

[Maks]

@argoate Bombermine a prouvé que c'était possible (bon ok ils ont de bons serveurs), j'ai regardé leur source ils ont même un moteur de collision (box2d surement) ce qui demande pas mal de packets (websockets) pour maintenir synchronisé le client (ils réduisent surement la bande passante en ne communiquant que des données binaires plutot que du JSON).

@dexyne merci pour les liens je vais regarder ça

[Argorate]

Bombermine lag parfois bien comme il faut, mais oui je sais que c'est possible, c'est pas le soucis, c'est plutôt comment qui m’intéresse, je vais regarder la vidéo mais j'avoue qu'en anglais sans sous titre ça va être chaud XD

[Maks]

Je regarde la vidéo, dans le cas de leur jeu ils ont un moteur box2d ce qui complique clairement les choses niveau réseau ^^