Все! БУКВАОЛЬНО ВСЕ! В итоге финальный диздок должен содержать в себе ВСЮ информацию, что бы клон вашей игры могли соорудить по нему и без вас!
Я надеюсь это сознательное преувеличение. Потому что, конечно, во всем нужен взвешенный подход и аджайл с его "работающий продукт важнее документации" тоже не просто так придумали. Документация нужна и как способ структуировать собственные мысли, понять что именно будем разрабатывать, и как способ коммуникации между участниками команды, потому что все может быть понятно неправильно будет понято неправильно. Кажется, что в случае соло-разработчика вторая часть не актуальна (зато очень актуальна первая), но это тоже не совсем так: разработка длится месяцы, если не годы, и за это время у тебя из будущего появляются вопросы к тебе из прошлого: что ты собственно имел ввиду? И тут хорошо если от прошлой версии тебя пришла какая-то корреспонденция.
Но если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить.
По крайне мере в идеале - GDD - это чертеж проекта. Будь игра домом - описанные логику, системы и фичи игры можно сравнить с ... электро и водопроводной сетью. Наличие чертежа - сильно упростит починку труб - если туалет прорвет.
Как и в случае со строительством проектная документация — это не один чертеж, а стопка разных чертежей, таблиц, текстов и т.д. GDD — только часть это документации, в ней не нужно пытаться определять вообще все вплоть до архитектуры серверов для мультиплеера, времени ответа поддержки коммьюнити менедежера на обращение игрока, графика отпусков команды и расходов на рекламу у блогеров.
Один из самых интересных советов, что я встречал по ведению GDD документации - это создание мысленного прохождения своей игры с последующей записью оного. Простая идея? Так почему мало кто ее воплощает в реальность?
Этот прием часто используют при разработке визуальных новелл и линейных кинематографических игр, насколько я знаю, — собственно в кино раскадровки стандартный инструмент. Но в случае игр с открытым миром, с процедурной генерацией сюжетов песочниц — не очень понятно насколько такие эссе или комиксы полезны. Тут скорее можно было бы сказать о важности прототипа. Вернее о важности наиболее простого и эффективного прототипа. Для каких сюжетных игр это может быть действительно просто рассказ или текстовый квест собранный на twine, например. Я лично ink использую для этих же целей.
Прототип очень важен, но описание механик прототипа не менее важно, так как при "масштабировнии" оного можно забыть о механиках, как к примеру в страифлде забыли о невесомости и роботе компаньене.
Про раскадровки. Я вставил пример из марио. Там довольно наглядно показаны механики в виде картинок. Возможно ты этот пример пропустил, так как он вставлен раньше.
На ракадровках очень удобно показывать "механики игры" это будет более наглядно чем читать схемы.
потому что все может быть понятно неправильно будет понято неправильно.А что бы этого не было - документация и нужна, что бы сразу можео было выяснить кто прав а кто занялся самодеятельностью. Без нее это сделать будет в разы труднее и проще свалится в "вечную разработку" как у Криса Робертса.
если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить
А потом не поленится записать что именно ты сделал и зачем. Это как ловушка джокера,зачем мне комментировать код, если я и так все знаю, а через пол года: кто это писал и как легаси код поддерживать?!
Все! БУКВАОЛЬНО ВСЕ! В итоге финальный диздок должен содержать в себе ВСЮ информацию, что бы клон вашей игры могли соорудить по нему и без вас!
Я надеюсь это сознательное преувеличение. Потому что, конечно, во всем нужен взвешенный подход и аджайл с его "работающий продукт важнее документации" тоже не просто так придумали. Документация нужна и как способ структуировать собственные мысли, понять что именно будем разрабатывать, и как способ коммуникации между участниками команды, потому что все может быть понятно неправильно будет понято неправильно. Кажется, что в случае соло-разработчика вторая часть не актуальна (зато очень актуальна первая), но это тоже не совсем так: разработка длится месяцы, если не годы, и за это время у тебя из будущего появляются вопросы к тебе из прошлого: что ты собственно имел ввиду? И тут хорошо если от прошлой версии тебя пришла какая-то корреспонденция.
Но если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить.
По крайне мере в идеале - GDD - это чертеж проекта. Будь игра домом - описанные логику, системы и фичи игры можно сравнить с ... электро и водопроводной сетью. Наличие чертежа - сильно упростит починку труб - если туалет прорвет.
Как и в случае со строительством проектная документация — это не один чертеж, а стопка разных чертежей, таблиц, текстов и т.д. GDD — только часть это документации, в ней не нужно пытаться определять вообще все вплоть до архитектуры серверов для мультиплеера, времени ответа поддержки коммьюнити менедежера на обращение игрока, графика отпусков команды и расходов на рекламу у блогеров.
Один из самых интересных советов, что я встречал по ведению GDD документации - это создание мысленного прохождения своей игры с последующей записью оного. Простая идея? Так почему мало кто ее воплощает в реальность?
Этот прием часто используют при разработке визуальных новелл и линейных кинематографических игр, насколько я знаю, — собственно в кино раскадровки стандартный инструмент. Но в случае игр с открытым миром, с процедурной генерацией сюжетов песочниц — не очень понятно насколько такие эссе или комиксы полезны. Тут скорее можно было бы сказать о важности прототипа. Вернее о важности наиболее простого и эффективного прототипа. Для каких сюжетных игр это может быть действительно просто рассказ или текстовый квест собранный на twine, например. Я лично ink использую для этих же целей.
Прототип очень важен, но описание механик прототипа не менее важно, так как при "масштабировнии" оного можно забыть о механиках, как к примеру в страифлде забыли о невесомости и роботе компаньене.
Про раскадровки. Я вставил пример из марио. Там довольно наглядно показаны механики в виде картинок.
Возможно ты этот пример пропустил, так как он вставлен раньше.
На ракадровках очень удобно показывать "механики игры" это будет более наглядно чем читать схемы.
потому что все может быть понятно неправильно будет понято неправильно.А что бы этого не было - документация и нужна, что бы сразу можео было выяснить кто прав а кто занялся самодеятельностью. Без нее это сделать будет в разы труднее и проще свалится в "вечную разработку" как у Криса Робертса.
если быстрее что-то просто реализовать, оттестить и зафиксировать, чем это расписывать, то лучше реализовать и оттестить
А потом не поленится записать что именно ты сделал и зачем. Это как ловушка джокера,зачем мне комментировать код, если я и так все знаю, а через пол года: кто это писал и как легаси код поддерживать?!