Советы новичкам от опытного гейм-дизайнера
Прежде, чем начать рассказывать правила составления ГДД, давайте определимся, кто же такой гейм-дизайнер и какова его роль в команде. Ближайший аналог гейм-дизайнера в искусстве — это режиссёр. Он не играет в фильме, не занимается светом и декорациями и даже не держит камеру — но при этом именно он решает, как должен выглядеть фильм, чтобы он доносил зрителю те ощущения, которые хочет режиссёр. Также и гейм-дизайнер очень часто не умеет рисовать и программировать, но обязан уметь вызывать у игрока нужные ощущения.
Поэтому его можно назвать мозгом команды, тем, кто всегда контролирует то, что делают все остальные. Даёт задания и принимает работу. Поэтому главное умение гд — находить общий язык со всеми в команде и делать так, чтобы они производили именно то, что есть в его голове. Поэтому в идеале нужно, чтобы каждый проект вёл один хороший специалист. О том, насколько трудно такого найти — это уже совсем другая тема. Просто давайте держать в голове, что эта статья — про хорошего гд или того, кто хочет им стать.
Вы, наверное, заметили, что среди обязанностей гейм-дизайнера я не упомянул ГДД. Потому что в идеальном сферическом мире он не нужен. Там гд всегда держит в голове описания всех фичей, никогда не болеет, не увольняется и ему не нужно ни перед кем отчитываться. Гейм-дизайнерский документ игры — это вспомогательный документ. Страховка студии от пропажи гд, напоминалка гд о том, что он хотел сделать, ведь разработка может подчас растягиваться во времени по не зависящим от него причинам, и напоминалка для специалистов о том, что они должны сделать, если вдруг отвлеклись.
Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее — ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним(которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жестко — с высокой вероятностью угробить собственную компанию. Некоторые, желая сэкономить, нанимают гд только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Марвел уволили гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.
Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.
Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде матч-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или, например, контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру. Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.
Оглавление
В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном. В мой первый месяц работы у меня случился факап: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем(художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.
Вступление
Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.
Базовый геймплей
Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в матч-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а матч-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно матч-3. Для Wolfenstein это прежде всего ходьба и стрельба. В этот раздел стоит включить и управление базовым геймплеем. Смотреть мышкой, ходить вперёд-назад-влево-вправо, стрелять на лкм, на три кнопки забиндить скиллы, а ещё одна — ульта, при попадании по персонажу у него отнимаются жизни, потом респ и т. д.
На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.
Важно не описать всё красиво, а описать всё точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. “Не ошибается тот, кто ничего не делает” — отличная фраза для такой ситуации, потому что нереально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.
В первые три-четыре года работы гд и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом “Норм?”. Это значительно повышает их качество и снижает время, потраченное на разбирательства.
На минутку вернувшись к теме хорошего гд, могу сказать, что он ежесекундно должен ставить себя на место других людей и задавать себе вопросы: “Что мне понятно из этого экрана?” “Что будет понятно обычному геймеру?” “Куда бы я нажал, если б открыл это меню в первый раз?” “Как может человек интерпретировать эту иконку?” и ещё около миллиарда таких же. Главный же вопрос гейм-дизайнера (если уходить в дебри) это “Почему?”. От “Почему PUBG такой популярный?” до “Почему эта фича, которую я придумал, будет востребованной?”.
HUD или интерфейс базовой игры
Head-up display — вся информация, которую видит человек, играя в шутер от первого лица. Здоровье, патроны, маркеры на экране и т. д. В других жанрах его аналог можно называть по-разному, но в любом случае это то, что видит игрок во время базового геймплея. Это одна из самых важных вещей в игре — игрок должен понимать то, во что играет, но при этом оно не должно отвлекать его от геймплея.
На самом деле искусство создания хорошего HUDа — это огромная наука, специалистов в которой очень мало. Лучше всего составлять его совместно с арт лидом и быть готовым, что переделывать его наверняка придётся.
Интерфейсы и главное меню
Этот раздел статьи я хочу начать с рассказа о том, что такое мокап. Или варфрейм. В индустрии очень часто одни и те же сущности в разных студиях называются по-разному и если у вас что-то из того, что я называю в статье, называли по-другому — это проблема отсутствия единого профессионального словаря. Итак, это — схематичный набросок, сделанный в графическом редакторе человеком, максимально далёким от рисования. Здесь не стоит задача “сделать красиво”, здесь стоит задача “сделать понятно”. Чтобы художник без лишних вопросов гармонично расставил кнопки и всё остальное.
Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё что угодно. Хоть карандашом на бумаге рисовать и фоткать. Вместо картинок — прямоугольники, кружочки, стрелки — короче, минимализм.
Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.
Дальше идут мокапы всех окон, начиная с главного меню, и заканчивая самым маленьким окошком с кнопкой “Ок”. Не забывайте про то, как из них выходить! Под каждым мокапом должно быть краткое и понятное описание каждой кнопки и другого элемента окна и что они делают. Лайфхак для сложных экранов: возле каждого элемента поставить кружок с числом, а снизу пронумерованные пункты.
Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.
Остальные фичи
Дальше мы просто бьём проект на мелкие составляющие и описываем каждый в своём разделе. Туториал, инвентарь, диалоги, глобальная карта, прокачка — всё, что у вас есть. Описывается всё так же, как и базовый геймплей. К каждой из фич в раздел стоит запихнуть мокап того, что с ней связано.
Функциональные разделы
В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.
Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.
Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.
Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.
Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.
Чего НЕ должно быть в ГДД?
Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: ”Пушка стреляет”. Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.
Референсов. Картинки делают файлы неподъёмно большими, а те в свою очередь уменьшают их размер, поэтому их лучше заливать в папку на дропбокс, свн или гугл диск. Отдельную папку для каждой сущности, естественно. Видео лучше заливать на ютуб и давать прямые ссылки.
Текстов. Выделите под них отдельный файл, желательно xml, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.
Литературных описаний — никто не оценит.
А что дальше?
После того, как вы написали все ТЗ и лид программистов уверенно сказал “Норм” вы переходите на главную часть работы гд — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.
Не забывайте, что всё, описанное в этой статье — не нормативы (хотя если вы заберёте их себе и сделаете нормативами — я против не буду), а результат моей многолетней работы на позиции гд. Никто не мешает вам сделать лучше.
Источник: DTF
