Оффтоп Artem Volkov
3 923

Процессы и документация для начинающих

Меня зовут Артём Волков и на данный момент я являюсь редким в наших кругах гейм-дизайнером фрилансером. Я успел насмотреться на разные маленькие игровые команды, которые пытаются сделать свой проект. Все они допускают приблизительно одни и те же ошибки. О них мы и поговорим.

В закладки

У большинства маленьких молодых команд одни и те же проблемы. Нормальные процессы не построены, простейшее планирование отсутствует, концепция шаткая и не проработана до конца, а документация представляет собой просто творческие идеи, сваленные в кучу.

В итоге сроки разработки затягиваются, путь игрока не отстроен и в игру банально не интересно играть. Деньги утекают быстрее, чем планировалось, а результаты заметно ниже ожидаемых.

Чтобы избежать всех этих проблем надо следовать универсальному правилу ППД — Процессы, Планирование, Документация. Налаживайте процессы, планируйте разработку, следите за своей документацией. Хорошие процессы и документация не гарантируют вам успеха, но с ними заметно проще сделать хорошую игру и довести её до релиза.

Цель ППД — максимально прозрачная структура всех работ над проектом и налаженная коммуникация между членами команды.

Первая проблема у большинства команд — разработка изначально не делится на этапы. Классические крупные этапы разработки:

  • Препродакшен
  • Продакшен
  • Постпродакшен

Не смешивайте этапы препродакшена и продакшена, ни к чему хорошему это не приведёт. Все крупные этапы также необходимо разбить на более мелкие майлстоуны, а их, в свою очередь, на итерации.

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

На этом этапе для вас будет самым важным следующее:

  • Концепт игры
  • Целевая аудитория и сеттинг
  • Ключевые игровые механики
  • План разработки
  • Бюджет

Вы ещё не делаете саму игру, вы только готовитесь к этому. Начните с небольшого прототипа, на котором будет можно попробовать основную механику. Помните — на этом этапе вы максимально гибки и можете разворачивать концепцию на 180 градусов в любой момент и по любой причине. Оценивайте идею, целевую аудиторию, свои ресурсы, риски — и формируйте видение игры.

Препродакшн — лучшее время закапывать мёртвую стюардессу и убивать неудачные идеи, чтобы самолёт летел дальше.

По итогу этого этапа у вас должны быть точно подготовлены:

  • Концепт-документ
  • Дизайн-документ
  • Технические задания
  • UX
  • Прототип основной механики
  • План разработки

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

Продакшен — это этап непосредственного производства игры. Производство стройте по плану, который вы сделали на препродакшене. На этом этапе не должно быть крупных и необоснованных изменений.

Конечно, избежать проблем не получится и что-то менять придётся, т.к. препродакшен не панацея, а некоторые проблемы всплывают на этапе продакшена:

  • Механики. Несмотря на дизайн-документ, при разработке всегда будут всплывать проблемы игровых механик. Поэтому я советую проводить быстрое прототипирование “на кубиках” во время препродакшена.
  • Баланс. Только с готовыми механиками можно понять, что балансировать и как, а во время разработки работать с балансом придётся очень много и меняться будет он часто. Да и сразу не получится получить необходимый баланс.
  • Технические аспекты. Проблемы технического характера всегда будут появляться, и точно предсказать их никто не сможет.

Эти проблемы естественны и существуют на каждом проекте, главное не начинать всё заново и в разгар разработки вместо сюжетного топдаун шутера про цветы-убийцы не делать сессионный FPS про зомби.

Не забывайте играть в свою игру, особенно это касается гейм-дизайнера. Играйте всей командой. Вы найдёте не только новые баги, но и недоработки и неочевидные дыры в балансе или механиках.

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

Если ваша игра стала популярной и приносит деньги, то её надо поддерживать. Поддержка игр заключается в создании дополнений и патчей. Их производство — это очередная цепочка из препродакшена и продакшена, только не всей игры, а конкретного патча или дополнения.

Даже если игра не выстрелила сразу, то не сдавайтесь. Анализируйте фидбек от пользователей и совершенствуйте ваш продукт до тех пор, пока это не станет откровенно убыточным занятием.

