Jak stworzyć realistyczne wykrywanie kolizji w grach 2D?

Zawsze chciałem stworzyć staroświecką grę fabularną 2D, taką jak Star Ocean, Final Fantasy, Sword of Mana, a nawet serial „Tales of”, i myślę, że wielu ludzi tak robi. Ale zanim nawet napisałem jedną linię kodu, przeprowadziłem wiele badań, rysowałem i próbowałem.

Znalazłem prawie wszystkie odpowiedzi na moje pytania, ale jest problem, którego nie byłem w stanie rozwiązać: Jak stworzyć realistyczne, ale jednocześnie proste wykrywanie kolizji , tak jak w grach, które wymieniłem wcześniej?

Znam już kilka sposobów obliczania detekcji kolizji, spójrz na następujące przykłady:

Żadne z nich nie spełnia moich potrzeb.

• Kolizje oparte na kafelkach są zbyt proste i bardziej pasują do Zelda niż do Gwiezdnego Oceanu. Ponadto rysunek każdego kafelka musi wypełnić całą przestrzeń, aby wyglądać realistycznie.
• Pixel-perfect ma zbyt wiele ograniczeń. Jeśli twój kafelek ma jakiś piksel tu i tam, gracz najprawdopodobniej utknie w szczerym polu (np. W niektórych grach utkniesz na korzeniu drzewa o szerokości 2 pikseli).
• A maski binarne zużywają zbyt dużo pamięci i ustawień imo.

Przeczytałem dużo dokumentacji, ale nigdy nie znalazłem czegoś, co wyglądałoby dla mnie dobrze. I wszystkie moje próby nie wyglądały tak, jak kiedyś. Więc jeśli masz jakieś dobre linki lub samouczki na temat ewolucji 2D RPG, daj mi znać.

N Samouczki mogą tu pomóc. Trzeba przyznać, że są platformówką w stylu arkadowym, ale równie dobrze sprawdzą się w RPG z widokiem z góry; po prostu nie stosuj grawitacji. Założeniem jest testowanie kolizji w zbiorze podstawowych kształtów - kół, obwiedni wyrównanych do osi, linii, punktów itp.

Następnie w jakiś sposób albo udekorujesz swój świat nimi (być może za pomocą edytora niestandardowego poziomu), albo automatycznie wygenerujesz je (dopasujesz najbliższe pudełko lub okrąg) - albo jedno i drugie (domyślnie automatycznie generowane okno / okrąg i pozwala projektantowi na dostosowanie) .

Tam, gdzie pracuję, zrobiliśmy sporo platformówek i kilka odgórnych gier eksploracyjnych. Robimy je od dni GBA. Najczęściej używamy AABB do postaci i obiektów, dostrajanych w edytorze ikonek - i wariujemy tutaj, pozwalając na tonę pudełek na ikonkę, niektóre o różnych celach. Możemy mieć:

• jedno lub więcej pól kolizyjnych, opisujących kształt obiektu do wpadania na rzeczy;
• być może wiele „skrzynek ataku”, które powstają tylko wtedy, gdy jesteś w środku ataku (i animujesz duszka), w zależności od tego, może nawet dwa lub trzy na broń;
• kilka „wrażliwych skrzynek”, które otrzymają obrażenia po trafieniu przez skrzynie ataku innych osób - domyślnie używamy skrzynki kolizyjnej, ale wrażliwe skrzynki zwykle czują się lepiej, gdy są mniejsze od skrzynki kolizyjnej, i możemy pozwolić w ten sposób uszkadza lokalizację
• co najmniej jedno „pole aktywacji” na AI, które opisuje region sensowny dla AI - zaatakują, jeśli gracz znajduje się w tym regionie, na przykład.

Poziomy to głównie ciągi segmentów linii; mamy trochę metadanych na segment, aby opisać uszkodzone lub śliskie powierzchnie itp.

Tak więc większość wykrywania kolizji i reakcji staje się AABB-vs-AABB lub AABB-vs-segment. Czasami wrzucamy koło do czegoś dla pocisku, chociaż często AABB też tu zrobi.

Nie potrzebujesz wielu podstawowych kształtów, aby wyglądać dobrze i zachowywać się dobrze - kilka wystarczy, pod warunkiem, że możesz je modyfikować i iterować.

Nie przejmuj się też mieszaniem systemów; kolizja oparta na kafelkach może być doskonała w niektórych obszarach (reprezentujących większość twojego świata), ale okropna dla interakcji obiekt-obiekt. W porządku; użyj innego systemu dla obiektu przeciw obiektowi! Pisanie dla interakcji między dwoma systemami może być łatwiejsze niż myślisz.