Jak szczegółowe i / lub kompletne są / są twoje dokumenty dotyczące projektowania gry przed rozpoczęciem projektu?

Zastanawiam się, jak kompletne są zazwyczaj dokumenty projektowe przed rozpoczęciem realizacji projektu? Mówię o średnich do bardzo małych projektach z bardzo małym zespołem tutaj, gdzie nawet w pełni rozwinięty cały dokument może mieć tylko kilkadziesiąt stron.

Czy zaczynasz od zgrubnego frameworka i zaczynasz dopracowywać szczegóły w tym samym czasie, gdy zaczyna się wdrażanie?

Czy całkowicie uzupełniasz każdą sekcję przed rozpoczęciem jakiegokolwiek wdrożenia? Jeśli tak, to jaką zmianę procentową widziałeś po rozpoczęciu wdrażania?

Jeśli masz doświadczenie w jednym z dwóch opisanych przeze mnie scenariuszy, chciałbym usłyszeć Twoją opinię na temat problemów związanych z tą konkretną trasą i przeszkód, które według ciebie pomogły Ci uniknąć.

Jeśli pomysł gry jest mocno oparta na jakiejś niezwykłej koncepcji rozgrywki , to prototyp, który od razu od podstaw, przy użyciu poprzedniego projektu jako szablonu. 95% czasu prowadzi to do uświadomienia sobie, że to nie jest tak zabawne, jak sobie wyobrażałem, a sprawienie, by było przyjemne, wymagałoby więcej zasobów niż jest warte.

Jeśli tymczasem pracuję nad innym projektem, nie spieszę się, zrób doodle, aby dowiedzieć się, jak powinien wyglądać prototyp (staraj się nie rozpraszać szkicem). Następnie dzielę się nim z przyjaciółmi, częściowo po to, aby sprawdzić, czy mają jakiś wkład, ale głównie po to, aby od razu pomyśleć o rzeczach, które nie są oczywiste (zawsze jest ich mnóstwo, nawet dla najmądrzejszych ludzi wymyślających najprostsze pomysły). Po kilku godzinach, opiszę kilka kluczowych pojęć, które muszą być w architekturze, dosłownie ~ 20 słów. Potem mogę zbudować prototyp, kiedy będę miał czas.

Obecnie moje projekty gier zostały odpowiednio dopracowane przed rozpoczęciem.

Opiszę większość ważnych klas, narysuję makiety (rysunki są zwykle okropne), opiszę grę.

Jest to spowodowane głównie długim dojazdem do pracy i niczym innym. Wolę spędzać mniej czasu na robieniu tego, a więcej na programowaniu, ponieważ opracowanie klas, które najprawdopodobniej się zmienią, wydaje się przesadą.

Pracując w małych zespołach w małych grach (jednoosobowe drużyny w małych zwykłych grach) przeszedłem z „ciężkiego projektu” na „szybki projekt”. Uważam, że iteracyjny rozwój (dwa tygodnie skupione na jednym celu, np. Podstawowa rozgrywka) pomaga dopracować projekt i daje ci coś do grania, co oznacza, że ​​nie zmienisz zdania i nie unieważnisz 90% tego, co zaprojektowałeś, które wyglądał dobrze „na papierze”, ale nie w grze.

Powiedziawszy to, spędzam większość czasu na projektowaniu na podstawowej rozgrywce i mechanice (jak będzie działała gra główna), a to rzadko zmienia się wiele - dostaje ulepszeń, a czasem zbieram nowe pomysły lub odrzucam stare pomysły; ale nic nie obejdzie się bez działającego prototypu.

Od strony technicznej wszystko powinno się zastanowić przez kilka minut, zanim kod stanie się prawdziwy. Ale zawsze możesz później refaktoryzować.

Dokumentacja projektowa ma koszt utrzymania; gdy rzeczy się zmieniają, musisz wrócić i ponownie przeczytać i zaktualizować wszystkie istniejące dokumenty. W związku z tym celem produkcyjnym powinno być zminimalizowanie ilości dokumentacji, którą można utrzymać, ponieważ pozwoli to zmaksymalizować czas spędzony na tworzeniu gry.

Stąd wynika, że ​​nie chcesz projektować wszystkiego z najdrobniejszymi szczegółami, ponieważ dobrze wiesz, że połowa się zmieni, a wtedy będziesz musiał zmarnować dużo czasu. Wykonaj minimalny projekt wymagany do rozpoczęcia tworzenia podstawowej gry. Gdy to zrobisz, iteruj w razie potrzeby, a następnie powtórz proces dla każdej nowej funkcji.