Теперь перехожу к самому интересному — документации:

  • Концепт-документ
  • Гейм-дизайн документ
  • UX
  • Балансные таблицы

Концепт-документ описывает идею игры и определяет вектор её развития.

Простые правила хорошего концепт-документа:

  • Краткость. Пишите тезисами. подробностей механик не надо, они ещё несколько раз изменятся при написании ГДД.
  • Ёмкость. Он должен отражать все основные особенности проекта, концепцию ключевого игрового процесса, предполагаемый визуальный стиль.
  • Исправляйте концепт-документ как угодно и сколько угодно раз — но только во время препродакшена.
  • Оформляйте концепты в виде презентаций. Это наглядно и привьёт вам навыки структурирования информации.
  • Альтернативный вариант концепта — User Story с упором на то, какие ощущения будет получать игрок.

В концепте вы обязательно должны прописать:

  • На какую аудиторию он рассчитан. Делать игру про зомби-нацистов на луне с кровавой кашей на экране и заявлять детскую аудиторию 7 лет — не лучшая идея.
  • Игровой фокус. Самое краткое возможное описание концепции игры. Подробнее о нём можно узнать из доклада Григория Чопорова “Гейм-фокус: как не заблудиться в разработке”, который он читал на DevGamm 2017 в Москве
  • User Selling Points (USP). Фичи, которые привлекут игрока, чем будет уникален проект.
  • Список конкурентов и похожих игр. Определите размер рынка, целевую аудиторию конкурентов, их и ваши сильные и слабые стороны в контексте выбранного рынка.

Как только готов и утверждён концепт, можно приступать к написанию гейм-дизайн документа, в простонародье ГДД.

С ГДД всё сложнее. Основная проблема большинства начинающих гейм-дизайнеров, особенно в молодых командах — это желание написать в одном документе всё. Не надо так делать.

Гейм-дизайн документ — это совокупность разных небольших документов. Каждый документ описывает полностью определенную механику или фичу игры и ничего другого.

Для удобства ведения документации советую написать вводный документ, который будет представлять собой текстовую версию концепта, который расширен и описывает концепции механик с ссылками на ГДД.

Ещё важный момент — ГДД обсуждают все, но редактирует всегда 1 человек.

  • Это решит проблему лебедя, рака и щуки. Документы останутся в едином стиле
  • Это позволяет централизованно отслеживать изменения документации
  • Не создавайте бесконечных обсуждений, остановитесь на одном оптимальном решении

Обновляйте ГДД, если по результатам разработки изменились детали некоторых механик, и обязательно оповещайте об этом команду.

Лучше всего писать документацию в Confluenсе, но он платный и система комментирования хуже, чем в Google Docs. Альтернативный вариант как раз Google Docs, они бесплатные. Структуру документации придётся полностью делать самому, но зато у Google Docs отменная система комментирования.

Технические задания (ТЗ) также являются важной частью ГДД, помимо игровой логики в них максимально подробно описываются все задачи по контенту игры — визуальные ассеты, анимации, звуки, музыка и так далее.

ТЗ вам позволит:

  • Оценить необходимые ресурсы
  • Спланировать производство
  • Рассчитать бюджет

ТЗ часто корректируются во время продакшена, это нормально.

UX (user experience) лучше проектировать уже после утверждения механик. В первую очередь напишите User Story — документ с блок-схемой, описывающий путь игрока по интерфейсам игры. Он поможет не только оценить объём интерфейсов, но и примерно прикинуть архитектуру продукта.

После утверждённого User Story делайте простые макеты без дизайна, мокапы. Это упростит работу не только программистам, но и дизайнерам UI.

Большая часть математической модели и баланс создаётся уже во время продакшена, т.к. изменения механик могут сильно спутать карты.

Лучший формат для мат.модели — это таблицы Excel (или аналог в OpenOffice). Google таблицами пользоваться не советую — они медленнее, в них есть ограничения на столбцы и строки, и не так приятно работать с оформлением.

Визуальное оформление таблиц важно. Информация должна быть представлена в максимально доступном виде. Чтобы было ещё проще воспринимать вашу модель — старайтесь комментировать ячейки.

