Нужны ли GDD при разработке игр?

«Мне кажется, многие гейм-дизайнеры реально отстойно делают свою работу»

Ричард Гэрриот, Лорд Бритиш, Создатель Ultima
3535
33
11

Все! БУКВАОЛЬНО ВСЕ! В итоге финальный диздок должен содержать в себе ВСЮ информацию, что бы клон вашей игры могли соорудить по нему и без вас!

Я надеюсь это сознательное преувеличение. Потому что, конечно, во всем нужен взвешенный подход и аджайл с его "работающий продукт важнее документации" тоже не просто так придумали. Документация нужна и как способ структуировать собственные мысли, понять что именно будем разрабатывать, и как способ коммуникации между участниками команды, потому что все может быть понятно неправильно будет понято неправильно. Кажется, что в случае соло-разработчика вторая часть не актуальна (зато очень актуальна первая), но это тоже не совсем так: разработка длится месяцы, если не годы, и за это время у тебя из будущего появляются вопросы к тебе из прошлого: что ты собственно имел ввиду? И тут хорошо если от прошлой версии тебя пришла какая-то корреспонденция.

Но если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить.

По крайне мере в идеале - GDD - это чертеж проекта. Будь игра домом - описанные логику, системы и фичи игры можно сравнить с ... электро и водопроводной сетью. Наличие чертежа - сильно упростит починку труб - если туалет прорвет.

Как и в случае со строительством проектная документация — это не один чертеж, а стопка разных чертежей, таблиц, текстов и т.д. GDD — только часть это документации, в ней не нужно пытаться определять вообще все вплоть до архитектуры серверов для мультиплеера, времени ответа поддержки коммьюнити менедежера на обращение игрока, графика отпусков команды и расходов на рекламу у блогеров.

Один из самых интересных советов, что я встречал по ведению GDD документации - это создание мысленного прохождения своей игры с последующей записью оного. Простая идея? Так почему мало кто ее воплощает в реальность?

Этот прием часто используют при разработке визуальных новелл и линейных кинематографических игр, насколько я знаю, — собственно в кино раскадровки стандартный инструмент. Но в случае игр с открытым миром, с процедурной генерацией сюжетов песочниц — не очень понятно насколько такие эссе или комиксы полезны. Тут скорее можно было бы сказать о важности прототипа. Вернее о важности наиболее простого и эффективного прототипа. Для каких сюжетных игр это может быть действительно просто рассказ или текстовый квест собранный на twine, например. Я лично ink использую для этих же целей.

6
Ответить

Прототип очень важен, но описание механик прототипа не менее важно, так как при "масштабировнии" оного можно забыть о механиках, как к примеру в страифлде забыли о невесомости и роботе компаньене.

1
Ответить

Про раскадровки. Я вставил пример из марио. Там довольно наглядно показаны механики в виде картинок.
Возможно ты этот пример пропустил, так как он вставлен раньше.

На ракадровках очень удобно показывать "механики игры" это будет более наглядно чем читать схемы.

1
Ответить

потому что все может быть понятно неправильно будет понято неправильно.А что бы этого не было - документация и нужна, что бы сразу можео было выяснить кто прав а кто занялся самодеятельностью. Без нее это сделать будет в разы труднее и проще свалится в "вечную разработку" как у Криса Робертса.

1
Ответить

если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить

А потом не поленится записать что именно ты сделал и зачем. Это как ловушка джокера,зачем мне комментировать код, если я и так все знаю, а через пол года: кто это писал и как легаси код поддерживать?!

1
Ответить