Strategie per affrontare le folle nei punti di soffocamento

Di recente ho cambiato il mio motore di gioco dai comportamenti di guida a movimenti basati sugli impulsi con una corretta risoluzione delle collisioni basata sul tempo. Ciò ha risolto così tanti problemi (niente più tunneling, yay) e reso la simulazione molto più stabile. Tuttavia, con la stabilità è arrivato un nuovo problema.

Le tre palle hanno iniziato il loro viaggio vicino al fondo dell'immagine, il loro obiettivo era dove la palla rosa si è fermata. Lungo la strada le palline rosse e verdi si sono incastrate nel punto di strozzamento nel muro.

Prima, potevo fare affidamento sugli errori in virgola mobile e sull'instabilità generale dei comportamenti di sterzata per far sussultare le palle verde e rossa fino a quando non riuscivano a superare il punto di strozzamento. Ora con un'adeguata risoluzione delle collisioni, le forze che agiscono sulle sfere si annullano a vicenda, il che si traduce nella perfetta stabilità delle sfere.

Quali metodi sono comunemente usati per risolvere tali situazioni? Forse una sorta di sistema di accodamento prioritario funzionerebbe, anche se posso vederlo diventare complesso una volta che devo decidere la priorità tra più di 2 oggetti.

collision-resolution

— Fibbles
fonte

Sono anche deluso dalla gestione della folla direttrice. Potresti aggiungere alcuni link sul "movimento basato sugli impulsi" alla domanda?

— Kromster,

Un impulso è solo forza * tempo. Quello che stavo cercando di dire era che mi ero trasferito a un modello basato fisicamente usando il rilevamento di collisioni continuo piuttosto che discreto. I comportamenti di guida non rispettano cose come le leggi del movimento di Newton, sono stati progettati per imitare gli stormi di uccelli piuttosto che essere una simulazione fisica. Non ho davvero alcun link di gioco per il movimento, è davvero solo la fisica delle scuole superiori. Tuttavia, il libro di Christer Ericson Real Time Collision Detection è praticamente la bibbia del gioco per il rilevamento continuo delle collisioni.

— Fibre,

Risposte:

Assegna a ciascun oggetto mobile un indice univoco e proibisci a un oggetto con un indice superiore di spostare un agente con un indice inferiore. Ciò consentirà agli oggetti "più vecchi" di dare una spinta a quelli "più nuovi", ma non viceversa ed è meno costoso del fare la fila. In sostanza, l'indice agisce come una priorità di movimento.

— Pikalek
fonte

Ho implementato questo e funziona in quanto le unità non si bloccano più, anche se devo dire che non è sempre carino. Alcuni avvertimenti: utilizzare l'indice solo per determinare la priorità per lo spostamento di oggetti della stessa massa, oggetti di grandi dimensioni dovrebbero spingere i piccoli oggetti in modo naturale. Utilizzare l'indice solo per determinare la priorità per gli oggetti nella stessa squadra. Un oggetto nemico non dovrebbe essere in grado di agire come un muro immobile per un oggetto giocatore semplicemente perché è stato generato per primo e quindi ha una maggiore priorità.

— Fibre,

Non avevo considerato la massa o la squadra; le tue modifiche sembrano il modo logico di rattoppare la mia risposta.

— Pikalek,

aggiungere tempo alla ricerca del percorso

ecco un articolo che parla di quel cubo di tempo: http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

e qui c'è un'implementazione di Objective-C: http://allseeing-i.com/ASIPathFinder

— Rakka Rage
fonte

Ho letto e implementato questo prima. Anche con più thread non è molto utile nella mia situazione. In un gioco RTS possono esserci centinaia di unità mobili e griglie della mappa che superano i 500 quadrati di lato. Il sovraccarico per il calcolo dei percorsi basati sul tempo per ogni unità è troppo alto. Solo per aggiungere, non sto dicendo che la risposta di rakkarage sia sbagliata, è un algoritmo molto accurato. Sto solo dicendo che le situazioni in cui è utile sono limitate dalla sua complessità.

