Jak radzić sobie z graficzną reprezentacją obiektów w grze 2D MVC?

Question

Tworzę grę 2D w Javie, używając wzorca MVC i po przeczytaniu i przeszukaniu mojej dupci wciąż nie znalazłem satysfakcjonującej odpowiedzi na pytanie, jak mam obsłużyć graficzne przedstawienie obiektów.

powinienem podzielić każdy przedmiot, na przykład odtwarzacza do PlayerModel (przechowywanej w modelu) i PlayerView (przechowywanej w widoku)?

To wydaje się trochę brudny ponieważ posiadał wtedy muszę śledzić których grapical reprezentacja-Object, czyli „ScaryMonsterEnemyView”, do którego podłączony jest logiczno-reprezentacja-obiekt „ScaryMonsterEnemyModel”. Czy tak naprawdę powinienem to zrobić zgodnie z MVC? Jeśli tak, to gdzie powinno być przechowywane to połączenie? W widoku?

Wiem, że to może być niemądry problem, ale chcę od samego początku jak najwięcej. Dzięki za pomoc :)

Answer 1

Jeśli się nie mylę, to zasadniczo pytasz, jak podzielić grę na paradygmat Model-Widok-Kontroler.

Po prostu model jest stanem twojej gry. W terminach O-O możesz myśleć o Modelu jako o wszystkich obiektach w grze.

Kontroler to zbiór reguł, które są stosowane do stanu gry (w tym przypadku wszystkich obiektów gry) w każdym cyklu aktualizacji. Może to zostać zaimplementowane jako metoda o nazwie update() we wszystkich twoich obiektach lub może to być funkcja wywoływana w pętli gry, która systematycznie przechodzi przez wszystkie obiekty, które wymagają aktualizacji i, no cóż, aktualizuje je. Możesz również myśleć o kontrolerze jako o pętli gry. Wywołuje wszystko, aby zaktualizować, a następnie rysuje je na ekranie i powtarza, chyba że spełnione są pewne warunki, a następnie nakazuje programowi zrobienie czegoś innego. W ten sposób prawie masz dwie zagnieżdżone struktury MVC. Jeden kontrolujący przepływ programu poprzez menu i takie, i jeden poświęcony samej grze.

Widok to tylko graficzne przedstawienie Twojej gry. Może to być tak proste jak tekst na ekranie, ale w twoim przypadku jest to grafika 2D. Aby to zaimplementować, każdy obiekt może również zawierać jego stan graficzny, bezpośrednio lub poprzez enkapsulację. Widok zrobi niewiele więcej, niż tylko sprawdzi wszystkie obiekty ze względu na ich stan graficzny, a następnie obejmie go na ekranie. Znowu można to zaimplementować na podstawie obiektu, na przykład metody zwanej draw(), lub innej systemowej funkcji, która będzie wywoływana bezpośrednio z pętli gry. Powszechną praktyką jest tworzenie obiektu o nazwie "Sptite" lub coś podobnego do przechowywania informacji graficznej, a każdy obiekt gry, który jest rysowany, ma osobistą instancję. Zwróć też uwagę, że Widok nie musi być obiektem samym w sobie. Wystarczy funkcja wywoływana w pętli gry, chociaż czasami konieczne jest przechowywanie informacji bezpośrednio wpływających na działanie widoku (takich jak rozmiar okna), w którym to przypadku widok może być obiektem. To samo dotyczy kontrolera.

Należy także pamiętać, że te podziały przekroju można się jeszcze dalej, aby uczynić życie prostszym. Na przykład: Kontroler można podzielić na przetwarzanie AI, aktualizację ruchów i sprawdzenie kolizji. Widok może być podzielony na ekran obiektu gry, a HUD i Model mogą być wszystkimi obiektami + całym stanem niezależnymi od obiektów gry (takimi jak ustawienia gry dotyczące rozdzielczości, rozmiaru okna, konfiguracji klawiszy itp.).

Wiem, że to może być trochę przesada i prawdopodobnie zawiera dodatkowe informacje, ale mam nadzieję, że odpowiada na twoje pytanie i daje pomysły na temat tego, od czego zacząć.

Answer 2

Model i widok to dwie kolekcje/kategorie/domeny obiektów.

Sterownik udostępnia zestaw interfejsów do wykonywania niektórych funkcji na obiektach modelu. I w razie potrzeby widok może bezpośrednio rozmawiać z obiektami modelu w odniesieniu do ich informacji o stanie.

Tradycyjnie, domena Widok odpowiada GUI, z pojęciami takimi jak Przyciski, Formularze, Windows itp. W środowisku graficznym.

Twoja domena widoku (lub jedna z nich) będzie odpowiadać środowisku 3D, które zbudujesz. (Drzewa, domy, osoby itp.). Dotyczy to szczegółów kolizji i Twojej fizyki. Oba wymagają geometrii związanej ze środowiskiem 3D.

W przypadku jednej z tych obiektów współpraca z obiektem w innej domenie może być bardzo rzadka. Ale przykład, rozważ telefon. Obiekt będzie istnieć w środowisku 3D, ale będzie także współpracował z inną domeną, która opisuje "połówki połączeń", "kanały", "przełączniki" itd. Obiekty te nie należą do Twojej domeny View, lecz do oddzielnej domeny Model.

Bardziej odpowiednim przykładem może być system oceny punktowej, taki jak statystyki RPG, który należałby do domeny Modelu.