Планирование. Из-за его отсутствия многие маленькие команды делают проекты очень долго. Планирование проекта дисциплинирует команду, позволяет оценить сроки производства, объём необходимых ресурсов и возможные риски.

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

Хорошо написанный и структурированный ГДД является основой для вашего плана:

Ведите фичлист, в котором будет список всех фичей на реализацию с ссылками на документ, исполнителем, сроками.

Записывайте все интересные идеи, которые пока не влезают в ваши сроки и бюджет, в отдельный лист.

Приоритезируйте ваши игровые механики и фичи по важности и сложности

Распишите их последовательность в реализации

Все очень крупные фичи старайтесь разделять на несколько маленьких

Обсудите с командой сроки реализации каждой фичи и не забудьте сразу прибавить 50% времени

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

Делите все крупные этапы на более мелкие майлстоуны, а их — на итерации.

Майлстоуны — это длинный этап, содержащий несколько итераций. В результате получается некоторая версия игры, в которой есть заранее обговоренные фичи и механики. Время длительности майлстоуна обсуждается при планировании, лучше использовать промежутки времени в 1-2 месяца. В этом случае будет чувствоваться прогресс.

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

Длину итерации выбираете сами. Оптимальной длиной итерации я лично считаю 1-2 недели, за это время вы можете успеть сделать что-то понятное и осязаемое.

На итерацию берите ровно столько, сколько сможете сделать, не пытайтесь сразу себя завалить всеми задачами. Если вам кажется, что задача не выполнится за итерацию, то разбейте её на подзадачи. Помните — не задачи существуют для итераций, а итерации для задач.

Почитайте подробнее про систему управления проектами Agile, чтобы вникнуть в эту тему глубже.

Ещё одна проблема, которую мало кто решает в молодых и маленьких командах — постановка и выполнение задач.

Для небольших и молодых команд проще всего использовать классическую Kanban-доску, со столбцами To Do, In Progress, Done. В To do лежат карточки задач, которые надо сделать. В In Progress — которые взяты в работу, а в Done уже завершённые задачи.

Для постановки задач удобно использовать Jira — у неё есть функционал дочерних задач (сабтасков), связи между задачами (например блокеры), и множество других удобных и полезных инструментов. В качестве альтернативы можно использовать Asana или Trello.

Приучите всю команду работать через задачи, это дисциплинирует.

Коммуникации внутри команды также надо налаживать и делать их более структурированными.

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

Выберите одного человека, который будет следить за временем, пресекать флуд и документировать результаты обсуждения.

Все рабочие обсуждения надо документировать — это дисциплинирует команду, а также позволит контролировать все решения. Самый простой способ документирования — Follow-Up. Это простое письмо, в котором тезисно расписаны все принятые решения по итогу обсуждения, оно рассылается всем участникам обсуждения после его завершения.

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

Важно проводить плановые обсуждения итераций, в идеале их должно быть 3 шутки:

  • Стартовое — во время которого происходит планирование, что будете делать на данной итерации. Проводится для того, чтобы ПМ мог оценить насколько корректно все поняли задачи и насколько корректно составили себе приоритеты на неделю, а остальные участники работ узнали бы про планы других. И смогли бы скорректировать планы по задачам, если они завязаны друг на друга.
  • Промежуточное — это быстрая синхронизация команды, на которой важно понять, есть ли у кого проблемы и как они влияют на завершение задачи. Нельзя врать о проблемах и их состоянии. Никого нельзя наказывать за проблемы и затыки. Проблемы надо находить и совместно решать, вы команда.
  • Конечное обсуждение — тут подводятся итоги итерации.

И ещё немного советов напоследок:

  • Процессы — не серебряная пуля успешных проектов. Это револьвер, при помощи которого выпускаемые вами пули летят кучнее, точнее и дальше.
  • Лучше потратить 2-3 месяца на препродакшен, а не 2-3 года на провальный проект
  • Лучше закрыть проект на препродакшене, чем мусолить его закрытие на продакшене
  • Убивайте проект на любом этапе, не превращайте его в ненужную работу ради работы, вытягивающую силы, деньги и ресурсы команды.
  • Идеальных документов не бывает
  • Документация зависит от жанра, объёма работ, методологии, привычек команды
  • Хорошие документы получаются не сразу, пишите постоянно, набивайте опыт
  • Пишите как можно однозначнее! Всё, что может быть понято более, чем одним образом — БУДЕТ понято не так, как хотелось.

