Tworzenie ścian w grach opartych na kafelkach: czego mi brakuje?

Po dzisiejszym spędzeniu czasu na zanotowaniu notatek dotyczących implementacji ścian w mojej grze opartej na kafelkach, nagle zdałem sobie sprawę, że nie będzie to takie proste, jak sobie wyobrażałem. Chociaż obecny etap mojej pracy nie jest nawet bliski zrobienia kodu związanego ze ścianą, wymyśliłem trzy różne sposoby na zrobienie tego. W tej chwili nie jestem pewien, który z moich pomysłów zadziała najlepiej i czy coś mi umknęło, czy nie.

Ważne: postać MOŻE stać na kafelku, który ma ściany, niezależnie od ich formy.

Wspólna rzecz dla wszystkich trzech wariantów: mapa tilem będzie „trzymana” w pojemniku opartym na std :: vector (lub podobnym) w jednym wymiarze. Przyczyny tego są (niewiarygodnie) wyjaśnione w odpowiedziach na inne pytanie.

Klasy kontenerów w grach opartych na kafelkach.

Powrót do ścian.

A) Proste podejście.

Nic szczególnego tutaj. Każdy pojemnik z płytkami może pomieścić nie tylko postacie, ale jeden lub kilka obiektów ściany, które są przymocowane do krawędzi wewnątrz płytki.

Plusy: łatwe do wdrożenia, nie trzeba nic zmieniać w silniku. Minusy: Dwie rzeczy. Po pierwsze - może być tylko w mojej głowie, ale niektóre kombinacje wyglądają po prostu brzydko. Po drugie - takie podejście pozwala na wykonanie podwójnej ściany z dwóch sąsiadujących ze sobą płytek. Budowanie będzie ważną częścią gry, a podwójne ściany pozwolą budowniczym na rezygnację z ulepszania materiału ścian za pomocą środków gry i osiągnięcie większej wytrzymałości dzięki podwojeniu istniejącej ściany. To nie jest pożądane. Jasne, mógłbym dołączyć procedurę, która zabrania podwójnego murowania, ale będzie to miało zły nastrój.

B) Inteligentne (?) Podejście.

Zamiast pozwolić graczom podwoić ścianę całej mapy, zamierzam ich pokonać. Każda ściana ma dwie połówki, które są przymocowane do krawędzi płytki od wewnątrz. Tak więc, aby stworzyć pojedynczą „jednostkę ścienną”, będę musiał stworzyć dwa obiekty w połowie ściany w dwóch sąsiadujących płytkach.

Plusy: Jest symetryczny !!! Ponadto nie jest wymagana znacząca zmiana aktualnych specyfikacji silnika. Minusy: więcej kłopotów, więcej przedmiotów i oczywiście „czapki”. Jak widać na zdjęciu, narożnik będzie w zasadzie wołał o obiekt „czapki”. Naprawdę jestem z tym spoko, nie jest tak trudno dodać. Hej, mam już plan cienkich kolumn wykonanych z czterech połączonych ze sobą nasadek. Słodkie. Mimo to mam pewne obawy dotyczące możliwych problemów z polem widzenia i linią widzenia.

C) Całkowity wariant remontu.

Albo mógłbym po prostu tworzyć granice i narożniki jako osobne pojemniki na obiekty gry. Właśnie tak.

Plusy: nawet nie jestem pewien. Cóż, to proste. Zdecydowanie. Minusy: Będzie to wymagało remontu. Na szczęście nie kodu, ale obecnej mentalności mechaniki gry - to na pewno. Korzyści nie są tak oczywiste. Również to podejście wymaga znacznie więcej pojemników niż dwa poprzednie. Matematyka indeksowania również będzie trochę bolesna.

Mamy więc trzy różne sposoby tworzenia ścian między płytkami. Jeśli są jakieś alternatywy - chętnie je sprawdzę. Jeśli są jakieś zalety / wady któregoś z podejść, których nie widziałem - proszę o ich wskazanie.

Użyłbym twojej metody „B”.

Aby uniknąć konieczności stosowania „zaślepek”, po prostu przedłuż każdą ścianę o „1/2 grubości ścianki” w obu kierunkach. Spowoduje to utworzenie nakładających się ścian w miejscu, w którym się spotkają, ale twoje schematy już sugerują, że to nie jest problem.

Tak więc w metodzie „B”, rysunek nr 3, ściana pozioma rozciągałaby się nieco w lewo, a ściana pionowa rozciągałaby się nieco w górę.

[Jestem tu nowy, właśnie zarejestrowany. Czy coś mi brakuje, ponieważ nie widzę przycisku „Dodaj komentarz” do oryginalnego postu. Czy to przywilej osób o wyższej reputacji? Czy przeoczam to, co oczywiste? Przepraszamy za dodanie tego jako „odpowiedzi”.]

Zauważyłeś, że postać może stać na kafelku zawierającym ścianę, ale czy rozważałeś potraktowanie każdej płytki jako samej ściany? Nawet pół kafelka jako ściana w układzie poziomym lub pionowym?

Zalety: Obliczenia i rozmieszczenia są trywialne, kolizja jest trywialna, gdzie wszystkie obliczenia i kolizje są oparte na współrzędnych umieszczenia ścian.

Minusy: może to wpłynąć na całą implementację, kod i grafikę. Nie chcesz też całkowicie porzucić swojej metody, nadal chcesz specjalnych przypadków, w których tylko część kafelka jest ścianą (Link do przeszłości z klifami).

W ten sposób oparłem moją implementację, idąc naprzód, wiedząc, że zawsze mogę odwołać się do kafelka i wykonać na nim obliczenia w zależności od lokalizacji moich postaci i rodzaju kafelka.

Ścianę zamku mogłem po prostu wykonać obliczenia od środka, rysując pudełko, przez które nie mogłem przejść, a jeśli jest to okrągły kamień, mógłbym wykonać te same obliczenia od środka, ale jako koło, aby moja postać mogła się poruszać, jakby była bułczasty.

Przykro mi to mówić, ale trzeci sposób jest naprawdę sposobem myślenia, cóż, już masz taką możliwość, więc przejdźmy i pomyślmy o dwóch pozostałych!

Chodzi o to, że ściana ma zerową szerokość, dwa wymiary (wysokość * długość, w świecie 3D), podzielona na dwa pola. Powinieneś rozważyć je jako takie, ale możesz użyć prostszego rozwiązania, kiedy budujesz loch (szczególnie jeśli inni ludzie mogą budować części).

Wygląda na to, że jest to gra 2D z góry na dół, w której ściany mają „szerokość”, więc potrzebują tego rogu (obiektu „czapki”). Jest to jednak wyłącznie „grafika”, więc wybrałbym coś w rodzaju:

Mapa 2D z kafelkami (tj. Typ kafelka i tym podobne).

Mapa 2D z 2 ścianami, np. dolny i prawy (lewa ściana będzie „prawą ścianą” na kafelku po lewej stronie od tej).

+ logika, która rysuje wszystkie ściany i „czapki” itp.

W ten sposób rozdzielając logikę i grafikę. Możesz zrobić „interfejs” dbając o takie rzeczy jak SetWall (ThisTile, LEFT, NOWALL) -> ustawiając prawą ścianę kafelka po lewej stronie ThisTile na „NOWALL” ...

Może wydaje się to niewyraźne, ale chodzi o to, że zawsze powinieneś starać się mieć po jednej stronie logikę (rzeczywiste dane, bez redundancji), a po drugiej „rysowanie danych”, które oblicza, czy istnieje potrzeba ograniczenia „itd.

++