Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Продуктовая документация в гейм-дизайне, лекция 1

Anatoly Shestov
January 14, 2019

Продуктовая документация в гейм-дизайне, лекция 1

Содержание:
- Знакомство.
- Зачем нужны гейм-дизайнеры?
- В чем отличие дизайн-документации от любых других доков?
- Три главных вопроса к любому пункту любого дизайн-решения.
- Домашнее задание.

Anatoly Shestov

January 14, 2019
Tweet

More Decks by Anatoly Shestov

Other Decks in Design

Transcript

  1. Продуктовая документация
    в гейм-дизайне
    Вводная лекция

    View full-size slide

  2. Содержание курса
    Вводная лекция
    Общий обзор продуктовой документации
    Документация для менеджмента и отделов поддержки: продюсера, пма, CM и саппортов
    Документация для команды разработки: программистов, UI, арта, QA
    Зачет
    2

    View full-size slide

  3. О лекторе
    Анатолий Шестов
    В геймдеве с 2011 года
    Работал в компаниях DaSuppa Studios, 2RealLife, Plarium, Nival, Yarr Games, Pixonic
    Пришел в геймдев из настольных ролевых игр
    Ведет блог aushestov.ru
    3

    View full-size slide

  4. Вводная лекция
    Знакомство.
    Зачем нужны гейм-дизайнеры?
    В чем отличие дизайн-документации от любых других доков?
    Три главных вопроса к любому пункту любого дизайн-решения.
    Домашнее задание.
    4

    View full-size slide

  5. Знакомство
    Во что играете?
    Что делали своими руками?
    Зачем здесь, на этом курсе?
    5

    View full-size slide

  6. Зачем нужны гейм-дизайнеры?
    Хард-скиллз
    Софт-скиллз
    Экспертиза
    6

    View full-size slide

  7. Хард-скиллз
    Хард-скиллз - навыки, требующие предварительного изучения, которые нужно напрямую использовать в
    работе. Пример: рисование, программирование, вождение.
    Обязательные:
    Арифметика и пользование экселем или гугло-таблицами.
    Необязательные:
    Психология, экономика, сценарное дело, режиссура, профильные для конкретного проекта темы.
    7

    View full-size slide

  8. Навыки и знания, позволяющие что-то делать определенным образом.
    Три блока:
    Как мы работаем в коллективе. Взаимодействие с командой, аргументация, презентация своих идей,
    стрессоустойчивость.
    Как мы работаем с игроком. Понимание восприятия, реакций, “потока”, “интересного”.
    Как мы работаем с продуктом. Системное мышление.
    Софт-скиллз
    8

    View full-size slide

  9. Любой может наиграть 10000+ часов. Не любой может сделать это с любовью и вниманием.
    Любой может поиграть в несколько похожих проектов. Не любой может в течении долгого времени
    систематически изучать все проекты конкретных жанров и платформ.
    Любой может посмотреть на проект здесь и сейчас. Не любой может следить за проектом последние
    несколько лет и разбираться во влиянии каждого отдельного патча.
    Любой может предложить что-то интересное. Не любой может найти десяток вариантов реализации
    предложенного и разобрать каждый на плюсы и минусы.
    Экспертиза
    9

    View full-size slide

  10. А что в сумме?
    Гейм-дизайнер - это не набор навыков, а отрасль знаний и зона ответственности за то, чтобы игроку было
    “интересно”. Или “понятно”. Или “хотелось платить”. Т.е. за вызов конкретных ощущений.
    Соответственно, гейм-дизайн документация - это описание достижения вот этих самых конкретных
    ощущений в каждом отдельном случае.
    10

    View full-size slide

  11. Какая бывает документация?
    Концепт. Предложение, главная задача которого - убедить делать именно это или именно так.
    ГДД. Развернутое описание, задача которого - дать максимально полное представление о предложении
    тем, кто его будет реализовывать. Главная задача - проверить на совместимость с уже реализованными \
    запланированными элементами и получить точные оценки по реализации.
    ТЗ. Инструкция к реализации, пользуясь которой конкретный исполнитель по максимуму освобожден от
    необходимости включать голову. Главная задача - свести к минимуму дополнительные издержки на
    обсуждение, уточнение, согласование.
    11

    View full-size slide

  12. Концепт элемента геймплея. Примеры: криты, стелс, перезарядка.
    Концепт элемента меты. Примеры: квесты, пассивный геймплей, лутбоксы.
    Концепт арта. Примеры: скины, карты, персонажи.
    Концепт системы. Примеры: игровой режим, крафт, мини-игры, новая игра.
    Какие бывают концепты?
    12

    View full-size slide

  13. Требования к концепту на геймплей
    Юзерсайд. Как игрок узнает о новой опции, поймет ее принцип работы, поймет эффективность, поймет
    контр-плей.
    Референсы. Как эта опция реализована в конкурирующих продуктах?
    Универсальность. Как эту опцию используют разные категории игроков?
    13

    View full-size slide

  14. Категории игроков
    1. По степени знакомства с жанром.
    2. По степени знакомства с платформой.
    3. По степени знакомства с вашим проектом.
    4. По интенсивности игры.
    5. По интенсивности социализации.
    6. По платежной истории.
    ВАЖНО: Какие именно категории игроков учитывать, сильно зависит от конкретного предложения.
    14

    View full-size slide

  15. Требования к концепту на мету
    Юзерсайд. Как игрок узнает о новом элементе, как поймет эффективный способ с ним взаимодействовать.
    Флоу. В какой момент игрок будет отвлекаться от кор-геймплея на этот элемент, почему это понравится
    игроку и не повредит остальному проекту?
    Системность. Благодаря чему этот элемент будет выделяться в восприятии игрока во что-то самобытное?
    Как этот элемент будет перекликаться с привычными игроку способами взаимодействия с продуктом?
    Универсальность. Как эту опцию используют разные категории игроков?
    15

    View full-size slide

  16. Требования к концепту на арт
    НЕ НУЖНО ГОВОРИТЬ ХУДОЖНИКАМ, ЧТО ИМЕННО РИСОВАТЬ.
    Нужно говорить:
    ● Какие ощущения и ассоциации должен вызывать этот арт?
    ● Вместе с какими другими элементами этот арт должен сосуществовать?
    ● Примеры достижения тех же ассоциаций и ощущений из конкурирующих продуктов?
    16

    View full-size slide

  17. Требования к концепту системы
    Система - это совокупность взаимодействия элементов. Из концепта системы должны быть понятны
    каждый отдельный элемент и то, как эти элементы работают друг с другом. Донести это помогут:
    Юзер-стори
    Cхемы
    Алгоритмы
    17

    View full-size slide

  18. Пример юзерстори 1
    В игре появляется персонаж с новой способностью «невидимость». Я узнаю об этом из хинтов, патч-ноутов,
    медиа-материалов и обсуждений в группах проекта в соцсетях.
    Первое время персонаж доступен только в отдельном игровом режиме и для ограниченной аудитории,
    увеличивающейся на 5% раз в полчаса. Я мотивирован отправиться в этот режим с помощью отдельного
    квеста с хорошей наградой.
    18

    View full-size slide

  19. Пример юзерстори 2
    К тому моменту, как способность становится доступна, я знаю, как она выглядит для меня (эффект
    включения, специальный шейдер, эффект выключения), как использовать эту способность эффективно
    (снимать агр с себя, обманывать одиночных оппонентов, близко подбираться к незащищенным целям) и что
    против меня будут предпринимать оппоненты (мерцание при попадании в невидимую цель — чтобы
    «запеленговать» невидимку; первые 0.5 секунды после выхода нет дамага и можно успеть навести прицел,
    прожать абилку или сместиться к укрытию).
    В самой игре я сразу понимаю, что у меня персонаж с невидимостью и не перепутаю ее с другой
    способностью благодаря однозначно понятной иконке. В каждом матче я вижу минимум несколько игроков с
    этой способностью.
    19

    View full-size slide

  20. Пример юзерстори 3
    В первом таком бое меня несколько раз убивает невидимка, и после этого боя я получаю оффер на покупку.
    Возвращаясь в главный экран, я вижу, на кнопке магазина индикатор того, что в магазине появилось что-то
    новое. Открыв магазин, я сразу попадаю на нового персонажа с невидимостью — я узнаю его по яркой иконке,
    которую уже видел. Я читаю описание персонажа, смотрю на ТТХ абилки и начинаю прикидывать, на сколько
    она «тащунская».
    Я возвращаюсь в бой, чтобы выполнить квесты на «невидимке» и вижу, как персонаж-невидимка берет топ-1
    по всем показателям. Мне опять предлагают оффер. Я задумываюсь над покупкой, решаю обсудить это с
    командой.
    20

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. Пример алгоритма
    Алгоритм - последовательность логических операций.
    На следующих слайдах - кусок алгоритма, описывающий взаимодействие игрока с экранами и
    интерфейсами в проекте Core Tactics (полный вариант можно посмотреть здесь) и кусок алгоритма,
    создающего оффер под конкретного игрока.
    25

    View full-size slide

  24. Разница между схемой и алгоритмом
    Главная разница - в степени детализации. В схеме вы просто показываете связь каких-либо элементов. Это
    могут быть не все элементы, а только часть. Элементы могут быть разного масштаба. Связи могут быть
    разного характера. В алгоритме вы описываете все логические операции и связи этих элементов.
    Второстепенная - в форме. Схема всегда визуализирована. Алгоритм может быть описан и простым
    текстом.
    Алгоритм - это то, во что будут превращать ваши хотелки программисты. Важно понимать, что именно от
    вас требуется - схема или алгоритм.
    28

    View full-size slide

  25. Какие бывают ТЗ?
    ТЗ - это сокращение от “техническое задание”. Чаще всег гейм-дизайнер имеет дело со следующими
    типами ТЗ:
    На код
    На арт
    На UI\UX
    На тестирование
    29

    View full-size slide

  26. ТЗ на код
    Тех.задание на код чаще всего составляется лидом технической команды, но в некоторых случаях это
    делает и гейм-дизайнер. Примеры тз на код:
    1. Добавить в админку параметр Х.
    2. Добавить импорт\экспорт из таблицы.
    3. Добавить дополнительную проверку … для определения читеров.
    4. Добавить ивент для трекининга новых событий в аналитике.
    Ключевая разница между ГДД и техзаданием в том, что гдд аргументированно рассказывает о результате,
    который должен получится (и может включать в себя несколько ТЗ), а техзадание говорит о том, какую
    конкретно работу нужно проделать.
    30

    View full-size slide

  27. ТЗ на арт
    Тех.задание на арт чаще всего составляется арт-лидом, но в некоторых случаях это делает и гейм-
    дизайнер. Примеры тз на арт:
    1. Новый персонаж.
    2. Новый скин.
    3. Новый сплеш-скрин.
    4. Пачка иконок.
    Ключевое отличие между концептом и тз на арт в том, что тз должен содержать все конкретные
    технические требования: размеры\полигонаж, перечень мест использования, типом использования,
    состояний.
    32

    View full-size slide

  28. ТЗ на UI\UX
    ТЗ на UI\UX чаще всего составляется лидом UI\UX команды, но в некоторых случаях это делает и гейм-
    дизайнер. Примеры тз на UI\UX:
    1. Добавить дополнительную точку входа в окно Х.
    2. Добавить вывод еще одного параметра в интерфейс У.
    3. Добавить новое состояние для кнопки абилки в боевом интерфейсе.
    Ключевая разница в том, что при работе с ГДД UI\UX работает с системой (проектирует ее с нуля или
    меняет имеющуюся), а при работе с ТЗ этот специалист просто реализует нужно изменения.
    34

    View full-size slide

  29. ТЗ на тестирование
    ТЗ на тестирование чаще всего составляется самими QA-специалистами, но время от времени к этому
    процессу подключаются и все остальные участники разработки. Примеры тз на тестирование:
    1. Проверить, как будет менять дпс при понижении фпс.
    2. Есть подозрение на баг в случае вот такой цепочки действий (WTR, way to reproduce)
    3. Есть древний функционал, который непонятно как будет взаимодействовать с новым. Нужно
    проверить.
    Ключевая разница в том, что при работе с ГДД QA-специалисты сам составляет список моментов, которые
    нужно проверить, а при работе с ТЗ он проверяет какой-то отдельный конкретный случай.
    36

    View full-size slide

  30. В чем же принципиальная разница?
    Ни в чем. Каждый принятый в работу ГДД превращается в набор ТЗ на всех участвующих в разработке
    специалистов.
    38

    View full-size slide

  31. Три главных вопроса
    Зачем?
    Почему?
    Ты уверен?
    39

    View full-size slide

  32. Главный вопрос “Зачем?”
    Если вы приходите со своим предложением, то этот вопрос вам зададут первым. Если вы получаете
    задачу, без ответа на этот вопрос не уходите.
    Суть вопроса: “Какой цели вы хотите достичь?”
    Вопрос со звездочкой: “Этой цели действительно нужно достигать?”
    40

    View full-size slide

  33. Некорректные ответы на вопрос “Зачем?”
    Игроки хотят
    У проекта А это есть
    Продюсер сказал сделать
    У нас человек простаивает, надо же хоть чем-то занять
    41

    View full-size slide

  34. Корректные ответы на вопрос “Зачем?”
    У нас есть заметный отвал на этом этапе туториальной воронки
    Этот элемент входит в программу минимум ожиданий от жанра
    Тепловые карты показывают, что в стычках на боковом проходе в большинстве случаев побеждают синие
    Популярность сборки Х заметно ниже, чем у остальных стартовых вариантов
    У игроков нет понятной и достижимой цели на этапе “3-5 дни”
    42

    View full-size slide

  35. Что общего у всех “корректных” ответов?
    Они валидируются цифрой. Аналитикой, маркетингом, статистикой.
    43

    View full-size slide

  36. Главный вопрос “Почему?”
    Если с целью вашего предложения все согласны, то следующий логический шаг - обсудить конкретный
    способ, которым вы предлагаете достичь этой цели.
    Суть вопроса: “Почему ты хочешь делать именно это и именно так?”
    Вопрос со звездочкой: “Какие еще варианты достижения цели ты рассмотрел?”
    44

    View full-size slide

  37. Некорректные ответы на вопрос “Почему?”
    Это же круто!
    А почему бы и нет?
    Мы обсудили и никто не возражал…
    Других вариантов не придумалось...
    45

    View full-size slide

  38. Корректные ответы на вопрос “Почему?”
    Из всех вариантов по оценкам команды этот оказался самым дешевым
    Технические риски минимальны, так как это идет на рельсах уже имеющегося функционала
    Среди долгосрочных целей проекта есть Х, а это - логичный шаг первой итерации в этом направлении
    По данным КМов среди всех запросов игроков просьба именно о таком функционале встречается в ХХ%
    Решение - трендовое, в большей части конкурирующих продуктов используется именно такая реализация
    46

    View full-size slide

  39. Что общего у всех “корректных” ответов?
    Они понятным образом говорят “если сделать так - то будет быстрее\дешевле\эффективнее\безопаснее”.
    47

    View full-size slide

  40. Главный вопрос “Ты уверен?”
    Если есть принципиальное согласие делать Х, и делать именно предложенным образом,
    бюрократический механизм продакшена начинает раскручиваться. Задачи поступают рядовым
    исполнителям. Тем людям, которые хотят не просто ходить на работу и делать задачи, но - делать “круто”.
    Суть вопроса: “Что станет лучше?”
    Вопрос со звездочкой: “Как мы поймем, что стало лучше именно благодаря этой фиче?”
    48

    View full-size slide

  41. Некорректные ответы на вопрос “Ты уверен?”
    Я так уже делал на другом проекте
    Да мы уже все порешали, чего ты возбухаешь?
    Ну, хз, что-то ведь все равно нужно…
    Давай как-нибудь потом обсудим?
    49

    View full-size slide

  42. Корректные ответы на вопрос “Ты уверен?”
    Вот интерактивный интерфейс, посмотри сам...
    Вот расчеты - видишь, у игрока вот здесь станет больше Х, и он сможет еще и У делать
    Мы уже собрали прототип, давай включу и сам посмотришь?
    Хм, а вот это мы не учли… Постараемся в следующей итерации сделать.
    50

    View full-size slide

  43. Что общего у всех “корректных” ответов?
    Они дают команде ощущение того, что вы все продумали, взвесили и выбранный вариант действительно
    тащит.
    51

    View full-size slide

  44. О чем мы не говорили (и не будем)
    В разработке используется огромное количество документации, с которой гейм-дизайнер не сталкивается
    практически никогда. К примеру:
    ● Арт-библия
    ● Регламент оформления кода
    ● Пайп-лайн автоматической сборки билдов
    Знать о них и быть в курсе их содержания полезно прежде всего для личного развития и
    взаимопонимания, но непосредственно к работе это отношения имеет мало.
    52

    View full-size slide

  45. Домашнее задание
    1. Поделиться на команды по принципу “все в команде имеют +- серьезный опыт игры в игру Х”. Для
    желающих хардкора - выбрать новую игру. Хоть мобильные платформы, хоть ПК.
    2. Обменяться контактными данными.
    3. Определить себя как игрока по приведенной в лекции классификации.
    4. Совместно выделить в выбранной игре 1 (ОДНО) главное ощущение, которым эта игра ценна.
    5. Отправить мне на почту [email protected] ссылку на гуглодок со списком участников команды,
    названием выбранной игры и описанием этого главного ощущения.
    6. Задание со звездочкой: Обратить внимание во время обсуждения на то, если какие-то общие черты
    у предложений от игроков одной категории.
    Срок - до дд.мм.гг
    53

    View full-size slide