Отдельное спасибо за помощь по докладу и статье Александру Пашину, Артёму Турушину, Алексею Калинину и Сергею Гиммерлейху.

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Artem Volkov", "author_type": "self", "tags": [], "comments": 72, "likes": 79, "favorites": 87, "is_advertisement": false, "subsite_label": "flood", "id": 13802, "is_wide": false }
{ "id": 13802, "author_id": 16933, "diff_limit": 1000, "urls": {"diff":"\/comments\/13802\/get","add":"\/comments\/13802\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/13802"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64955 }

72 комментария 72 комм.

Популярные

По порядку

Написать комментарий...
11

Слишком много котиков

Ответить
8

Не бывает такой вещи как "слишком много котиков".

Ответить
1

Он сам как кот Базилио. Не удивительно.

Ответить
0

И среди них нет Гоши, хотя он тут был бы прямо в тему :(

Ответить
0

А можно Вигерса почитать для начала) или завести маленького такого, карманного, бизнес-аналитика

Ответить
8

Примеры бы
Концепт-документ
Гейм-дизайн документ
UX
Балансные таблицы

Ответить
4

Соглашусь. Я только о них слышал в теории, но никогда они мне в живую не попадались. Это как идеальная теща. Похоже на мифЪ.

Ответить
0

Это как идеальная теща. Похоже на мифЪ.

вовсе нет. Это я, как обладатель идеальной тещи говорю

Ответить
0

Ну ишь как оно бывает, иной раз миф становится реальностью... Для одного йети в Госдуме даже кресло специальное инсталлировали.

Ответить
0

1) Прооблема NDA
2) Проблема в том, что документация зависит от множества факторов.

Ответить
6

Можно, взять какую-нибудь игру и описать её в ГДД. Необязательно большую (тетрис, любую игру ketchapp). Потому что советы типа "сделайте ГДД" – это конечно хорошо, но это полезно только для совсем начинающих.

У меня вот такая проблема: пытаюсь составить ГДД и не знаю, на какие разделы его разбивать – хочется всю игру на одной странице описать. И где посмотреть best practice – не знаю.

Ответить
0

Вот кстати ГДД первой Диаблы

Ответить
2

Это питч, вроде, а не ГДД.

Ответить
3

Если есть цель продать игру, то питч. Если ты решил пилить игру, то ГДД. От задачи зависит. Содержание дока часто меняется под обстоятельства. У кого-то будет страничка, у кого-то будет целая книга со связями, мокапами, посчитанными балансами и так далее. Все очень зависит от подходов.

Главное, чему стоит следовать - не упарываться. Писать максимально коротко и емко, но чтобы было всем понятно, о чем вообще тут все. Потому что большой объем потребует много сил на саппорт всего этого. Самому потом сложно будет найти важную инфу.

Но тут есть важное НО. Как только все поняли, что вот это все играбельно и то, что нам нужно, сразу же все фиксируйте. Иначе потом не найдете хвостов, и опять же возникнут трудности с поиском важного и нужного.

Программисты напилят реализации. Через год новопришедший ГД захочет перепилить какую-нибудь функциональность. А программист тот уволился. У нового ГД на руках ничего нет. Начинается реверс-инжиниринг, а это больно и долго...

Ответить
1

Разбивай на составляющие, к примеру:
- Строительство
- Добыча ресурсов
- Прокачка юнитов
- Линейка открытий и т.д.

Ответить
1

В одной странице вы можете описать главные Loop'ы игрока в игре. И потом к этому нацеплять уже отдельные описания всех механик, фичей, экономики и так далее.

Ответить
0

Ну сморите, у меня так:
1) Вводная часть - кратко про игру, мини-питч своего рода
2) Базовая механика (описание матч-3, например для матч-3, или механики сражений для Дарк соулс)
3) HUD
4) Интерфейс - сюда включаются мокапы главных экранов и то, что автор статьи назвал User Story
5-256) Остальные механики, по одному пункту на каждую механику (туториал, диалоги, инвентарь, карта и т. д.)

