Nakładanie się obiektów na siebie

[Sutikku]

Problem polega na tym, że jeśli mamy parę obiektów które poruszają się przez mp_potential_step o tej samej prędkości do tego samego punktu, to jest szansa, że jakby wejdą w siebie i będą idealnie odwzorowywać swoje ruchy. Jak ominąć ten efekt? Żeby np. obiekt po styknięciu się z drugim, poczekał aż tamten sobie pójdzie. Zakładamy, że to ten sam obiekt. Zrobiłem kolizję, ale wtedy oba obiekty stopują zabawę.

[Amaterasu]

Po mp_potential_step użyj place_meeting() aby sprawdzić, czy nie wlazł na jakiś inny obiekt, jeśli tak, to xprevious i yprevious

 

Robię to samo w tym właśnie momencie

[Threef]

Nawet jeżeli to gra akcji to musisz myśleć jakby to była gra turowa. Jeżeli np jeden przeciwnik wejdzie w korytarz to pozostali powinni wiedzieć o tym i szukać innej drogi, albo poczekać aż ten pierwszy przejdzie. Możesz to robić na wiele sposobów.

Najprostsze będzie tworzenie nowego mp_grid co step uznając każdy ruchomy obiekt za przeszkodę, ale to nie ma sensu. Innym rozwiązaniem będzie tworzenie nowego mp_grid pod jakimiś warunkami. Na przykład gdy obok będzie inny ruchomy obiekt który może się poruszyć i zablokować mi zaraz drogę.

 

Musisz przeanalizować co się u ciebie dzieje w grze i szukać odpowiednich rozwiązań. Może w momencie gdy dwaj przeciwnicy idą do tego samego celu w wąskim korytarzu musisz zapytać obu który powinien iść przodem? Wyliczyć na podstawie odległości, szybkosci, ilości HP, siły ataku i innych warunków który powinien mieć pierwszeństwo. Wtedy ten drugi wystarczy że się zatrzyma na moment a potem ponownie wygeneruje sobie drogę.

 

Edit: Pisząc zapomniałem że pytasz o mp_potential_step a nie mp_grid. :D

[3r3se7ven]

Problem polega na tym, że jeśli mamy parę obiektów które poruszają się przez mp_potential_step o tej samej prędkości do tego samego punktu, to jest szansa, że jakby wejdą w siebie i będą idealnie odwzorowywać swoje ruchy. Jak ominąć ten efekt? Żeby np. obiekt po styknięciu się z drugim, poczekał aż tamten sobie pójdzie. Zakładamy, że to ten sam obiekt. Zrobiłem kolizję, ale wtedy oba obiekty stopują zabawę.

 

Przetestować wszystkie instancje pod kątem x czy nie jest powtórzone korzystając z for.

A jeśli jest to sprawdzić też y.

Pchnąć w losowym kierunku młodszą numerem instancję w kierunku losowym przeciwnym do starszej.

 

I nie musisz analizować dlaczego tak się stało, w grze to może być rezultat całej masy różnych zdarzeń z kreacją włącznie.

Taki glicz deleter.

[Sutikku]

Edit: Pisząc zapomniałem że pytasz o mp_potential_step a nie mp_grid. :D

W sumie mogę skorzystać z mp_grid, ale czy to nie będzie zbyt spowalniało gry? A dokładnie tworzenie jednego gridu co step w jednym obiekcie i udostępnianie go innym?

[Threef]

W sumie mogę skorzystać z mp_grid, ale czy to nie będzie zbyt spowalniało gry? A dokładnie tworzenie jednego gridu co step w jednym obiekcie i udostępnianie go innym?

Metoda jest taka: Pierw tworzysz mp_grid dla całej mapy zawierający tylko nie ruchome obiekty. Funkcje mp_grid podczas tworzenia zwracają ds_grid który możesz sobie zapisać. To jest jeden który nie będzie się nigdy zmieniał i musisz go wygenerować tylko raz. Potem jeżeli tworzysz ścieżkę dla jakiegoś przeciwnika to możesz stworzyć nową tymczasową mp_grid i dodać do niej już wcześniej wygenerowany. A mp_grid nie używa się co step tylko od czasu do czasu, bo on zwraca gotowy path.

 

Ale nie używaj w takim wypadku mp_grid bo nie ma on dla Ciebie żadnych korzyści. Ruchy są nie naturalne i wyrównane do siatki, a samo użycie go będzie sprawiało masę problemów. Drobnych ale jednak. Jedyny plus byłby taki jeżeli robiłbyś sporą sieczkę pokoi i chciałbyś aby przeciwnik który nie widzi swego celu doszedł do niego. Ale wtedy w momencie gdy cel jest widoczny trzeba wyłączyć poruszanie przez mp_grid i z powrotem przejść na mp_potential_step.

 

 

A wracając do mp_potential_step:

Ostatni punkt z poprzedniego mojego posta będzie działać.

