Sprawdzanie kolizji na drodze w linii prostej

[MaxGaming]

Chce sprawdzić czy przeciwnik w linii prostej może dojść do obiektu, czy występuje jakiś obiekt solid po drodze do celu. Tyle, ze przeciwnicy też mają oznaczenie solid. Więc jak mam to zrobić? Mam taki warunek:

GML

!collision_line(x, y, _nearestPlayer.x, _nearestPlayer.y, oWarrior, false, true)

ale nie działa, ponieważ przeciwnik też jest solid i wykrywa jego. Muszę odejmować rozmiar maski od pozycji, czy jest na to jakiś prostszy/poprawniejszy sposób?

[Threef]

Piaty argument to ID obiektu albo instancji z którą chcesz sprawdzać kolizję. collision_line() nie sprawdza kolizji z solidami a każdym obiektem o jaki pytasz. W czym jest problem?

[MaxGaming]

Chce, aby obiekt nie "wchodził" na inne obiekty oWarrior po drodze do "właściwego" oWarrior. Da się jakoś zrobić, aby sprawdzał kolizje ze wszystkimi instancjami obiektu oWarrior z wykluczeniem jednej instacji? Coś w pseudokodzie:

!collision_line(x, y, _nearestPlayer.x, _nearestPlayer.y, oWarrior-_nearestPlayer, false, true)

(_nearestPlayer to oWarrior który jest celem)? Da się, aby siebie nie wykrywał o ile rozumiem ostatni argument, ale ja chce żeby nie wykrywał siebie i tego celu. Jedyne co mi przychodzi do głowy to "obrysowywać maskę" za pomocą lengthdir_x/ lengthdir_y, gdzie jako długości użyłbym połowy wielkości maski+1, ale czy nie ma na to lepszego sposobu?

 

@e. Póki co zrobiłem jak mówiłem

GML

!collision_line(x, y, _nearestPlayer.x-lengthdir_x(sprite_width+1, _directionToPlayer), _nearestPlayer.y-lengthdir_y(sprite_height+1, _directionToPlayer)

przyczym

GML

_directionToPlayer=point_direction(x, y, _nearestPlayer.x, _nearestPlayer.y);

[Threef]

Acha. Chyba rozumiem. Jeden obiekt chce sprawdzić czy pomiędzy nim a innym obiektem oWarrior są inne obiekty oWarrior? Ok, więc problem jest taki że koniec lini jest w punkcie x/y obiektu oWarrior. Twój pomysł ze skróceniem linii jest dobry, ale wydaje mi się że można to obejść małym trikiem. Nie testowałem tego ale w teorii powinno być ok.

GML

var xx=_nearestPlayer.x, yy=_nearestPlayer.y;

_nearestPlayer.x-=10000

_nearestPlayer.y-=10000

//test !collision_line(xx, y, xx, yy, oWarrior, false, true)

_nearestPlayer.x+=10000

_nearestPlayer.y+=10000

Zmiana pozycji odbywa się raz po raz w jednym step więc nie powinno być tego widać. ;)

[MaxGaming]

No w sumie bardzo ciekawa koncepcja, chyba będzie Twoim sposobem optymalniej?

[3r3se7ven]

...Jedyne co mi przychodzi do głowy to "obrysowywać maskę" za pomocą lengthdir_x/ lengthdir_y, gdzie jako długości użyłbym połowy wielkości maski+1, ale czy nie ma na to lepszego sposobu?

...

 

Point distance

Bardzo słuszna koncepcja

Tak to się właśnie najszybciej robi.

 

Lista pozycji oWarior zawiera pewne punkty w przestrzeni i raczej nie będzie to długa lista.

Jeśli point distance (nawet 3d jak masz taką potrzebę) do próbkowania linii jest mniejszy niż - masz rezultat.

[MaxGaming]

@3r3se7ven w sumie fakt. Po jakiego grzyba ja użyłem tam lengthdir_y skoro mogłem użyć point_distance, albo distance_to_object. Tylko która z tych 3 opcji jest bardziej optymalna?

I kolejna kwestia, że TAK TO SIĘ ROBI, ale znowu 3F wymyślił fajny sposób obejścia i chyba ten sposób tak myślę, że będzie szybszy od kombinowania z odległościami, albo lengthdir-ami?

 

[3r3se7ven]

@3r3se7ven w sumie fakt. Po jakiego grzyba ja użyłem tam lengthdir_y skoro mogłem użyć point_distance, albo distance_to_object. Tylko która z tych 3 opcji jest bardziej optymalna?

I kolejna kwestia, że TAK TO SIĘ ROBI, ale znowu 3F wymyślił fajny sposób obejścia i chyba ten sposób tak myślę, że będzie szybszy od kombinowania z odległościami, albo lengthdir-ami?

 

Bo każdy zaczyna od abs(x-xpos) <distance id to samo y, potem sine, potem lengthdir, potem point distance, potem... przynależność do struktury.

 

Threef ma skuteczny sposób, ważne aby problem był rozwiązany a potem się to zoptymalizuje. Point distance jest najszybszy bo ma oszukaną matematykę, jak większość obliczeń na tabelach.

Co do optymalizacji to zacząłbym od nieużywania obiektów. Więc czy to zrobisz tak czy siak to jest tylko kwestia liczby zapytań, bo i tak odwołasz się potem dość ciężkim ty_tam.zmienna

 

 

Jak rozwiązania Threefa zacznisz używać do mapowania przestrzeni i szukania drogi z użyciem greed i A* to dopiero wtedy liczba kroków robi kaszan, że można iść na kawę zanim ai się zdecyduje na jakiś plan. O ile w ogóle podejmie jakąś decyzję, a nie będzie się bawiła w przerysowywanie kropek donikąd na mapie :)