Если механика привязана к интерфейсу (например, настройки или инвентарь) то мокап этого окна вкладывается в соответствующую механику. Потом заменяется на превью. Остальные мокапы вкладываются в интерфейс.

Если делаете f2p, то в конце не забудьте такие пункты, как сбор статистики, метод настройки баланса и админка.

Ответить
1

Отдельный спорный момент с анимациями. По моему опыту толку от того, чтобы описывать их словами в документе особого нет - аниматору проще объяснить на пальцах, а кодер будет делать по видео.

Ответить
0

То есть, в ГДД не нужно описывать поведение каждого моба и каждой кнопки?

Ответить
4

Кнопки - часть мокапов. Про них должна быть инфа, куда она ведёт или просто какой результат даёт
Мобы - зависит от игры. Как минимум нужно выделить категории "Мобы" и "ИИ мобов". В первой перечисляются параметры мобов (скорость, сила, прокачка и т. д.), во втором - логика их поведения/вызова/что у вас там.
Если у каждого моба есть свои скиллы, то в ГДД нужно прописать их логику (типа урон с радиусом Х по Х хп в секунду). Когда кодер получит от аниматора двадцать анимаций с названием mob_death, mob_walk, mob_attack, mob_skill и сравнит их с его описанием, то 90% анимаций он расставит сам. Ещё 9% уточнит у аниматора. И 1 самый хитровыделанный процент будет спрашивать у гд.
Если все анимации расписать в ГДД, результат будет примерно тот же с тем же, если не большим процентом багов.

Ответить
1

Может тоже статью написать? Только более практическую, сразу про ГДД.

Ответить
0

Было бы здорово! Спасибо за рекомендации)

Ответить
0

Только столкнёшься с той же проблемой что и я - сколько гд, столько и мнений.:) + Очень тяжело унифицировать под разные жанры.

Ответить
0

Попробую)))

Ответить
0

Я просто предупредил, я уже пытался написать, в итоге отказался от идеи после первого фидбека, который оказался очень спорным.

Ответить
0

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

Ответить
0

Ну ты это, если шо, обращайся за фидбеком.

Ответить
0

Замётано)

Ответить
0

Да, это делается в отдельной документации.
Например, для каждого персонажа составляется отдельный документ-ТЗ. Описание внешнего вида, характеристики, абилки, анимации и т.д.
Или делается сводная таблица по всем персонажам в excel по такому же принципу.

Ответить
7

Слишком мало котиков

Ответить
5

ИМХО, проблема таких постов (которые пытаются помочь недопустить ошибок) в том, что пока сам эти ошибки не сделаешь - не поймешь, не ощутишь, не разберешься - после чего этот пост становится очевидным и ненужным. Получается действительно сферическая разработка, потому что до начала разработки непонятно как этим вообще пользоваться, а после - уже не нужно. Так и живем.)

Ответить
0

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

Ответить
3

Статья из Вомглы. Даже прослезился немного... кровью. Эдакая ностальгия о сферической разработке в вакууме. Не, ну а чо, плюсанул, конечно.

Ответить
0

Из жизни:

Программист:
Я не буду нихера это делать, потому что.. потому что... да потому что мне нужен диздок! Давай, пиши свой диздок сначала!

Дизайнер:
Концепт, и фанкспек по задаче месяц, как написан. Вот, на.

Программист (через месяц):
Я не буду нихера это делать, потому что... потому что... да потому что мне нужен диздок! Фанкспек - это не то! Мне нужен полный диздок!

Дизайнер:
Да ты хотя бы концепт читал, не говоря о фанкспеке?

Программист:
Ну, я открывал, картинки глянул... но... но... мне нужен фокус! Зачем мне столько текста?! Мне нужен фокус в одном предложении, чтобы я сразу все понял! Иди, пиши фокус!

Ответить
1

Это проблема коммуникаций, если в вашей команде такие проблемы, о которых вы пишете, то зачем вы так работаете? Если не можете договориться друг с другом и выстроить процессы?

Ответить
2

