Stratégies de gestion des foules aux points d'étranglement

J'ai récemment changé mon moteur de jeu des comportements de direction au mouvement basé sur les impulsions avec une résolution de collision appropriée en fonction du temps. Cela a résolu tant de problèmes (plus de tunneling, oui) et a rendu la simulation beaucoup plus stable. Cependant, avec la stabilité est venu un nouveau problème.

Les trois balles ont commencé leur voyage vers le bas de l'image, leur cible était l'endroit où la balle rose s'est arrêtée. Sur le chemin, les boules rouges et vertes se sont collées au point d'étranglement dans le mur.

Avant, je pouvais compter sur des erreurs en virgule flottante et l'instabilité générale des comportements de direction pour que les boules vertes et rouges se bousculent jusqu'à ce qu'elles parviennent à franchir le point d'étranglement. Maintenant, avec une résolution de collision appropriée, les forces agissant sur les billes s'annulent, ce qui fait que les billes restent parfaitement immobiles.

Quelles méthodes sont couramment utilisées pour résoudre de telles situations? Peut-être qu'une sorte de système de mise en file d'attente prioritaire fonctionnerait, bien que je puisse le voir devenir complexe une fois que je dois décider de la priorité entre plus de 2 objets.

collision-resolution

— Fibbles
source

Je suis également déçu de la gestion de la foule. Pourriez-vous s'il vous plaît ajouter quelques liens sur le "mouvement basé sur les impulsions" dans la question?

— Kromster

Une impulsion est juste force * temps. Ce que j'essayais de dire, c'est que j'avais opté pour un modèle à base physique utilisant une détection de collision continue plutôt que discrète. Les comportements de pilotage ne respectent pas vraiment des choses comme les lois du mouvement de Newton, ils ont été conçus pour imiter des troupeaux d'oiseaux plutôt que d'être une simulation physique. Je n'ai pas vraiment de liens gamedev pour le mouvement, c'est vraiment juste de la physique au lycée. Cependant, le livre de Christer Ericson Real Time Collision Detection est à peu près le jeu dev bible pour la détection de collision continue.

— Fibbles

Réponses:

Attribuez à chaque objet mobile un index unique et interdisez à un objet avec un index supérieur de déplacer un agent avec un index inférieur. Cela permettra aux objets «plus anciens» de pousser les «plus récents», mais pas l'inverse, ce qui représente moins de surcharge que la mise en file d'attente. Essentiellement, l'indice agit comme une priorité de mouvement.

— Pikalek
source

J'ai implémenté cela et cela fonctionne dans le sens où les unités ne sont plus bloquées, même si je dois dire que ce n'est pas toujours joli. Quelques mises en garde: utilisez uniquement l'index pour déterminer la priorité des objets en mouvement de la même masse, les gros objets doivent repousser naturellement les petits objets. Utilisez uniquement l'index pour déterminer la priorité des objets de la même équipe. Un objet ennemi ne devrait pas pouvoir servir de mur inamovible à un objet joueur simplement parce qu'il a été créé en premier et a donc une priorité plus élevée.

— Fibbles

Je n'avais pas envisagé la masse ou l'équipe; vos ajustements semblent être le moyen logique de corriger ma réponse.

— Pikalek

ajouter du temps à la recherche de chemin

voici un article qui parle de ce cube temporel: http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

et voici une implémentation Objective-C: http://allseeing-i.com/ASIPathFinder

— Rakka Rage
source

J'ai lu et mis en œuvre cela avant. Même avec plusieurs threads, ce n'est pas très utile dans ma situation. Dans un jeu RTS, il peut y avoir des centaines d'unités mobiles et de grilles de cartes qui sont supérieures à 500 carrés d'un côté. La surcharge pour le calcul des trajets basés sur le temps pour chaque unité est tout simplement trop élevée. Juste pour ajouter, je ne dis pas que la réponse de rakkarage est fausse, c'est un algorithme très soigné. Je dis simplement que les situations dans lesquelles il est utile sont limitées par sa complexité.

