Wzajemne śledzenie obiektów

Witam,

W przypadku gdy A śledzi obiekt B, to miejsce kolizji (prędkość i kierunek A) można określić poprzez zwykły rachunek wektorowy (poprzez obliczenie położenia końcowego B).

Problem pojawia się gdy A śledzi obiekt B, a B śledzi obiekt A,
albo w bardziej skomplikowanej sytuacji, gdy:
A śledzi B,
B śledzi C,
C śledzi A,

W obu przypadkach są to układy zamknięte i "intuicyjnie" można czuć, że punkt spotkania nastąpi w środku układów.

Niestety nie wiem jak to przełożyć na język zrozumiały dla komputera tak, aby:
- program rozpoznawał że układ jest zapętlony,
- wyliczał punkt kolizji,

Metoda #1: obliczenie pozycji kolizji bazując na kierunku i prędkości celu
Efekt -> zamiana obiektów miejscami

Metoda #2: przesunięcie obiektu śledzącego cel ruchomy na koniec kolejki
Efekt -> nieskończona pętla

Metoda #3: pętla z podziałem na coraz krótsze odcinki czasowe
Efekt -> spowolnienie pracy wskutek stosowania pętli, za KAŻDYM razem gdy celem jest inny obiekt
(pętla tak długo, aż obiekt nie zmieni swojego położenia)


Wydaje się że metoda 3 jest najbardziej użyteczna, ale stosowanie osobnej pętli dla każdego obiektu (jeżeli śledzony obiekt śledzi inny obiekt) indywidualnie będzie czasowo kosztowne.
Fakt faktem, na każdą sesję (turę) tych obiektów będzie raptem kilka...

Co o tym myślicie? Może jakieś inne rozwiązania? 

Chcesz żeby to była najkrótsza możliwa trasa?

Tak. Oczekiwałbym najkrótszej możliwej trasy.

Próbuję wykorzystać pętlę (ma najwięcej sensu wg mnie), ale wyniki nie pokrywają się z oczekiwaniami:
Przy układzie takim jak poniżej (A i B są na rogach kwadratu, A i B mają stałą prędkość)

B      <-A(śledzenie B)
|
V


B powinien znaleźć się dokładnie na dolnym rogu kwadratu, a A - na przekątnej.
Tymczasem metodą przybliżeń A zatacza łuk, a punkt położenia A nie odpowiada teoretycznej prędkości z rachunku wektorowego.

Bo za bliska ta twoja przyszłość. Podejrzewam, że liczysz pozycję śledzonego obiektu w następnej klatce, a to prawie to samo co nie wychodzić w przyszłość w ogóle. W ustawieniu które podałeś, dążenie obiektu śledzącego w linii prostej do obecnej pozycji obiektu śledzonego sprawi, że obiekt śledzący będzie się poruszać po łuku. Pozycja którą tak naprawdę chcesz śledzić, to punkt spotkania ze śledzonym obiektem.

Zgadza się - masz pełną rację.

Problem pojawia się jednak wtedy, kiedy śledzony obiekt sam śledzi inny obiekt, albo jak pisałem wcześniej obiekty śledzą się nawzajem:
A -> B -> A
A -> B -> C -> A

Wyobraźmy sobie kwadrat o długości boków 300.
Na każdym wierzchołku jest obiekt, który śledzi kolejny wierzchołek A-> B -> C -> D.
Przy stałej prędkości 10 pikseli, punkt zderzenia będzie w środku, a najkrótsza droga - po przekątnej.

W takim przypadku nie jestem w stanie stworzyć zadowalającego modelu matematycznego, bo śledzony obiekt nie ma zdefiniowanego punktu końcowego (tak jak w przypadku poruszania się obiektu po łuku).

Być może rozwiązaniem jest:
1) wykorzystanie pętli i doprowadzenie do kolizji metodą śledzenia obiektów
2) określenie punktu kolizji i odległości od punktów startowych,
3) przemieszczać obiekty po znanej wtedy ścieżce (najkrótszą trasą) z prędkością 10 pikseli.

Czasochłonne i wyjątkowo mało eleganckie rozwiązanie.
Dodatkowo nie odpowiada na pytanie co w przypadku kiedy obiekty się rozminą (pętla aż da czasu kolizji).

Próbowałeś zaimplementować to, co napisałem?

Czytałeś co napisałem?
NIE DA SIĘ określić punktu spotkania, jeżeli śledzony obiekt (AI) śledzi inny obiekt.

A, B. A śledzi B, oba obiekty są w stanie spoczynku.
1. A wyznacza punkt spotkania z B (pozycja B, bo B się nie rusza)
2. B wyznacza punkt spotkania z A (pozycja A + (B - A) / 2, bo A idzie prosto na B).
Obiekty poprawnie spotykają się dokładnie w środku. To przy założeniu, że prędkość śledzenia jest stała.

NIE DA SIĘ określić punktu spotkania

Nie da się. Obiekt poruszający się jednostajnie w próżni po linii prostej to przypadek idealny. Normalnie obiekt może zmienić kierunek, prędkość, itp, choćby i w wyniku spotkania z innym obiektem. Nawet nie określiłeś, co się ma wtedy stać. Jeśli obiekty mogą na siebie oddziaływać, to dostajesz kosztowny obliczeniowo problem optymalizacyjny.