Я лишь рассказал давнюю историю о реальном весе документации, а вы сразу начали искать проблемы коммуникаций в команде.

Дизайнерская лирика, по сути, никому, кроме дизайнера, не нужна. ТЗ - единственное, что имеет хождение в команде. Остальное - пища для прокрастинации.

Ответить
2

Не согласен, документация нужна всем, вопрос как её делать, вести и подавать команде. А то что я у вас увидел, в первую очередь проблемы коммуникаций и не умение донести позицию до человека или его нежелание слушать. При этом, ТЗ на основе чего делать? На что ссылаться, если ТЗ неверно выполнено?

Ответить
2

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

На основе чего делать ТЗ (фанкспек)?
На основе видения проекта его лидером. Будь то геймдиз, продюсер, программист или кто еще. Сам лидер может делать что угодно, писать сколько угодно документации (или не писать ее вообще), чтобы отточить и зафиксировать свое видение.
Диздок, по сути, вещь не для команды, это концепт ответов на все возможные вопросы дизайнера к самому себе.

Ответить
0

Как раз ГДД для команды, именно к нему обращаются при спорных вопросах, но если вы делаете плохой ГДД и не общаетесь с командой чообы она читала ГДД перед реализацией фичи, то это проблема не ГДД. Ещё раз вопрос, какой документ считать эталонным, если возникла спорная ситуация? Ну и да, ГДД - это как инженерная документация.

Ответить
1

О да, легендарный способ сэкономить у некоторых продюсеров: нанять гд для написания ГДД, а потом работать без него) Общение с командой? Не, не слышал.

Ответить
0

Эталонный документ для команды - пачка ТЗ (фанкспек, если в сборе) плюс - тасктрекер.

Общение с командой - вопрос очень риторический.

БОльшей части (экспертам-технарям) глубоко похрен на глобальную идею про "грабим корованы", они занимаются своими задачами, будь то личный челендж кодера, самореализация артиста или плейтестовые метания левелдиза.

Общение с командой происходит на митингах (просто потрындеть или побрейнштормить) или точечно при постановке/редакции/оценке задачи с лидами подразделений или адекватными работниками "в теме".

Диздок может считаться эталонным лишь в одном случае - в момент релиза, если он регулярно правился на всем протяжении разработки.

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

Ответить
0

У тасктрекера есть проблема- он постоянно заполняется и что-то найти, особенно для новчика в команде, будет очень тяжело, как собираетесь дела передавать другому ГД или обучать человека проекту? Кроме того, на основе чего создавать ТЗ? Как удостовериться, что ТЗ написанное в трекере правильное и уитывает многие моенты?

Ответить
1

По-моему, когда уже начались записи в трекере, диздок из инструкции превращается в мемуары.

Ответить
0

А может просто надо кидать ссылку на документацию в задаче, а не описывать документацию в задаче.

Ответить
0

Не знаю. Мне кажется, это тоже способствует прокрастинации. :)
Это как полезешь на Лурк почитать про МПХ, а очнёшься через два часа на какой-то странице про филателистов.

Ответить
0

Да. верно, тасктрекер не есть кладезь знаний. Он просто, в конце концов, оказывается чуть ли не единственным рабочим документом на 90% времени разработки. :)

Ответить
0

И это не нормально. Хороший ГДД, общение с командой и приучение работы с доками занимает время и силы, но в будущем упрощает разработку в разы.

Ответить
1

Дык, я про то, работа с доками - это здорово, но доки для работников - это не дизайн-документ и иже с ними, а набор технической документации от своего лида.

Если же работник возжелает почитать хотя бы дизайнерский концепт - его можно зацеловать до смерти, но требовать такого от каждого - насилие над личностью. :)

Ответить
0

ГДД и есть набор документации, это не один большой документ, это совокупность множества малых документов.

Ответить
0

Ну, тогда папку с артами можно тоже отнести к ГДД. :)

Все же, "если по канону", часть ГДД вообще никоим образом не относится к деятельности геймдиза. Я о технической спецификации, вернее, о множестве спецификаций на разные темы, которые лежат у разных людей в разных местах, потому что, пидоры, не находят времени все залить на сервак. :)

