Комментарии 11
Хорошая статья, спасибо автору.
Вообще писать качественные ТЗ и диздоки весьма интересная работа. И не только геймдизайнеры это делают :-)
Вообще писать качественные ТЗ и диздоки весьма интересная работа. И не только геймдизайнеры это делают :-)
Интересно, есть существенное отличие Wiki от Google Docs — кроме очевидного удобства для работы с текстом во втором варианте (и менее удобной работы с перекрестными ссылками на внутренние ресурсы)
Для небольших команд Google Docs в принципе применим — в статье просто речь о крупных компаниях. Для них же поднимаются такие вопросы:
— интеграция с системами отслеживажния ошибок/управления проектом/… принятыми в компании. К примеру, драму насчет решения Atlassian про интеграцию с Google Docs можно почитать тут — answers.atlassian.com/questions/140987/linking-google-docs-documents-to-jira-issue-in-jira-ondemand — и в целом, вики-решения интегрировать как правило намного проще.
— необходимость держать документы в внутренней офисной сети (соображения безопасности, логгирования всего доступа)
— уже упомянутые перекрёстные ссылки на внутренние ресурсы
— на вики-движках намного проще обеспечить распределение прав доступа по компании — соответствующие доступы по отдельным проектам/командам, новые сотрудники и увольнения,… всё решается проще.
И, наконец, в крупных компаниях редко бывают реально коллаборативные дизайн-документы — обычно только один гейм-дизайнер (ответственный за направление либо исполнитель задачи) пишет документ, а коллеги только комментируют. Подход «дизайним сразу всей командой» очень редок.
Кстати, Google Docs нередко применяются и параллельно вики-движку — как раз для общего редактирования текста, к примеру, сбора отзывов после плейтеста. После чего «выжимка» из общего набора мнений перекладывается на вики.
— интеграция с системами отслеживажния ошибок/управления проектом/… принятыми в компании. К примеру, драму насчет решения Atlassian про интеграцию с Google Docs можно почитать тут — answers.atlassian.com/questions/140987/linking-google-docs-documents-to-jira-issue-in-jira-ondemand — и в целом, вики-решения интегрировать как правило намного проще.
— необходимость держать документы в внутренней офисной сети (соображения безопасности, логгирования всего доступа)
— уже упомянутые перекрёстные ссылки на внутренние ресурсы
— на вики-движках намного проще обеспечить распределение прав доступа по компании — соответствующие доступы по отдельным проектам/командам, новые сотрудники и увольнения,… всё решается проще.
И, наконец, в крупных компаниях редко бывают реально коллаборативные дизайн-документы — обычно только один гейм-дизайнер (ответственный за направление либо исполнитель задачи) пишет документ, а коллеги только комментируют. Подход «дизайним сразу всей командой» очень редок.
Кстати, Google Docs нередко применяются и параллельно вики-движку — как раз для общего редактирования текста, к примеру, сбора отзывов после плейтеста. После чего «выжимка» из общего набора мнений перекладывается на вики.
Вопрос на 100 балов, перед началом чтения: а что такое диздок? :)
Не отождествляю это название с сущностью.
Не отождествляю это название с сущностью.
В этом-то и подвох: как правило те, кто задают вопрос «что такое диздок?», и так не имеют иллюзий на этот счёт, на развеивание которых направлен текст ;)
К сожалению, эволюция этих иллюзий была весьма печальна, к примеру
www.gamedev.ru/projects/forum/?id=8221 (2005 год)
gmakers.ru/index.php?topic=54.0 (2008)
smartresponder.ru/web_version.php?Action=ShowArchiveMessage&q=001Xja002EXc00ip0N3cb53b0c (2014)
И даже в 2014… «Детальное описание игры… Под детальным описание подразумевается, как и общий концепт так и объектная модель мира т.е опись каждого игрового объекта с его характеристикой.»
В этом нет упрека — можно делать и такие диздоки (наследие старой школы документации геймдизайна на Западе — которой уже почти нет), просто последующий опыт работы в крупной компании может оказаться шокирующим.
Если же у вас нет иллюзий, это отлично! ;) Диздок — дизайн-документ — просто вариант оформления геймдизайна (всей игры или ее части) в проектной документации. И всё. Остальное — уже зависит от проекта и работодателя ;)
Примеры, как сделать это «оформление» более структурированным и удобочитаемым для коллег — это уже тема отдельных статей и курсов.
К сожалению, эволюция этих иллюзий была весьма печальна, к примеру
www.gamedev.ru/projects/forum/?id=8221 (2005 год)
gmakers.ru/index.php?topic=54.0 (2008)
smartresponder.ru/web_version.php?Action=ShowArchiveMessage&q=001Xja002EXc00ip0N3cb53b0c (2014)
И даже в 2014… «Детальное описание игры… Под детальным описание подразумевается, как и общий концепт так и объектная модель мира т.е опись каждого игрового объекта с его характеристикой.»
В этом нет упрека — можно делать и такие диздоки (наследие старой школы документации геймдизайна на Западе — которой уже почти нет), просто последующий опыт работы в крупной компании может оказаться шокирующим.
Если же у вас нет иллюзий, это отлично! ;) Диздок — дизайн-документ — просто вариант оформления геймдизайна (всей игры или ее части) в проектной документации. И всё. Остальное — уже зависит от проекта и работодателя ;)
Примеры, как сделать это «оформление» более структурированным и удобочитаемым для коллег — это уже тема отдельных статей и курсов.
Design Document.
Спасибо.
Пишем всё в гугледоксе — спасибо функции «Вставить оглавление» и стилям текста. Команда небольшая, каждого специалиста по одному экземпляру.
Пишем всё в гугледоксе — спасибо функции «Вставить оглавление» и стилям текста. Команда небольшая, каждого специалиста по одному экземпляру.
Когда я такое писал (2003-2005) Диздок так и выглядел :)
Просто концепт шел как введение, Вижн был основной частью, а фичелист дроблился на приложения. Не было тогда еще адской моды на викидвижки везде и всюду :)
Просто концепт шел как введение, Вижн был основной частью, а фичелист дроблился на приложения. Не было тогда еще адской моды на викидвижки везде и всюду :)
10 лет назад — да, «единый текст» нередко применялся. Но уже тогда в крупных компаниях (на Западе, в основном; хотя, к примеру, документация Аллодов уже была на MoinMoin — 2006 год) распространялся вики-подход и разбиение диздоков на компоненты… а за 10 лет почти все перешли на новый формат. Кроме статей в интернете о диздоках ;)
Возможно, через еще 10 лет парадигма снова изменится, хотя пока очевидных предпосылок еще нет.
Возможно, через еще 10 лет парадигма снова изменится, хотя пока очевидных предпосылок еще нет.
Общий вид не изменился. Изменилась линковка документов между собой. Возникло дробление.
Тоесть раньше по фичелисту шли уже четкие ссылки на лидов и ответственных за разработку и внедрение. Сейчас тоже самое на вики. Как плюс есть контроль версионности, а так же сразу видно кто где гадит. Подход через вики помоему ближе к agile методикам и упрощает их внедрение, вертикальная работа от документа — это явно ближе к waterfall. При разработке игр логично предположить что более вероятно применение agile-подобных схем разработки и как следствие каша в виде викисклада отлично соответствует требованиям.
Тоесть раньше по фичелисту шли уже четкие ссылки на лидов и ответственных за разработку и внедрение. Сейчас тоже самое на вики. Как плюс есть контроль версионности, а так же сразу видно кто где гадит. Подход через вики помоему ближе к agile методикам и упрощает их внедрение, вертикальная работа от документа — это явно ближе к waterfall. При разработке игр логично предположить что более вероятно применение agile-подобных схем разработки и как следствие каша в виде викисклада отлично соответствует требованиям.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как написать диздок