— Fibre,

ya rieseguo il mio intero percorso per trovare l'algoritmo ogni giro invece di comprenderlo e implementarlo completamente, ma immagino che alla fine

— dovrei doverlo fare

In realtà, non penso che dovresti risolverlo. Se (immagino) le frecce indicano i vettori di forza applicati a qualsiasi sfera, in qualsiasi posizione nella griglia (probabilmente interpolata "bi-linearmente" o similmente, o in qualche modo più "analogica" rispetto al semplice essere 0/1), allora il il comportamento è fisicamente corretto e dovresti congratularti con te stesso per avere una soluzione ben comportante.

Le 2 sfere sono in buon equilibrio, mentre si siedono lì e si odiano a vicenda. Apparentemente, se si spostano un po 'verso destra, la "freccia della forza" a destra influenza un po' di più la sfera del lato destro (e viceversa sulla sfera del lato sinistro; un po 'meno), e quindi ritornano in equilibrio. Ecco come dovrebbe essere.

Imho, ciò che dovrebbe essere riparato è il muro, o le dimensioni della sfera, o qualcos'altro tra le pietre stesse. Hai creato un'impossibilità e il comportamento corretto in quella situazione è di conseguenza un punto morto (scusami per le parole sbagliate, spero che le capisca comunque :-)).

Forse invece disabiliti le frecce di forza sinistra / destra più vicine o disponile in un altro modo che non sia simmetrico e non incoraggi l'equilibrio ?

Penso che sarebbe una brutta soluzione ripararlo artificialmente ... diventerebbe peloso troppo presto.

— Stormwind
fonte

Questo non risponde alla domanda. Capisco la tua motivazione, ma alla fine la domanda è come affrontare la situazione. Non conosciamo le intenzioni di gioco, quindi il giudizio se questo è un problema o no dipende da Fibbles. La modifica del muro può cambiare lo scopo del punto di arresto. La domanda è un problema valido che può essere risolto.

— Felsir,

La mia risposta è basicamente: (ri) sistemare le forze o riorganizzare qualcos'altro nello scenario ma non rimescolare il risolutore di fisica (" Imho, ciò che dovrebbe essere riparato è il muro, o le dimensioni della sfera, o qualcos'altro tra le pietre loro stessi "). La domanda è " Quali metodi sono comunemente usati per risolvere tali situazioni?" Penso che la mia A sia molto un "metodo comunemente usato" e una soluzione al problema. Ad esempio i giochi di minigolf online (che la Q ricorda molto) soffocano le palle, se l'ambiente chiede che ciò accada. La fisica erratica è una cattiva strada, imo.

— Roccavento,

Sono d'accordo che il risolutore di fisica dovrebbe rimanere in contatto. La domanda afferma che le sfere dovrebbero cercare l'obiettivo, fondamentalmente come cambiare i comportamenti degli agenti (quindi non la fisica o la disposizione dei livelli). La modifica del layout di livello può risolvere questo problema, ma può apparire in un layout diverso. Quindi la domanda è diversa dall'esempio di minigolf che fornisci poiché in questo caso la domanda è quella di evitare specificamente un deadlock.

— Felsir,

Come vedi, propongo anche di riordinare le forze nella risposta. Sembra essere rimasto poco dopo che :-).

— Roccavento,

Riorganizzare le pareti o alterare le dimensioni della sfera non è fattibile nel mio caso, sebbene possa essere in altri. Lo screenshot è dalla modalità di debug di un motore RTS. Esistono diverse dimensioni dell'unità e le pareti possono essere posizionate a piacimento dal giocatore. Le frecce che vedi sono generate dal mio algoritmo Fast Flow Fields. Sono vettori normalizzati che vengono utilizzati per influenzare la direzione di marcia delle unità mobili. Non è possibile modificare la lunghezza dei vettori perché tutte le unità mobili nel gruppo condividono lo stesso campo di flusso.

— Fibre