Ответить
1

Имхо такой программист должен быть изгнан на мороз, если он на протяжении месяца не изволил подойти и попросить то, что не хватает ему для разработки.

Ответить
1

Забавно: геймдизайнер пишет сугубо ПМскую статью)

Ответить
0

где она ПМская?0_о Как правило большую часть того, что было упомянуто в статье требуют с ГД.

Ответить
3

Ну из ПМского там деление на майлстоуны и итерации и Канбан. Остальное вполне ГДшное)))

Ответить
0

Если вы пишете о ГДД, это не делает статью автоматически геймдизайнерской.
Представьте себе, ПМов ГДД тоже интересует, но не с позиции написания, а с позиции работы с ней всех членов команды.

Ответить
1

Вот именно, что "упомянуто".
В статье не описаны методики написания ГДД, расчёта баланса, etc.

В статье описаны тезисно все эти вещи, их необходимость и место в разработке.

Это чисто ПМская статья про то, как, что и в какой последовательности организовать)

Ответить
3

Во-первых, в малых клмандах приходится на себя брать дополниетльные роли. Во-вторых, сколькоьигр, столько и методологий баланса, как и методологий наеисания документации. Я пробовал навинать писать статью про документацию и столкнулся с проблемой фрагментации методологий, чем больше ГД - тем больше методов.

Ответить
1

Я не совсем понимаю, с чем конкретно и зачем Вы спорите.
Мой тезис: ваша статья больше пригодится ПМу, чем ГД, поскольку она рассматривает проект в целом, у Вас даже в названии "процессы". ГД в норме не должны заниматься процессами, это прерогатива как раз-таки ПМа.

То, что у Вас ГД имеют ПМ/любую другую кроссфункциональность - нормально, но это никак не меняет того факта, что статья - не про ГД.

Ответить
0

Много запросов в комментах на пример реального диздока. Когда-то наткнулся на отличную хабровкскую статью с примерами:
https://habrahabr.ru/post/302964/
Там же найдёте ссылки, например, на диздок "Ряба" :)

Ответить
2

Только не ряба

Ответить
0

ПОЗДНО! :D

Ответить
0

Хорошая статья. Абстрактно но зато для всего подойдет.
Я очень часто сталкивался и в статьях и в живую, что люди прототип ставят во главу угла - если прототип интересный - значит игра будет, а если нет - то нет.
Но как может быть интересным прототип - Destiny, MGS5, COD и тп. ? Они такие потому что там куча механик и они отполировано до играбельного вида.

Ответить
1

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

Ответить
0

Да, без условно. Я про то что прототип может не быть интересным для игры. А для выявления проблем и разных тестов - самое то

Ответить
0

Если на кубиках играется интересно, то при визуале тем более.

Ответить
0

Прототип Овервотча кажется состоял из одной карты без текстур и двенадцати Трейсер. Тоже без текстур и анимаций.

Ответить

Комментарий удален

Комментарий удален

0

" У большинства маленьких молодых команд одни и те же проблемы. "
Почему-то мне кажется что статья не для начинающих, мне кажется проблемы другие, в духе: Очень маленький бюджет или полное его отсутствие, что чаще.
И статья не поможет решить такие проблемы, имхо только навредит..

Опять же, почему нет примеров..? Я года 3 назад что такое диз. док. знать не знал и в глаза не видел и никто его не показывал :)

Ответить
0

Примеры кидать сложно, т.к. жанров много. Кроме того, каждый ГД пишет документацию под себя и команду.

Ответить
0

Отличный материал) Я бы ещё добавил про MVP и умение разделять базовый функционал и финтифлюшки.

Ответить
0

Прочитал статью только из-за котиков

Ответить

Комментарий удален

Комментарий удален

0

Отличная статья, буду рекомендовать.

По софту рекомендую обратить внимание на HacknPlan - совмещает таски (доски, карточки, чеклисты), итерации и ГДД в одну взаимосвязанную структуру, заточен под геймдев.

Ответить

Комментарий удален

–3

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

Ответить

Комментарий удален

Комментарий удален

0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]
EA анонсировала DLC для DLC
для аддона для спин-оффа
Подписаться на push-уведомления