Podczas poruszania sprawdzaj czy na pozycji x+hspeed i y+vspeed nie dojdzie do kolizji. Jeżeli tak to niech oba obiekty skomunikują się i rozwiążą spór.

Na początek dobrym sprawdzeniem będzie czy w ogóle któryś ma wolna drogę. Jeżeli jeden ma a drugi nie to drugi ma czekać. To bardzo prosty warunek. Jeżeli obaj mają zablokowaną przez siebie drogę to maja sprawdzić czy jeżeli się wycofają o krok to odblokują drogę drugiemu. Jeżeli oba mogą to zrobić to trzeba jakoś wybrać który ma to zrobić. Na przykład ten szybszy, albo ten bliżej, albo ten z więcej HP.

Jeżeli jednak żaden z nich po zrobieniu kroku wstecz nie odblokuje drogi to musisz szukać innych akcji. Np 2 kroki wstecz.

[3r3se7ven]

Atakujecie problem od jednej strony.

Co jeśli kolejne takie rezultaty nie będą wynikały z ruchu po siatce, a z innych przyczyn mechaniki gry w tym z próby naprawy ruchu po siatce?

Kolejna łata?

[Threef]

Ciężko jest mnie wywrócić z równowagi ale tobie się udało. Gratuluję.

 

Twoje dwa posty z tego jednego tematu wydaja się zaprzeczać same sobie. Poza tym kolejny raz nie zrozumiałeś problemu i starałeś się, wykorzystując swoją dużą wiedzę którą szanuję, podsunąć rozwiązanie które w zupełny sposób nie pasuje do problemu. I nie przypominam sobie żeby którykolwiek z twoich ostatnich postów na forum w ogóle w jakiś sposób ukierunkowywał w stronę rozwiązania. Za każdym razem odbiegasz od tematu jakby twoim jedynym celem było pochwalenie się wiedzą. Niestety ale kolejne takie posty będą już karane.

 

Atakujecie problem od jednej strony.

Co jeśli kolejne takie rezultaty nie będą wynikały z ruchu po siatce, a z innych przyczyn mechaniki gry w tym z próby naprawy ruchu po siatce?

Kolejna łata?

Przetestować wszystkie instancje pod kątem x czy nie jest powtórzone korzystając z for.

A jeśli jest to sprawdzić też y.

Pchnąć w losowym kierunku młodszą numerem instancję w kierunku losowym przeciwnym do starszej.

 

I nie musisz analizować dlaczego tak się stało, w grze to może być rezultat całej masy różnych zdarzeń z kreacją włącznie.

Taki glicz deleter.

[3r3se7ven]

Ciężko jest mnie wywrócić z równowagi ale tobie się udało. Gratuluję.

 

Twoje dwa posty z tego jednego tematu wydaja się zaprzeczać same sobie. Poza tym kolejny raz nie zrozumiałeś problemu i starałeś się, wykorzystując swoją dużą wiedzę którą szanuję, podsunąć rozwiązanie które w zupełny sposób nie pasuje do problemu. I nie przypominam sobie żeby którykolwiek z twoich ostatnich postów na forum w ogóle w jakiś sposób ukierunkowywał w stronę rozwiązania. Za każdym razem odbiegasz od tematu jakby twoim jedynym celem było pochwalenie się wiedzą. Niestety ale kolejne takie posty będą już karane.

 

Threef jeszcze raz Ci objaśniam... niekoniecznie rozumiesz co czytasz.

Skoro piszę coś o rozwiązaniu problemu to najwidoczniej miałem taki sam i rozwiązałem.

W sposób który wg Ciebie sobie przeczy.

Bo najwidoczniej później z redukcji do last step wyrasta kolejny problem, i kolejny i kolejny i jakoś trzeba to w końcu rozwiązać globalnie.

 

Gdzieś tu jest zamieszczony przykład mojej starej zrobionej na obiektach i przez to przycinającej gierki o rootach na wielopoziomowej izometrii.

 

Otóż roboty zajmują pewną przestrzeń i ściany też.

Można skoczyć jednym an drugi, ale można też zamknąć przesuwane rota na robotach w polu zamknięcia.

 

Najwidoczniej nie utykają mi w ścianach. Choć czasem potrafią wystrzelić z drzwi jak z procy i odbić się od ściany :)

 

Roboty poruszają się po siatce równoważnej dla mp_grid tylko z wykorzystaniem rozszerzonego greed i skracania do słabego JPS.

 

 

Czyli jak czegoś nie rozumiesz - czytaj jeszcze raz.

Do skutku, a jak nie ma skutku - doprecyzuj czego nie rozumiesz.

 

Najczęstsza przyczyna zapytań u programistów "rozwiązanie problemu wygenerowało problem".

 

 

//==============

 

I nie krępuj się, jak czytam co sądzi o shaderach dentysta z Bergen to otwieram podręcznik do grubszej matmy i staram się dowiedzieć czy ja w ogóle zrozumiem jak to przekopię.