Quelles données doivent être mises en cache sur un serveur multijoueur, par rapport à l'IA et aux joueurs?

8

Dans un endroit virtuel, entièrement piloté par le réseau, avec un nombre arbitraire de joueurs et un nombre arbitraire d'ennemis, quelles données doivent être mises en cache dans la mémoire du serveur, afin d'optimiser la simulation de l'IA en douceur?

Essayer d'expliquer, disons que le joueur A voit le joueur B à E, et l'ennemi A à G. Chacun de ces joueurs, voir le joueur A, mais pas nécessairement les uns les autres. Il en va de même pour les ennemis. Pensez à cette question dans une perspective descendante s'il vous plaît.

Dans de nombreux cas, par exemple, lorsqu'un joueur tire avec son arme, le serveur traite le son comme un "signal" radial que toutes les autres entités à portée de main "entendent" et réagissent.

Faire ces recherches tout le temps pour une zone entière, contenant éventuellement beaucoup de joueurs et d'ennemis indépendants, semble être un problème, lorsque le budget de chaque agent IA est si petit.

Chaque entité doit-elle mettre en cache tout ce qui entre et sort de son rayon de conscience? Existe-t-il un excellent moyen de retracer les entités proches sans inonder la mémoire avec de tels caches?

Qu'en est-il des autres problèmes liés à l'IA qui peuvent survenir, après avoir supposé que le précédent fonctionne bien? Nous parlons d'environnements avec peut-être des centaines d'ennemis, un essaim.

ai multiplayer Grimshaw
la source
Cela dépend un peu du nombre de joueurs et de l'IA et ainsi de suite dans le jeu. Par exemple, les MMO utilisent des choses comme des graphiques de scène pour rechercher rapidement qui est proche de quoi pour des choses comme vous le mentionnez ci-dessus, alors qu'un jeu FPS qui ne suit que peut-être 30 choses au total, ce serait exagéré et juste une liste chaînée de 30 entités est probable suffisant. Pouvez-vous être un peu plus précis dans vos paramètres? Avec seulement 5 joueurs et 7 IA, je dirais que vous n'avez rien à faire de spécial, en plus d'avoir les 13 entités chargées en mémoire comme d'habitude.
James
Un cas absolument moyen du monde du jeu est en tant que tel: plus de 20 régions, comme dans la ville et les environs. Chaque région est ce que nous considérons ici et elle est subdivisée récursivement par des zones, comme un graphique de scène comme vous l'avez dit. Une zone peut être encore plus grande que la conscience de l'entité, et peut parfaitement contenir 100 ennemis ou plus, et N'IMPORTE QUEL nombre de joueurs. Bien sûr, il y a des zones vides, mais aussi surpeuplées
Grimshaw
1
Je suis très intéressé par les commentaires sur cette question.
Coyote

Réponses:

7

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.

Coyote
la source
Votre réponse semble définir la plupart des méthodes qui existent, fantastique! Faire un mélange de tous semble être un bon choix, pour une telle application critique en termes de performances, tout doit être fait en détail, en évitant de surcharger ici et là. De plus, je pense vraiment que si le client fait autorité sur TOUT, il peut et sera trompé: P
Grimshaw
Oui ... mais si vous pouvez déléguer certaines choses au client maintenant, vous pourrez déléguer plus tard aux serveurs secondaires si vous le souhaitez, en restreignant la délégation uniquement aux serveurs et en la désactivant sur les clients. Mais juste une idée :)
Coyote
C'est une bonne idée, mais les joueurs exploiteront toujours quand il deviendra compétitif ... Je préfère utiliser la puissance de traitement client pour le plaisir des yeux et des trucs pour améliorer l'expérience, le son, les graphiques, etc. Le serveur n'a pas besoin de tout suivre, certains les choses que le client peut assumer sans permettre de tricher. Quoi qu'il en soit, merci beaucoup pour la réponse, encore une fois, cela aidera à équilibrer les choses!
Grimshaw