— Fibbles

ya je viens de relancer tout mon algorithme de recherche de chemin à chaque tour au lieu de bien comprendre et de mettre en œuvre cela, mais je pense que je devrais éventuellement le faire

— Rakka Rage

En fait, je ne pense pas que vous devriez le réparer. Si (je peux deviner) les flèches indiquent des vecteurs de force appliqués à n'importe quelle sphère, à n'importe quelle position dans la grille (probablement interpolés "bi-linéairement" ou de même, ou en quelque sorte plus "analogiques" que d'être simplement 0/1), eh bien alors le le comportement est physiquement correct et vous devez vous féliciter d'avoir une solution qui se comporte bien.

Les 2 sphères sont bien équilibrées, car elles sont là et se détestent. Apparemment, s'ils se déplacent un peu vers la droite, la "flèche de force" vers la droite affecte un peu plus la sphère droite (et vice versa sur la sphère gauche; un peu moins), et ainsi ils reviennent à l'équilibre. Ça devrait être comme cela.

À mon humble avis, que devrait être fixé, c'est le mur, ou la taille des sphères, ou quelque chose d'autre parmi les pierres de construction elles-mêmes. Vous avez créé une impossibilité et le comportement correct dans cette situation est donc une impasse (désolé pour avoir abusé des mots, j'espère que vous les obtiendrez quand même :-)).

Peut-être au lieu de cela désactiver les flèches de force gauche / droite les plus proches, ou les disposer d'une autre manière qui n'est pas symétrique et n'encourage pas à s'équilibrer ?

Je pense que ce serait une mauvaise solution de le réparer artificiellement ... deviendrait poilu trop tôt.

— Hurlevent
source

Cela ne répond pas à la question. Je comprends votre motivation, mais finalement la question est de savoir comment gérer la situation. Nous ne connaissons pas les intentions de gameplay, donc l'appréciation de savoir si c'est un problème ou non dépend de Fibbles. Changer le mur peut changer le but du chokepoint. La question est un problème valable qui peut être résolu.

— Felsir

Ma réponse est bascally: (re) organiser les forces ou réarranger quelque chose d' autre dans le scénario , mais ne brouillent le solveur de physique ( » IMHO, ce qui devrait être fixé est le mur ou la taille de la sphère, ou autre chose parmi les buildstones eux-mêmes. "). La question est " Quelles méthodes sont couramment utilisées pour résoudre de telles situations?" Je pense que mon A est une "méthode couramment utilisée" et une solution au problème. Par exemple, les jeux de minigolf en ligne (dont le Q rappelle beaucoup) étouffent les boules, si l'environnement demande que cela se produise. La physique erratique est une mauvaise façon, imo.

— Stormwind

Je suis d'accord que le solveur physique doit rester en contact. La question indique que les sphères doivent rechercher la cible, essentiellement comment changer les comportements des agents (donc pas la physique ou la disposition des niveaux). Modifier la disposition des niveaux peut résoudre ce problème, mais cela peut se produire dans une disposition différente. La question est donc différente de l'exemple de mini-golf que vous fournissez, car dans ce cas, la question est d'éviter spécifiquement une impasse.

— Felsir

Comme vous le voyez, je propose également de réorganiser les forces dans la réponse. Semble être un peu à gauche après cela :-).

— Stormwind

Réorganiser les murs ou modifier la taille des sphères n'est pas viable dans mon cas, bien que cela puisse l'être dans d'autres. La capture d'écran provient du mode de débogage d'un moteur RTS. Il existe de nombreuses tailles d'unités différentes et les murs peuvent être placés à volonté par le joueur. Les flèches que vous voyez sont générées par mon algorithme Fast Flow Fields. Ce sont des vecteurs normalisés qui sont utilisés pour influencer la direction de déplacement des unités mobiles. Il n'est pas possible de modifier la longueur des vecteurs car toutes les unités mobiles du groupe partagent le même champ de flux.

— Fibbles