Przedmówię to, mówiąc, że nie szukałem dużej ilości źródeł gier ani nie budowałem zbyt wiele na sposób gier.
Ale przychodząc od próby zastosowania praktyk kodowania „korporacyjnego” w aplikacjach internetowych, poważne spojrzenie na kod źródłowy gry boli mnie: „Co to za logika widoku robi z logiką biznesową? To wymaga refaktoryzacji ... więc to, refaktor, refactorrr „
Martwi mnie to, gdy zaczynam projekt gry i nie jestem pewien, czy próba mvc / tdd procesu tworzenia będzie nam przeszkadzać czy nam pomagać, ponieważ nie widzę wielu przykładów gier, które używają tego lub duży nacisk na lepsze praktyki architektoniczne w społeczności.
Poniżej znajduje się fragment świetnego artykułu na temat prototypowania gier , chociaż wydawało mi się, że postawa, którą wielu twórców gier wydaje się stosować podczas pisania kodu produkcji:
Błąd nr 4: Budowanie systemu, a nie gry
... jeśli kiedykolwiek zdarzy ci się pracować nad czymś, co nie prowadzi bezpośrednio do przodu, zatrzymaj się właśnie tam. Jako programiści staramy się uogólniać nasz kod, nadawać mu elegancji i być w stanie poradzić sobie w każdej sytuacji. Stwierdzamy, że swędzenie jest wyjątkowo trudne, a nie zadrapanie, ale musimy się nauczyć. Wiele lat zajęło mi uświadomienie sobie, że nie chodzi o kod, ale o grę, którą ostatecznie dostarczasz.
Nie pisz eleganckiego systemu elementów gry, całkowicie pomiń edytor i podłącz kod w stan, unikaj opartego na danych, parsowania, szaleństwa XML i po prostu koduj to cholerstwo.
... Po prostu wyświetlaj rzeczy na ekranie tak szybko, jak to możliwe.
I nigdy, nigdy, nigdy nie używaj argumentu „jeśli poświęcimy trochę więcej czasu i zrobimy to we właściwy sposób, możemy ponownie wykorzystać go w grze”. ZAWSZE.
to dlatego, że gry są (głównie) zorientowane wizualnie, więc sensowne jest, aby kod był mocno ważony w widoku, więc wszelkie korzyści z przeniesienia rzeczy do modeli / kontrolerów są dość minimalne, więc po co się tym przejmować?
Słyszałem argument, że MVC wprowadza narzut wydajności, ale wydaje mi się, że jest to przedwczesna optymalizacja, i że należy zająć się ważniejszymi problemami z wydajnością, zanim będziesz się martwić o narzuty MVC (np. Renderowanie potoku, algorytmy AI, struktura danych przechodzenie itp.).
To samo dotyczy TDD. Nie często widzę gry wykorzystujące przypadki testowe, ale być może wynika to z powyższych problemów projektowych (widok mieszany / biznesowy) oraz z faktu, że trudno jest testować komponenty wizualne lub komponenty, które opierają się na wynikach probablistycznych (np. Działają w ramach symulacji fizycznych ).
Być może po prostu patrzę na zły kod źródłowy, ale dlaczego nie widzimy więcej takich „korporacyjnych” praktyk stosowanych w projektowaniu gier? Czy gry naprawdę różnią się tak bardzo pod względem wymagań, czy też jest to kwestia ludzi / kultury (tj. Twórcy gier pochodzą z innego pochodzenia, a tym samym mają inne nawyki kodowania)?