17-06-2013, 07:05 PM
Citation :Mais du coup, faire un algo qui parcours tout les joueurs, calcule le champs de vision et regarde si je suis dedans pour savoir si oui ou non il faut les pusher, ça me semble hard niveau temps, tout ce temps de calcul est "perdu" et risque de crée des problèmes de fluiditer.2 mots: Arbre binaire. (ou 1 mot: régionalisation, cela revient au même).
L'idée est de découper la carte en zones statiques (qui bougent pas dans le temps), et de dresser une table qui permet de savoir quelles zones sont liées entre elles (voisines).
Après, le joueur appartient à 1 seule zone (si le joueur est un point). Pour tous les joueurs de la zone courante, plus les joueurs des zones voisines, le serveur crawle et fait le teste du champ de vision. Pour toutes les autres zones, inutile de faire le test: les joueurs dans ces zones sont forcément trop loin.
Après, mais c'est un avis personnel, tu ne résoudras pas le problème du "serveur surchargé s'il y a des centaines de personne en temps réel". Pourquoi? parce que cette problématique, cela fait plus d'une dizaine d'année qu'elle existe dans les jeux classiques (ceux qui nécessitent une installation): au bout de 16 (puis après, ca a été 32, 64 et maintenant, au mieux, une centaine) de joueurs, le serveur rame.
Donc, à mon sens, le problème n'est pas "comment j'implémente du temps réel?" mais "est-ce que j'ai vraiment besoin d'un pur temps réel?", car implémenter un temps réel, qui plus est par navigateur, qui plus est avec des budgets amateurs, cela me semble totalement cramé... Mais faut pas que ca te décourage trop quand même ^^
Pour la sécurité, j'en sais rien.
Pour les FPS, je sais que Supreme Commander a une solution assez élégante: au lieu de faire des transferts dans tous les sens pour chaque mouvement, le serveur ne fait qu'envoyer, régulièrement, un "paquet" contenant une liste d'évènements majeurs, avec leur date d'occurence. Le client récupère cette liste, et se "recadre" avec ce que dis le serveur. Entre deux listes, le client fait le calcul lui même (cela implique d'avoir une "implémentation javascript", aka coté client, de ce que le serveur fait).
Avec ce système, Sup Com arrive à tenir 8 joueurs et des centaines (1.000 max) d'unités par joueur, sans trop ramer (bon, 8 joueurs avec 1.000 unités, ca dérouille sec, mais ça peut passer).