Il existe plusieurs façons de le faire, mais elles dépendent de l'endroit où vous aurez une grande quantité d'interactions ou une population très dense.
Malheureusement, si vous voulez que votre simulation conserve une bonne précision, vous devrez gérer la plupart des événements générés par tous les acteurs et trouver tous / la plupart des acteurs nécessitant une notification.
Collisions de zone bon marché
Concernant le problème des zones de sensibilisation, vous pouvez le résoudre en utilisant une détection de collision simple.
Dans un monde 2D, la détection de collision sur les cercles est "bon marché". Par exemple, l'opération pour détecter si un point est dans un cercle ne prend que 2 soustractions, 2 multiplications et un ajout. Vous n'avez pas besoin de faire la racine carrée car vous pouvez stocker et comparer directement le rayon carré de votre zone avec la distance carrée.
Si vous utilisez le cercle 2D dans un monde 3D, il fonctionnera essentiellement comme un cylindre. Cela peut être un moyen pratique de créer des zones si la hauteur n'est pas très importante.
Rayon orienté événements
Si le volume des événements (échanges de tirs, mouvements ...) est faible, vous pouvez essayer de détecter chaque acteur affecté par chaque événement. Vos événements généreront des zones (où ils pourront être entendus).
C'est la méthode la plus simple à mettre en œuvre, c'est aussi la plus flexible car vous pouvez détecter les impacts de balles / projectiles provenant d'acteurs en dehors d'une zone de sensibilisation.
D'un autre côté, une fois que le volume d'événements augmente, vous devrez peut-être réduire le nombre d'événements déclenchant des analyses de zone ou réduire le nombre d'acteurs analysés par événement.
-> Vous pouvez également créer de petites zones (d'événement) où tous les événements sont enregistrés ensemble et traités en bloc (c.-à-d. 2 impacts de balles et un pas de pied se produisant dans une zone n'utilisera qu'un seul balayage et sera envoyé à toutes les entités impactées). <-
Zones orientées acteurs
Vous pouvez utiliser le principe de "zone de sensibilisation". IE si un acteur entre en collision avec la zone de conscience (cercle) d'un autre acteur, vous ajoutez simplement l'acteur entrant en collision à une liste d'acteurs potentiellement en interaction. Selon la façon dont votre moteur est construit, vous pouvez ensuite vous inscrire aux messages sonores et autres événements provenant des acteurs de la liste.
Pour vérifier le contact visuel, vous pouvez également effectuer vos analyses visuelles uniquement sur la liste des acteurs enregistrés.
Vous n'avez pas besoin de vérifier les changements de zone de sensibilisation à chaque tick. Vous pouvez le faire de temps en temps, toutes les 5 à 30 ticks par exemple.
Si les listes commencent à s'allonger, vous pouvez les limiter à une taille maximale. Mais alors vous devrez prioriser les acteurs à ajouter / échanger dans les listes.
Approche mixte
Vous pouvez mélanger les deux approches. Vous pouvez enregistrer des acteurs dans des zones de sensibilisation pour des événements tels que les marches à pied, les nez de moteur, etc. ... Et d'autres événements (impacts de projectiles, explosions, etc.) peuvent déclencher des analyses en fonction de leur importance. Il y a beaucoup plus de chances que quelqu'un entende une explosion de grenade qu'un impact de balle, donc l'explosion de grenade devrait déclencher un balayage plus étendu que l'impact de balle.
Je vous recommande de commencer par implémenter le rayon d'événement. Une fois que celle-ci fonctionne et que vous pouvez réduire / augmenter la précision de cette méthode à volonté, vous pouvez commencer à mettre en œuvre les zones de sensibilisation des acteurs. De cette façon, vous pourrez commencer à déplacer certains événements vers le deuxième système.
Pools de contextes
Tous les acteurs n'ont pas besoin d'être informés de tous les événements. Par exemple, une tourelle anti-aérienne n'a pas besoin d'être informée des impacts de balles et des pas de pied autour d'elle, même la présence d'unités terrestres pourrait être ignorée pour certaines unités.
Si vous trouvez de nombreux cas spéciaux, vous pouvez créer différents pools de zones de sensibilisation. Un acteur peut activer sa zone de sensibilisation dans plusieurs pools. Par exemple, vous voudrez peut-être que vos unités terrestres réagissent aux unités terrestres uniquement tandis que certaines unités équipées de missiles et de lasers peuvent également réagir aux unités aériennes. Les aéronefs n'ont jamais besoin d'être informés des impacts au sol autres que les explosions ...
Bien sûr, vous n'avez pas besoin de créer plusieurs "listes" pour les pools. Vous pouvez simplement utiliser un masque de bits et définir le bon masque pour chaque acteur / zone. De cette façon, vous pouvez filtrer avec un simple ou avant de vérifier la distance.
Agrégation
Si vous voyez les listes dans chaque zone de sensibilisation s'allonger et que la mémoire est rare, vous pouvez agréger des zones de sensibilisation pour des groupes d'ennemis (équipes, escouades, pelotons, troupeaux, essaims ...) tant qu'ils restent proches les uns des autres. De cette façon, toute une équipe peut s'inscrire à des événements ou à d'autres acteurs / groupes entrant dans sa zone de sensibilisation.
Fondamentalement, l'entité de groupe devient un substitut / proxy pour toutes les analyses tandis que tous les membres du groupe sont supprimés des pools.
Ce principe peut également être appliqué à toutes les unités à l'intérieur d'un véhicule.
Activations de proximité
Si le serveur est vraiment surpeuplé de robots (et que vous devez vraiment les garder tous en vie), vous ne pouvez activer la sensibilisation / IA que sur ceux qui se trouvent dans une "zone d'activation spéciale autour de chaque joueur". De cette façon, les bots (ou groupes) à l'intérieur d'une ou plusieurs zones d'activation restent eux-mêmes et leur zone de conscience activée (dans le pool de collisions). Sinon, leur zone de sensibilisation est supprimée du ou des pools de zones actives.
La fréquence à laquelle ces «zones d'activation» recherchent des «zones de sensibilisation» peut varier en fonction de la vitesse du joueur. Un joueur voyageant à une vitesse plus élevée déclenchera plus d'activations qu'un joueur campant dans une zone (nécessaire au moins pour activer les robots itinérants et désactiver les robots qui quittent la zone).
Vous pouvez également désactiver la zone d'activation d'un joueur s'il monte à bord d'un véhicule et attribuer une zone d'activation au véhicule s'il n'en a pas. De cette façon, 10 joueurs voyageant dans le même véhicule n'ont pas besoin d'avoir 10 zones d'activation.
Délégation
Si vous ne craignez pas les tricheurs et autres fauteurs de troubles, vous pouvez déléguer une partie de la détection d'événements à l'application cliente.
Le serveur peut envoyer périodiquement une liste des acteurs à proximité (bots et joueurs) qui seront notifiés par les applications clientes. L'application cliente devra effectuer l'analyse et la détection des événements pour tous les événements générés par le lecteur. Il peut par exemple envoyer la liste des acteurs pour notifier un tir, un impact de balle ou des pas de pied.
C'est une option, elle peut être valable selon le type de jeu que vous créez. Il s'agit d'une idée théorique et je ne recommanderais pas de le faire jusqu'à ce que vous ayez un contrôle total sur les clients délégués (serveurs bots ou clients sécurisés).
J'espère que ça aide.