Architektura silnika gry MVC (Model-View-Controller) - tak czy nie? [Zamknięte]

Czytam jedną świetną książkę, Game Coding Complete , i ta książka zdecydowanie zaleca stosowanie podejścia MVC (Model-View-Controller) , z trzema kluczowymi warstwami:

1. Warstwa aplikacji gry
2. Logika gry
3. Widok gry

Dla mnie takie podejście wygląda jak przesada w mobilnej grze komputerowej.

Jakie jest twoje zdanie? Czy warto wdrożyć tę architekturę, nawet jeśli wymaga ona dodatkowej komunikacji między modułami? Czy ten projekt może zużywać tak dużo mocy procesora, że ​​na końcu wynik byłby znacznie wolniejszy, niż gdyby nie został zaimplementowany?

W pewien sposób popieram używanie struktury MVC nawet w prostej grze mobilnej. Co więcej, pomaga to w problemie, który dręczy programistów, którzy nie ugryzli go wystarczająco często: oddzielenie kodu wyświetlanego od logiki gry.

Powiem też jednak, aby pamiętać, że MVC, podobnie jak wszystkie wzorce projektowe, istnieje, aby ułatwić Ci życie . Oznacza to, że jeśli w danym momencie przestrzeganie pewnych zasad dotyczących tego, co powinieneś robić, a czego nie powinieneś robić podczas korzystania z MVC, utrudnia ci życie, zignoruj ​​to . Stanie się jedna z dwóch rzeczy: 1) później zostaniesz ugryziony, a potem zrozumiesz, dlaczego inaczej to zrobić w rzeczywistości ułatwiłoby ci życie na dłuższą metę, lub 2) żadnych konsekwencji.

Z natury programowanie komputerowe przyciąga wielu wyznawców reguł, którzy cenią przestrzeganie eleganckiej zasady nad faktycznym osiąganiem czegokolwiek i uwielbiają propagować swój system wartości; nie pozwól im uczynić cię jednym z nich. Najważniejszą rzeczą, jaka może się przydarzyć Twojej grze, jest jej wysyłka .

Projekty czasu kompilacji nie zużywają mocy procesora, chyba że masz niesamowicie fatalny kompilator. Język lub podejście obiektowe nie różni się cechami wydajnościowymi od proceduralnych. Nie będziesz wywoływać żadnych dodatkowych kosztów związanych z używaniem MVC. Modułowość istnieje w czasie kompilacji, a nie w czasie wykonywania, gdy kod zostanie wstawiony i zoptymalizowany, nie zrobi to żadnej różnicy.

Wiele współczesnych gier korzysta z modeli i widoków w osobnych wątkach i zyskuje ogromne korzyści na większości platform.

Ostatecznie MVC to dobry projekt, który zapewnia większą konserwację i mniej błędów itp. Za darmo . Nie ma powodu, aby go nie używać. To tak, jakby pytać, dlaczego warto użyćfor pętli zamiast ręcznie pisanych goto. Jeśli nie masz na myśli doskonałego projektu, na pewno jest lepszy niż nic.

Edycja: Projekty w czasie kompilacji nie zużywają mocy procesora. Oczywiście projekty wykonawcze, takie jak dziedziczenie.

Prawie zawsze występuje kompromis między przejrzystością kodu a wymaganiami technicznymi (szybkość, pamięć itp.) Programu. Języki zorientowane obiektowo mają narzut w porównaniu z językami proceduralnymi, ale wykazano, że mają wiele zalet w stosunku do języków proceduralnych, szczególnie w długoterminowej konserwacji kodu (błędów itp.), A często także w szybkości programowania.

Mając to na uwadze, proponuję, aby MVC warto wdrożyć ze względu na Ciebie jako programistę gier . Twój kod będzie lepiej przestrzegał zasad obiektowych, zwłaszcza enkapsulacji , i zapewne będziesz miał znacznie łatwiejszy czas na utrzymanie go (naprawianie błędów lub dodawanie nowych funkcji).

Z drugiej strony upewnij się, że faktycznie ukończyłeś grę i nie spędzałeś tyle czasu na pracy nad „silnikiem”, że nigdy się nie uda.

Aby uzyskać więcej informacji, przeczytaj pytanie „Dlaczego MVC i TDD nie są więcej wykorzystywane w architekturze gier?” i moja naprawdę długa odpowiedź.