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