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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23

24

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

26

27

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

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

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

31

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

33

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

35

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

37

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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