MonoGame/Xna - podążanie za okręslonymi współrzędnymi.

0

Witam. Mój problem polega na tym, że mam swoją grę i jest w niej jakiś tam mob który ma gonić gracza. Mob dostaję na bieżąco współrzędne każdego kafelka ( wszystko jest na tile mapie ) do którego ma podążać. Droga jest wyszukiwana algorytmem A*, który na 100% ( sprawdzałem ) podaje dobrą drogę omijając kafelki kolizyjne. Problem w tym, że nie wiem jak zrobić by ten mob poruszał się w kierunku tych współrzędnych omijając bloki kolizyjne. Jeżeli ktoś czegoś nie rozumie to pisać, wszystko wyjaśnię.

Proszę o pomoc,
Pozdrawiam.

0

Zakładając, że sprawdzasz pozycję od moba do gracza, to przesuwasz się na pierwszy punkt ze ścieżki, jaką zwraca A*.

0
Patryk27 napisał(a):

Zakładając, że sprawdzasz pozycję od moba do gracza, to przesuwasz się na pierwszy punkt ze ścieżki, jaką zwraca A*.

No tak to wiem.. Ale właśnie nie wiem jak zrobić by się w dobry sposób przesuwał na ten punkt.

0

A jaki to jest "zły" oraz "dobry" sposób?
Chcesz mieć animację, jak mniemam, tak?

0

Animacje mam, po prostu nie wiem w jaki sposób przesuwać go na ten punkt. Mam jakiś przykładowy Vector2(160f, 192f) który jest kolejnym punktem drogi i w jaki sposób odpowiednio przesuwać moba ( czyli zmieniać jego pozycje ) by "szedł" w tym kierunku ?

0

Ktoś pomoże ?

1

Poruszanie się to część animacji :P
Anyway, stwórz w klasie gracza pole w stylu Point Target;, które będzie wyznaczało kierunek podążania (ten pierwszy punkt ze ścieżki), oraz float Speed; wyznaczające prędkość.
Zakładam, że gracz już ma jakąś metodę Update() wywoływaną co klatkę (czy jak tam to działa, dawno nie dłubałem w Mono) - wtedy pozostaje tylko zmiana pozycji gracza na podstawie delty czasu, kierunku oraz celu.
W sumie najtrudniejszą częścią tego zadania jest wyznaczenie kąta między graczem, a punktem docelowym, ale bardzo magiczna matematyka to nie jest.

0

Więc.. przeanalizowałem wszystko dokładnie i problem leży w tym, że w zły sposób przerzucam pozycje rzeczywiste ( tile mapa, każda kafelka 32x32 ) na pozycje które są potrzebne do wyszukiwania drogi ( na graf, lewy górny wierzchołek każdego kafelka to punkt na grafie do wyszukiwania drogi, np (192, 192) to pozycja (6, 6) w grafie ) i z mojego sposobu przerzucania wynika, że np. gdy mob jest na pozycji (191, 192) to zalicza go już jako (5, 6) [ 191 / 32 = 5,98.. ] w grafie gdzie tylko jego pozycja jest na tym kafelku, a cała jego textura wciąż znajduje się na (6, 6), więc A* wyszukuje wtedy drogę dla pozycji (5, 6) i każe mu jechać np. do góry, wtedy cała textura jedzie po bloku kolizyjnym ( czego właśnie nie chce ) bo pozycja na grafie jest (5, 6) a textura jedzie po (6, 6). Dlatego potrzebuję jakiegoś sposobu który dobrze będzie odzwierciedlał pozycje na grafie, jest to też zależne w którą stronę A* każe nam jechać.
Męczę się już z tym 3 dni, ciągle wymyślam jakieś nowe sposoby, ale wciąż nic nie działa tak jak powinno... Ale ja po prostu mogę być " za głupi " ^^ Więc proszę o pomoc..

0

Ktoś pomoże ? Bo chętnych nie widzę.. ^^

0

Na oko i z mojego - nikłego ale jednak - doświadczenia gejmdewelopera, powinno wystarczyć dzielenie z zaokrągleniem w dół. Wrzuć swój aktualny kod, w taki sposób będzie prościej.

0
Ellyon napisał(a):

i z mojego sposobu przerzucania wynika, że np. gdy mob jest na pozycji (191, 192) to zalicza go już jako (5, 6) [ 191 / 32 = 5,98.. ] w grafie gdzie tylko jego pozycja jest na tym kafelku, a cała jego textura wciąż znajduje się na (6, 6)

To chyba to jest zaokrąglanie w dół, nie ? Wiem to ze gdy np. mob porusza się w lewo to powinna być brana pozycja z prawej strony, gdy w prawo to z lewej, gdy w dół to z góry, gdy w górze to z dołu. Chodzi w tym o to ze tak to algorytm będzie "czekał" aż ta pozycja będzie na danym kafelku, i wciąż będzie pokazywało dobrą drogę, gdzie cała tekstura będzie właśnie jechała po tym kafelku aż osiągnie odpowiednie współrzędne. Tylko problem w tym, ze nie wiem jak to wykonać...

0

Wiem to ze gdy np. mob porusza się w lewo to powinna być brana pozycja z prawej strony, gdy w prawo to z lewej, gdy w dół to z góry, gdy w górze to z dołu

Em, może mam za mało wprawy, ale... w jakim celu to tak komplikować?

0
Patryk27 napisał(a):

Wiem to ze gdy np. mob porusza się w lewo to powinna być brana pozycja z prawej strony, gdy w prawo to z lewej, gdy w dół to z góry, gdy w górze to z dołu

Em, może mam za mało wprawy, ale... w jakim celu to tak komplikować?

Idąc za tą logiką że przenosząc pozycje na graf po prostu dzielimy dana pozycje przez 32 i zaokrąglamy w dół ( np. 191 / 32 = 5.98.. czyli na grafie 5), więc gdy np. będziemy poruszać się w lewo to wystarczy że tylko 1'ym pixelem wejdziemy w dana kafelkę ( podstawowa "pozycja" to lewy górny róg textury ) a już będziemy wychwytywani jakbyśmy tam byli i algorytm poda nam nową droge od tego kafelka gdzie jesteśmy tylko 1'ym pixelem, a cała textura leży na wcześniejszym kafelku i jest tam wyświetlana. Więc dlatego gdy poruszamy się w lewo bierzemy pozycje z prawej strony, ( wiec gdy wejdziemy ostatnim pixelem textury na dany kafelek, to dopiero wtedy nas zaliczy jakbyśmy tam byli i o to chodzi, bo jest tam cała textura ), gdy poruszamy się w prawo to pozycje z lewej itp.. Rozumiesz ?

0

Ach, imho przekombinowywujesz, bo cały czas (co krok) wyszukujesz nową ścieżkę względem aktualnej pozycji, a powinieneś wyszukać ją tylko raz i najwyżej odświeżać dopiero po dotarciu na wyznaczoną pozycję (target, czyli następną kafelkę).

0

Da to taki sam efekt, wystarczy, że wejdę 1'ym pixelem na target i już algorytm poda mi nową pozycje bo uzna, że tam jestem... A cała textura będzie na wcześniejszym.

0

No to sprawdzaj względem środka sprite'a.

0

I wtedy będzie to samo tylko, że po wjechaniu połową textury algorytm będzie nam podawał nową drogę.. i wciąż połowa textury będzie na poprzednim kafelku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1