Ошибки при создании дизайн-документа
На "Манжетах" вышла статья Артёма Волкова об основных ошибках начинающих геймдизайнеров при создании дизайн-документов. Большая часть текста посвящена вопросам оформления и форматирования.
Основные моменты статьи, на которые действительно стоит обратить внимание:
1. Разбивайте документацию на несколько файлов. Каждый должен описывать свою и только свою область и содержать перекрёстные ссылки на другие документы. Например, верхнеуровневое описание должно быть разработано отдельно от таблицы баланса.
2. ГДД создаётся для проектной команды, а не для себя. Поэтому документы должны быть удобночитаемыми с простыми и понятными формулировками.
3. Структура однотипных документов должна быть едина. В каждом разделе информация должна подаваться от важного в второстепенному, от общего к частному.
4. Не описывайте конкретные значения переменных в тексте документа, а давайте ссылки на эти переменные. Значения переменных, описанные отдельно, можно будет исправить.
От себя я хочу добавить ещё пару замечаний, который улучшат работу с документацией:
1. Храните документы в одном месте. Как правило, это проектный репозиторий.
2. Обновляйте документацию ASAP, Поддержка актуального состояния - дело не простое, но оно позволяет избегать проблем на поздних стадиях разработки.
3. Пишите причины исправления в лог версии. Указывайте заказчиков исправления, номер раздела, потребность и всю информацию, которая поможет восстановить последовательность событий для принятия решения.
4. Добавляйте больше графиков и изображений для описания алгоритмов, Use Case. Отдавайте предпочтение визуальному формализованному языку, а не текстовым описаниям.
Сама статья:
https://gdcuffs.com/7-ways-to-fuck-up/ (~5 минут)
#Документация
На "Манжетах" вышла статья Артёма Волкова об основных ошибках начинающих геймдизайнеров при создании дизайн-документов. Большая часть текста посвящена вопросам оформления и форматирования.
Основные моменты статьи, на которые действительно стоит обратить внимание:
1. Разбивайте документацию на несколько файлов. Каждый должен описывать свою и только свою область и содержать перекрёстные ссылки на другие документы. Например, верхнеуровневое описание должно быть разработано отдельно от таблицы баланса.
2. ГДД создаётся для проектной команды, а не для себя. Поэтому документы должны быть удобночитаемыми с простыми и понятными формулировками.
3. Структура однотипных документов должна быть едина. В каждом разделе информация должна подаваться от важного в второстепенному, от общего к частному.
4. Не описывайте конкретные значения переменных в тексте документа, а давайте ссылки на эти переменные. Значения переменных, описанные отдельно, можно будет исправить.
От себя я хочу добавить ещё пару замечаний, который улучшат работу с документацией:
1. Храните документы в одном месте. Как правило, это проектный репозиторий.
2. Обновляйте документацию ASAP, Поддержка актуального состояния - дело не простое, но оно позволяет избегать проблем на поздних стадиях разработки.
3. Пишите причины исправления в лог версии. Указывайте заказчиков исправления, номер раздела, потребность и всю информацию, которая поможет восстановить последовательность событий для принятия решения.
4. Добавляйте больше графиков и изображений для описания алгоритмов, Use Case. Отдавайте предпочтение визуальному формализованному языку, а не текстовым описаниям.
Сама статья:
https://gdcuffs.com/7-ways-to-fuck-up/ (~5 минут)
#Документация
В продолжение темы про работу с документацией
Настоящей проблемой является не то, КАК нужно оформлять документацию, а то, ЧТО нужно в ней писать. Мой опыт работы в IT сфере подсказывает, что среди команд нет чётко сформулировной структуры сущностей, которые необходимо описывать. При переходе специалиста на новый проект (даже в рамках одной компании) часть времени тратится на повторное обучение работы с требованиями.
На игровых проектах очень мало внимания уделяется унификации. Одни команды сосредотачиваются на описании геймплейного цикла и игровых ограничений, другие - на описании сюжета и взаимодействию с персонажами. Это означает, что идеальной документации не существует.
Энтузиастами пытаются стандартизировать GDD и оставить в них выжимку полезной информации. Шаблоном одного из таких "концентрированных" документов я хочу сегодня поделиться с вами. Его особенность заключается в структуре "от общего к частному, от простого к сложному" и охватывает если не все, то большинство игровых модулей, включая читы и пасхальные яйца.
Шаблон я выложил на нашем Trello-проекте (там же оригинальный документ):
https://trello.com/c/dE1PK4dX
В дополнение рекомендую прочитать замечательную книгу Дина Леффингуэлла "Принципы работы с требования к программному беспечению". В книге описаны полезные приёмы выработки и формализации требований, а так же примеры проектных документаций. Минусом книги может являться её древность, но я с уверенностью могу сказать, что она прошла проверку временем.
#Документация
Настоящей проблемой является не то, КАК нужно оформлять документацию, а то, ЧТО нужно в ней писать. Мой опыт работы в IT сфере подсказывает, что среди команд нет чётко сформулировной структуры сущностей, которые необходимо описывать. При переходе специалиста на новый проект (даже в рамках одной компании) часть времени тратится на повторное обучение работы с требованиями.
На игровых проектах очень мало внимания уделяется унификации. Одни команды сосредотачиваются на описании геймплейного цикла и игровых ограничений, другие - на описании сюжета и взаимодействию с персонажами. Это означает, что идеальной документации не существует.
Энтузиастами пытаются стандартизировать GDD и оставить в них выжимку полезной информации. Шаблоном одного из таких "концентрированных" документов я хочу сегодня поделиться с вами. Его особенность заключается в структуре "от общего к частному, от простого к сложному" и охватывает если не все, то большинство игровых модулей, включая читы и пасхальные яйца.
Шаблон я выложил на нашем Trello-проекте (там же оригинальный документ):
https://trello.com/c/dE1PK4dX
В дополнение рекомендую прочитать замечательную книгу Дина Леффингуэлла "Принципы работы с требования к программному беспечению". В книге описаны полезные приёмы выработки и формализации требований, а так же примеры проектных документаций. Минусом книги может являться её древность, но я с уверенностью могу сказать, что она прошла проверку временем.
#Документация
Хранение идей, возникших во время проектирования
Работа геймдизайнера связана с творчеством. На начальных стадиях проектирования игры весомую долю времени занимает брейншторминг и моделирование игровой системы. В результате таких сессий на бумаге остаётся много идей, не вошедших в итоговую игру (зато отлично нашедших место в рабочем столе).
Идея не должна пропадать даром. Кто-то ведёт базу знаний, кто-то заклеивает стены офиса карточками с возникшими идеями "чтобы были на виду". Систематизация идей помогает ориентироваться среди них, особенно когда их копится неприлично много.
В статье ниже приведён один из подходов к систематизации идей по игровым механикам (и не только по ним, на самом деле). Это список с уникальной легендой, которая помогает определить влияние механики на игровой процесс, её новизну и возможные ожидания игрока от её использования:
https://www.gamedev.net/articles/game-design/a-simple-format-to-archive-design-decisions-r5049/
#Документация
Работа геймдизайнера связана с творчеством. На начальных стадиях проектирования игры весомую долю времени занимает брейншторминг и моделирование игровой системы. В результате таких сессий на бумаге остаётся много идей, не вошедших в итоговую игру (зато отлично нашедших место в рабочем столе).
Идея не должна пропадать даром. Кто-то ведёт базу знаний, кто-то заклеивает стены офиса карточками с возникшими идеями "чтобы были на виду". Систематизация идей помогает ориентироваться среди них, особенно когда их копится неприлично много.
В статье ниже приведён один из подходов к систематизации идей по игровым механикам (и не только по ним, на самом деле). Это список с уникальной легендой, которая помогает определить влияние механики на игровой процесс, её новизну и возможные ожидания игрока от её использования:
https://www.gamedev.net/articles/game-design/a-simple-format-to-archive-design-decisions-r5049/
#Документация
GameDev.net
A Simple Format to Archive Design Decisions
Before starting production on Nanotale, we took some time to prototype various typing gameplay ideas. When prototyping, you have to focus
Гейм дизайн документ Grand Theft Auto
Под конец дня - GDD самой первой части легендарной серии Grand Thedt Auto. Да, для 2019 года этот артефакт изрядно устарел, но именно с его помощью на свет появилась игра.
https://ru.scribd.com/doc/53563149/Grand-Theft-Auto-Design-Document
Больше дизайн-документов по тегу
#Документация
Под конец дня - GDD самой первой части легендарной серии Grand Thedt Auto. Да, для 2019 года этот артефакт изрядно устарел, но именно с его помощью на свет появилась игра.
https://ru.scribd.com/doc/53563149/Grand-Theft-Auto-Design-Document
Больше дизайн-документов по тегу
#Документация
Scribd
Grand Theft Auto Design Document
Scribd is the world's largest social reading and publishing site.
Советы по написанию гейм дизайн документа
Мы уделили много внимания написанию главного документа в жизни геймдизайнера (один из шаблонов можете найти в нашем trello). Тем не менее, всегда найдётся ещё несколько дельных советов, которые помогут по-другому взглянуть на его создание. Например, коллеги из Sloperama Productions рекомендуют составлять документ, держа в голове следующие правила.
Большая часть геймдизайна должна выглядеть как художественное произведение
Вместо того, чтобы документ выглядет как список покупок, для каждого описываемого элемента нужно добавлять описание, соответствующее игровому лору. Вы должны ясно передать, какие эмоции и опыт должен получить игрок при взаимодействии с описываемым элементом, а не просто перечислять контент вашей игры.
Например, вместо списка
Оружие: меч, лук и стрелы, катапульта, пулемёт
Составить список
Оружие
Меч - меч тролля, поэтому он большой и тяжёлый, с потёртостями и царапинами. Он всетится бледно-зелёным цветом во время полнолуния.
Лук и стрелы - их сделали Апачи в 1867 году, и они попали в игру через пространственно-временной континуум, созданный злым магом.
Катапульта - ваше стандартное оружие дальнего боя. Имеет при себе запас тяжелых камней и стреляет на 300 метров вперёд (долетает до Лос-Анджелеса).
Пулемёт - описание не нужно, вы посмотрите КАК он хорошо выглядит в инвентаре.
Не создавайте инструкции в техническом документе
Инструкции нужны для помощи запутавшимся игрокам, которые не знают как пройти игру дальше. Они должны давать понять, на что смотрик игрок и как с этим взаимодействовать. Так как игроки не хотят тратить много времени на чтение, описывайте инструкции несколькими словами. Назначение дизайн документа - полное описание всего происходящего в игре. Поэтому он не должен быть похож на инструкцию.
Используйте разные способы представления информации
Не ограничивайтесь только словами. Добавляйте в документ как можно больше следующих вещей:
1. Таблицы;
2. Изображения и сноски с объяснениями;
3. Блок-схемы;
4. Диаграммы UML - Use Case, Sequence, Class;
5. Графики.
UPD. В чатике подсказывают, что художественное описание функциональности - это, конечно, хорошо, но лучше её выносить в отдельный документ. Таким образом дизайн документ будет легче восприниматься в процессе разработки. А художественная часть может служить референсом для того, чтобы команда оставалась на одной волне.
#Документация
Мы уделили много внимания написанию главного документа в жизни геймдизайнера (один из шаблонов можете найти в нашем trello). Тем не менее, всегда найдётся ещё несколько дельных советов, которые помогут по-другому взглянуть на его создание. Например, коллеги из Sloperama Productions рекомендуют составлять документ, держа в голове следующие правила.
Большая часть геймдизайна должна выглядеть как художественное произведение
Вместо того, чтобы документ выглядет как список покупок, для каждого описываемого элемента нужно добавлять описание, соответствующее игровому лору. Вы должны ясно передать, какие эмоции и опыт должен получить игрок при взаимодействии с описываемым элементом, а не просто перечислять контент вашей игры.
Например, вместо списка
Оружие: меч, лук и стрелы, катапульта, пулемёт
Составить список
Оружие
Меч - меч тролля, поэтому он большой и тяжёлый, с потёртостями и царапинами. Он всетится бледно-зелёным цветом во время полнолуния.
Лук и стрелы - их сделали Апачи в 1867 году, и они попали в игру через пространственно-временной континуум, созданный злым магом.
Катапульта - ваше стандартное оружие дальнего боя. Имеет при себе запас тяжелых камней и стреляет на 300 метров вперёд (долетает до Лос-Анджелеса).
Пулемёт - описание не нужно, вы посмотрите КАК он хорошо выглядит в инвентаре.
Не создавайте инструкции в техническом документе
Инструкции нужны для помощи запутавшимся игрокам, которые не знают как пройти игру дальше. Они должны давать понять, на что смотрик игрок и как с этим взаимодействовать. Так как игроки не хотят тратить много времени на чтение, описывайте инструкции несколькими словами. Назначение дизайн документа - полное описание всего происходящего в игре. Поэтому он не должен быть похож на инструкцию.
Используйте разные способы представления информации
Не ограничивайтесь только словами. Добавляйте в документ как можно больше следующих вещей:
1. Таблицы;
2. Изображения и сноски с объяснениями;
3. Блок-схемы;
4. Диаграммы UML - Use Case, Sequence, Class;
5. Графики.
UPD. В чатике подсказывают, что художественное описание функциональности - это, конечно, хорошо, но лучше её выносить в отдельный документ. Таким образом дизайн документ будет легче восприниматься в процессе разработки. А художественная часть может служить референсом для того, чтобы команда оставалась на одной волне.
#Документация
Техническое задание для саунд-дизайнера
Читатель канала поделился шаблоном ТЗ для передачи в работу саунд-дизайнеру. Этот шаблон помогает в общении со звуковиками и позволяет ясно и лаконично передать требования для создания правильных звуков.
ТЗ представляет собой таблицу, содержащую следующие колонки:
1. Тип звука. Указание на то, является ли звуковой файл эффектом (SFX) или музыкальным треком (Music).
2. Описание. Описание требований к звуку, его свойств:
2.1. Продолжительность.
2.2. Цикличность (окончание трека сопоставимо с его началом).
2.3. Дополнительные эффекты (затухание, нарастание).
2.4. Применение звука - в UI, фоновая музыка, звук выстрела и т.д.
2.5. Описание события, при котором звук должен воспроизводиться.
3. Отсылки. Ссылки на звуки, видео и изображения для передачи знания об ожидании заказчика.
4. Название файла. Важный атрибут, благодаря которому при сборке игры код вызова звука обращался к данному звуковому файлу.
5. Приоритет звука. Описание того, какие звуки будут проигрываться в игре чаще всего, и над какими файлами нужно будет поработать в первую очередь.
6. Стоимость. Заполняется стороной, создающей звуки, для предоставления сметы по работе.
Что можно улучшить:
1. Таблица представляет собой структурированный набор данных. То есть атрибуты (а не значения атрибутов) каждого файла не изменяются. Файлы всегда имеют продолжительность, референсы и т.п. В таком случае удобно нормализировать таблицу, и разделить столбец "Описание" на атомарные столбцы.
Закари Куарлес, саунд-дизайнер Quake, RAGE, DOOM и других видеоигр написал заметку о том, какие ещё атрибуты полезно видеть саунд-дизайнеру в техническом задании:
http://zacharyquarles.com/blog/?p=518
#Документация
Читатель канала поделился шаблоном ТЗ для передачи в работу саунд-дизайнеру. Этот шаблон помогает в общении со звуковиками и позволяет ясно и лаконично передать требования для создания правильных звуков.
ТЗ представляет собой таблицу, содержащую следующие колонки:
1. Тип звука. Указание на то, является ли звуковой файл эффектом (SFX) или музыкальным треком (Music).
2. Описание. Описание требований к звуку, его свойств:
2.1. Продолжительность.
2.2. Цикличность (окончание трека сопоставимо с его началом).
2.3. Дополнительные эффекты (затухание, нарастание).
2.4. Применение звука - в UI, фоновая музыка, звук выстрела и т.д.
2.5. Описание события, при котором звук должен воспроизводиться.
3. Отсылки. Ссылки на звуки, видео и изображения для передачи знания об ожидании заказчика.
4. Название файла. Важный атрибут, благодаря которому при сборке игры код вызова звука обращался к данному звуковому файлу.
5. Приоритет звука. Описание того, какие звуки будут проигрываться в игре чаще всего, и над какими файлами нужно будет поработать в первую очередь.
6. Стоимость. Заполняется стороной, создающей звуки, для предоставления сметы по работе.
Что можно улучшить:
1. Таблица представляет собой структурированный набор данных. То есть атрибуты (а не значения атрибутов) каждого файла не изменяются. Файлы всегда имеют продолжительность, референсы и т.п. В таком случае удобно нормализировать таблицу, и разделить столбец "Описание" на атомарные столбцы.
Закари Куарлес, саунд-дизайнер Quake, RAGE, DOOM и других видеоигр написал заметку о том, какие ещё атрибуты полезно видеть саунд-дизайнеру в техническом задании:
http://zacharyquarles.com/blog/?p=518
#Документация
Forwarded from Кодзима Гений - канал про геймдизайн
Ошибки при создании дизайн-документа
На "Манжетах" вышла статья Артёма Волкова об основных ошибках начинающих геймдизайнеров при создании дизайн-документов. Большая часть текста посвящена вопросам оформления и форматирования.
Основные моменты статьи, на которые действительно стоит обратить внимание:
1. Разбивайте документацию на несколько файлов. Каждый должен описывать свою и только свою область и содержать перекрёстные ссылки на другие документы. Например, верхнеуровневое описание должно быть разработано отдельно от таблицы баланса.
2. ГДД создаётся для проектной команды, а не для себя. Поэтому документы должны быть удобночитаемыми с простыми и понятными формулировками.
3. Структура однотипных документов должна быть едина. В каждом разделе информация должна подаваться от важного в второстепенному, от общего к частному.
4. Не описывайте конкретные значения переменных в тексте документа, а давайте ссылки на эти переменные. Значения переменных, описанные отдельно, можно будет исправить.
От себя я хочу добавить ещё пару замечаний, который улучшат работу с документацией:
1. Храните документы в одном месте. Как правило, это проектный репозиторий.
2. Обновляйте документацию ASAP, Поддержка актуального состояния - дело не простое, но оно позволяет избегать проблем на поздних стадиях разработки.
3. Пишите причины исправления в лог версии. Указывайте заказчиков исправления, номер раздела, потребность и всю информацию, которая поможет восстановить последовательность событий для принятия решения.
4. Добавляйте больше графиков и изображений для описания алгоритмов, Use Case. Отдавайте предпочтение визуальному формализованному языку, а не текстовым описаниям.
Сама статья:
https://gdcuffs.com/7-ways-to-fuck-up/ (~5 минут)
#Документация
На "Манжетах" вышла статья Артёма Волкова об основных ошибках начинающих геймдизайнеров при создании дизайн-документов. Большая часть текста посвящена вопросам оформления и форматирования.
Основные моменты статьи, на которые действительно стоит обратить внимание:
1. Разбивайте документацию на несколько файлов. Каждый должен описывать свою и только свою область и содержать перекрёстные ссылки на другие документы. Например, верхнеуровневое описание должно быть разработано отдельно от таблицы баланса.
2. ГДД создаётся для проектной команды, а не для себя. Поэтому документы должны быть удобночитаемыми с простыми и понятными формулировками.
3. Структура однотипных документов должна быть едина. В каждом разделе информация должна подаваться от важного в второстепенному, от общего к частному.
4. Не описывайте конкретные значения переменных в тексте документа, а давайте ссылки на эти переменные. Значения переменных, описанные отдельно, можно будет исправить.
От себя я хочу добавить ещё пару замечаний, который улучшат работу с документацией:
1. Храните документы в одном месте. Как правило, это проектный репозиторий.
2. Обновляйте документацию ASAP, Поддержка актуального состояния - дело не простое, но оно позволяет избегать проблем на поздних стадиях разработки.
3. Пишите причины исправления в лог версии. Указывайте заказчиков исправления, номер раздела, потребность и всю информацию, которая поможет восстановить последовательность событий для принятия решения.
4. Добавляйте больше графиков и изображений для описания алгоритмов, Use Case. Отдавайте предпочтение визуальному формализованному языку, а не текстовым описаниям.
Сама статья:
https://gdcuffs.com/7-ways-to-fuck-up/ (~5 минут)
#Документация
Примеры дизайн-документов видеоигр
Действительно большое собрание примеров документации было собрано в одном твиттер-треде пользователем Nicola Dau. Здесь все: таблицы excel, питчи, детальная документация и многое другое.
Не поленитесь, посмотрите, что вам может пригодиться в работе. Ну или просто посмотрите, в чем заключается смысл работы геймдизайнера.
Ссылка на тред:
https://twitter.com/dau_nicola/status/1555820158928707584?s=21&t=fC77i7vGJQ5tdYBENctVBw
#документация
#геймдизайн
Действительно большое собрание примеров документации было собрано в одном твиттер-треде пользователем Nicola Dau. Здесь все: таблицы excel, питчи, детальная документация и многое другое.
Не поленитесь, посмотрите, что вам может пригодиться в работе. Ну или просто посмотрите, в чем заключается смысл работы геймдизайнера.
Ссылка на тред:
https://twitter.com/dau_nicola/status/1555820158928707584?s=21&t=fC77i7vGJQ5tdYBENctVBw
#документация
#геймдизайн
X (formerly Twitter)
Nicola Dau (@dau_nicola) on X
📄EXAMPLES OF GAME DESIGN DOCS
Finding examples of #gamedesign documentation is hard. As a recent graduate in the field, what better time for me to share some of my university work in case it might help new students find inspiration?
Here's a🧵 full of it!
Finding examples of #gamedesign documentation is hard. As a recent graduate in the field, what better time for me to share some of my university work in case it might help new students find inspiration?
Here's a🧵 full of it!
Тут в чатике вспомнили, как в далёком 2019 году мы с чатиком собрались для хакатона DTF чтобы запилить игру за пару суток.
Из этой задумки, конечно, целевого результата достичь не удалось. Но побочные продукты в виде пары статей и дизайн-документа появились.
Прошу ознакомиться, в частности тем, кто только начинает свой путь в игровой индустрии или хочет принять участие в хакатоне:
https://t.me/kojima_calls/1119
https://t.me/kojima_calls/1154
P.S. Я хотел запилить и третью статью с описанием процесса разработки и коммуникации в распределённой команде. Но, во-первых, после ковида практически каждый из вас столкнулся с этим опытом. А во-вторых, я просто забыл все нюансы.
#Опыт
#Документация
Из этой задумки, конечно, целевого результата достичь не удалось. Но побочные продукты в виде пары статей и дизайн-документа появились.
Прошу ознакомиться, в частности тем, кто только начинает свой путь в игровой индустрии или хочет принять участие в хакатоне:
https://t.me/kojima_calls/1119
https://t.me/kojima_calls/1154
P.S. Я хотел запилить и третью статью с описанием процесса разработки и коммуникации в распределённой команде. Но, во-первых, после ковида практически каждый из вас столкнулся с этим опытом. А во-вторых, я просто забыл все нюансы.
#Опыт
#Документация
Telegram
Кодзима Гений
Как казаки на хакатон ездили: Сбор команды
Ну наконец-то я добрался до рефлексии насчёт участия команды "Кодзимы Гения" на хакатоне DTF. Изначально я хотел написать огромный лонгдринк по всем активностям - от сбора команды до заливания сборки на сайт хакатона.…
Ну наконец-то я добрался до рефлексии насчёт участия команды "Кодзимы Гения" на хакатоне DTF. Изначально я хотел написать огромный лонгдринк по всем активностям - от сбора команды до заливания сборки на сайт хакатона.…
Принципы написания дизайн-документа
И другой проектной документации.
Артём Волков в своём блоге на Medium сделал подборку принципов, благодаря которым все аналитические и дизайн-артефакты могут стать понятными, удобными, практически полезными.
Я сам применяю часть описанных принципов в работе (например, KISS и DRY), поэтому рекомендую ознакомиться с описанием каждого из них:
https://medium.com/@tricky_fat_cat/clean-design-documentation-principles-59819b9913d6
#Документация
И другой проектной документации.
Артём Волков в своём блоге на Medium сделал подборку принципов, благодаря которым все аналитические и дизайн-артефакты могут стать понятными, удобными, практически полезными.
Я сам применяю часть описанных принципов в работе (например, KISS и DRY), поэтому рекомендую ознакомиться с описанием каждого из них:
https://medium.com/@tricky_fat_cat/clean-design-documentation-principles-59819b9913d6
#Документация
Medium
Clean Design Documentation Principles
Now I want to tell you about principles which can help you to improve the quality of your game design documentation.