Podział podobny do MVC w grach? [Zamknięte]

Zastanawiałem się nad zaprojektowaniem gry (w szczególności przetłumaczeniem gry planszowej na komputer, co, jak sądzę, jest w tym przypadku istotne) i przyszło mi do głowy, że sensowne może być zbudowanie „gry” oddzielnie od „wyświetlacza”.

Pozwoliłoby mi to szybko prototypować coś za pomocą prostego interfejsu tekstowego, a następnie zrobić to później. Pozwoliłbym też łatwiej przenieść grę na inne media.

Czy tego rodzaju podział na przedziały jest powszechny w grach? Czy powinienem starać się dalej rozkładać? Czy są jakieś komplikacje, które mogą mi brakować?

Gra planszowa jest dobrym przykładem gry, którą można wykonać za pomocą MVC, ponieważ logika gry (model) istnieje całkiem niezależnie od wyglądu (widok). Jeśli jednak weźmiesz pod uwagę grę akcji, taką jak Gears of War, geometria modeli 3D jest nieodłączna od logiki gry, więc oddzielenie widoku tak, jakby były one wymienne, staje się bezcelowe. Unity3D jest doskonałym przykładem bardziej specyficznego dla gry sposobu organizowania kodu. Masz podstawową klasę encji, do której dodajesz funkcjonalność z komponentami, w której jeden komponent może obsługiwać rysowanie encji, jeden logikę gry itp. Sprawdź te słynne posty na blogu na ten temat:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

Moje zdanie na ten temat:

• Modelu jest, gdy większość danych leży logika i wszystko odbywa.
  Odczytuje kolejkę zdarzeń wejściowych i odpowiednio modyfikuje stan gry.
  Następnie przetwarza rzeczy takie jak fizyka i inne podstawowe elementy, które również aktualizują stan gry.
  Pętla. To wszystko.
  Celem jest uniezależnienie modelu: nie ma on żadnej zależności od widoku lub kontrolera: powinieneś być w stanie stworzyć program, który uruchamia tylko model.
• Widok po prostu odczytuje stan gry modelki, aktualizuje swoje własne komponenty dedykowane do reprezentacji danych i wyświetlać rzeczy na ekranie.
  Nigdy nie zapisuje niczego w modelu, jest to proces tylko do odczytu, z wyjątkiem może rejestracji jakiegoś modułu obsługi zdarzeń (np. „Hej Mister Model, kiedy wykryjesz kolizję między tymi dwoma obiektami, zadzwoń do mojego modułu obsługi zdarzeń, który odtwarza dźwięk! „).
• Regulator łapie zdarzeń wejściowych i przekazuje je do kolejki wejściowej modelu. Odczytuje widok (czy kliknięcie tego przycisku miało miejsce na przycisku interfejsu użytkownika?).

W ten sposób możesz podłączyć fałszywy kontroler, który odczytuje plik zawierający wcześniej zarejestrowane zdarzenia wejściowe.
Zrób również prosty widok, który rejestruje rzeczy w pliku.
Bardzo przydatne do testowania i debugowania.

Pamiętaj, aby aktualizować model ze stałą szybkością (stały krok czasowy), a widok i kontroler tak szybko, jak to możliwe (ale nie za bardzo zmienne).

Ten rodzaj podziału na przedziały to podział na silnik i kod gry i jest dość powszechny. Po drodze jest dużo miejsca na abstrakcję.

Twój silnik i dane graficzne specyficzne dla gier mogą wyglądać jak widok, kod gry model, a kontroler byłby jakimkolwiek klejem, którego użyjesz, aby powiedzieć silnikowi, jaką teksturę zastosować do której encji w kodzie gry.