Советы новичкам от опытного геймдизайнера
Прежде, чем начать рассказывать правила составления ГДД, давайте определимся, кто же такой геймдизайнер и какова его роль в команде. Ближайший аналог геймдизайнера в искусстве — это режиссёр. Он не играет в фильме, не занимается светом и декорациями и даже не держит камеру, но при этом именно он решает, как должен выглядеть фильм, чтобы он доносил зрителю те ощущения, которые хочет режиссёр. Также и геймдизайнер очень часто не умеет рисовать и программировать, но обязан уметь вызывать у игрока нужные ощущения.
Поэтому его можно назвать мозгом команды, тем, кто всегда контролирует то, что делают все остальные. Даёт задания и принимает работу. Поэтому главное умение геймдизайнера — находить общий язык со всеми в команде и делать так, чтобы они производили именно то, что есть в его голове. Поэтому в идеале нужно, чтобы каждый проект вёл один хороший специалист. О том, насколько трудно такого найти — это уже совсем другая тема. Просто давайте держать в голове, что эта статья — про хорошего геймдизайнера или того, кто хочет им стать.
Вы, наверное, заметили, что среди обязанностей геймдизайнера я не упомянул ГДД. Потому что в идеальном сферическом мире он не нужен. Там геймдизайнер всегда держит в голове описания всех фич, никогда не болеет, не увольняется и ему не нужно ни перед кем отчитываться. Геймдизайнерский документ игры — это вспомогательный документ. Страховка студии от пропажи геймдизайнера, памятка о том, что он хотел сделать, ведь разработка может подчас растягиваться во времени по не зависящим от него причинам, и памятка для специалистов о том, что они должны сделать, если вдруг отвлеклись.
Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.
Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.
Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.
Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.
Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.
Оглавление
В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном.
В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.
Вступление
Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.
Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…
Техуманитарный диздок
Однако что такое «диздок»? – может спросить читатель. В двух словах – это написанная «на бумаге» игра. К такому документу обращаются за информацией все участники команды разработчиков. Тут можно найти описание геймплейных механик, математические модели баланса, разветвлённый сюжет игры, указания музыканту, список звуков и визуальных эффектов… По крайней мере этому нас учат «классические» примеры диздоков. Самым известным из них в России является, конечно, документ «Месть курочки Рябы» из далёкого 2004-го года. А вот ещё один экземпляр заготовки диздока, намедни попавший мне на глаза на Reddit’е.
Как видите, структура у них крайне похожа – документ предназначен одновременно для всех и ни для кого. Он написан «техуманитарным» языком, который уже теряет смысл для программиста, но ещё недостаточно понятен для художника. К тому же колоссальный размер диздока ведёт за собой сложность навигации, чтения, поддержания текста в чистом и актуальном состоянии. Вам, должно быть, знаком термин «информационный шум»; участники команды будут сражаться именно с этой проблемой в поисках нужной информации. Если гранд-мастер гейм-дизайна 90-го уровня и сможет управляться с возникающими сложностями, то подумайте о новичках, какой диздок напишут они?
На этой сногсшибательной ноте я хотел бы предложить альтернативный вариант диздока, основанный на гранулировании документации, – она делится на небольшие, чёткие задания так, что исполнитель не тратит время на поиск и фильтрацию информации, но может тут же приступать к работе. Кто-то крикнет из зала, что обособленность задачи является минусом. И будет отчасти прав, ведь исполнитель не видит общей картины и работает на своём огороженном участке. Именно тут получает шанс блеснуть золотым, отполированным до блеска разумом Его Управленчество руководитель проекта.
Он способен донести до команды текущее состояние проекта, рассказать как о возникших сложностях, так и об успехах, которых добились разработчики. В его рукаве спрятано множество инструментов. Одним из них может быть «аджайл», но об этом я расскажу чуть позже. Там же, – чуть позже, – будут ссылки на мой вариант проектной документации.
Зима, случайно попавшая в тренд
Много месяцев назад мне посчастливилось наткнуться на тёплую ламповую «adarkroom». Поиграв до утра и опоздав на работу, я вдохновился. Простые игровые механики и полное отсутствие графики послужили катализатором для воображения, раскрывшегося феерией красок в голове. Так родилась идея проекта «Survive the Winter», игры с простыми игровыми механиками и наличием графики. Ряд обстоятельств, правда, не позволил начать полноценную разработку, и идея была заброшена в комод.
За одним прекрасным обеденным перерывом я наткнулся на заданный на форуме вопрос. Неопытный разработчик попросил пример диздока, хотел разобраться, как проектировать игру. Ответы завсегдатаев состояли в основном из скудных попыток троллинга и ссылок на «Месть курочки Рябы». В тот день зародилась Идея. «Survive the Winter» – это фиктивная мобильная игра; она как бы есть, но её нет. Я решил воспользоваться старым концептом, и на его основе создать открытую документацию по созданию игры с нуля. «Ворох файлов в Google Docs, ряд макетов интерфейсов, а также щедрая россыпь тасков и технических заданий в Trello могут стать наглядным примером как для совсем зелёных новичков, так и для девелоперов с опытом», – вычурно подумал я, приступая к работе.
Являясь духовным наследником игры «adarkroom», «Survive the Winter» является вариацией «кликера». Последнее время этот жанр набирает всё большую популярность. Коллеги в интернет-издании «Цукерберг Позвонит» написали статью с анализом текущего состояния, а также возможных перспектив «кликеров».
Геймплей фиктивной игры
«Survive the Winter» основывается на менеджменте четырёх ресурсов: еды и дров на складе, сытости и тепла. Соответственно, от игрока требуется вовремя ходить на охоту, запасаться хворостом, кушать и разводить костёр. Временами происходят «события». Появляется окошко с текстом: «Среди зарослей орешника вы приметили затаившегося кролика. Привычным жестом вы натягиваете тетиву. Выстрелить?». После чего пользователь решает, как поступить. Например, ответив положительно, получает сообщение: «Предназначенная для охоты на оленя стрела насквозь пробивает крошечное тельце зверька и с треском врезается в сухую корягу», вместе с тем герой получает +5 единиц мяса. Эти «события» могут иметь самые разные последствия, начиная с получения дополнительного мяса и заканчивая травмой героя (дебафф, усложняющий игру). Они же постепенно раскрывают сюжет игры.
На первый взгляд может показаться, что проект маленький и несложный в разработке, даже если запланировать высокий production value (то есть исключительное качество продукта). Но так ли это? Разработчики часто недооценивают количество работы, идущее в небольшой по их меркам проект. Я считаю, что игра размера «Survive the Winter» является отличным способом достичь моей цели – показать людям ещё альтернативный пример диздока.
Большая документация маленького проекта
Откровенно говоря, я сам не ожидал, что документация разрастётся настолько широко. Посмотрите на полный список задач в Trello. Заметьте, там доступен горизонтальный скроллинг, открывающий новые столбцы. Отмечу, что уже был проведён препродакшн, то есть предварительная работа, поиск информации, исследования. Это избавляет нас от большей части задач по проектированию и гейм-дизайну. Теперь основной объём работы лежит на плечах программистов. Если бы задачи из подготовительного этапа остались на доске, то размер её был бы в полтора раза больше.
Документация ведётся с использованием двух сервисов: Google Docs + Spreadsheets и Trello. В Google Docs хранятся общие документы, такие как описание проекта или список фич. Там же спрятаны технические задания, на которые ссылаются карточки из Trello. Сам Trello используется как «бэклог», то есть склад всех доступных для работы задач. Пробежав глазами по Trello, любой специалист может наглядно увидеть проект целиком, визуально оценить прогресс команды, но в первую очередь такое отображение удобно для менеджера. Менеджером, замечу, может быть как продюсер, так и программист или любой другой ответственный специалист, если размер команды невелик.
Если вы работаете по гибким методологиям, то под «спринты» стоит создать отдельную доску, и в неё переносить задачи из «бэклога». Как следствие, можно будет наглядно оценить как общее состояние проекта, так и состояние текущего «спринта». Если объём работы для вашего проект заметно больше, чем для «Survive the Winter», то общая доска-«бэклог» может превратиться в помеху: все задачи не поместятся, вы начнёте в них путаться. Придётся поднять сервис таск-трекинга по типа Jira или Redmine. Тем не менее, для большинства инди-разработчиков Trello должен подходить идеально. В противном случае рекомендую внимательнее изучить размер проекта, вероятно, он слишком большой?
Спринт, аджайл, бэклог и другие сложные слова
На всякий случай расскажу чуть-чуть про «спринты» и «аджайл» для тех, кто ещё не познакомился с этим веянием в методологиях разработки программного обеспечения. Под «спринтом» подразумевается небольшой отрезок времени, как правило длиной в одну или две недели. В начале «спринта» команда проводит встречу и решает, какие задачи будут точно выполнены за выделенное время. Ключевая цель при выборе задач – это получить конкретный работающий функционал к концу «спринта». Соответственно, во время заключительной встречи команде демонстрируется рабочее демо, на этом «спринт» считается завершенным.
«Спринт» является также прекрасным инструментом по поддержанию мотивации, ведь люди трудятся вместе ради достижения общей цели, – рабочего функционала в демо, – подбадривая друг друга, и к концу выделенного отрезка времени они получают осязаемый результат, что всегда приятно. Более того, даже если над игрой трудится один разработчик, «спринты» всё равно являются отличным мотиватором: разработчик не «пилит» какой-то абстрактный код, а реализует конкретную игровую фичу, которую можно будет пощупать непосредственно в «билде» игры. «Билд» же, в свою очередь, можно дать потискать друзьям и знакомым.
Структура основной доски Trello удобна для общего управления проектом, но не подходит для «спринтов». Есть смысл выбранные для очередного «спринта» задачи брать из доски-«бэклога», который можно сравнить с большим мешком с подарками, и переносить эти задачи в новую, отдельную доску, рассчитанную на один «спринт».
Тут же хочу заметить (и посыпать голову пеплом), что документация «Survive the Winter» в текущем её исполнении напоминает водопадную модель. Эта методология отличается тем, что заранее готовятся все задачи, после чего передаются исполнителям. Проект движется по предварительно выложенным рельсам, он становится негибким, любые изменения вносить сложно, – они буквально крошат его жесткую структуру, грозя массивными разрушениями, срывами сроков и выходом за рамки бюджета. Мне пришлось создать именно такую общую доску с задачами, спроектированными заранее и с особой тщательностью, чтобы наглядно показать разработчикам документацию целиком, как бы с высоты птичьего полёта.
Распределённый диздок
На доске-«бэклоге» карточки сгруппированы по смыслу и разложены по приоритету, чтобы самые важные были всегда на виду. Можно пойти ещё дальше и сгруппировать задачи по фичам. Иными словами, чтобы иметь фичу «событие» (помните, я рассказывал про бедного кролика, насквозь пробитого стрелой?), надо реализовать для неё всплывающее окошко, брать откуда-то текст, дать кнопки выбора варианта ответа на «событие», и так далее. То есть каждой отдельной фиче принадлежат несколько задач. Таким образом специалист сможет видеть, какая задача связана с какой, и какой общей целью они объединены. Поэтому важно создать несколько особых документов, отражающих каждую сферу проекта, то есть: программирование, графика, гейм-дизайн, звук и другие. Получается тесная интеграция с принципами гибких методологий разработки. Каждая фича представляет из себя спроектированный «на бумаге» функционал. В то же время каждый спринт стремится создать демо, в котором реализован цельный работающий функционал. В итоге всё служит достижению общей цели.
Тернистый путь проектировщика
Вы наверняка уже успели пощёлкать по задачам в Trello. В каждой вы видите выжимку информации, рассчитанную на конкретного специалиста. Если это программист, он получает больше технических описаний, если художник – больше описаний ощущений («от игры должно веять холодом!»). Создавая технические задания для разных специалистов, нужно стремиться понимать тип их мышления, знать, что для них важно, а что – пустые слова. Это следует всегда держать в голове. Документы надо создавать с высокой детализацией, чтобы специалист не тратил время, додумывая и заполняя пробелы за проектировщиком. В лучшем случае это ведет к фрустрации, в худшем окажется, что часть работы потом придётся переделывать.
Проектирование игры требует массу времени; важно не попасть в ловушку, считая, что составление задач и техзаданий – быстрый процесс, которым можно заниматься как бы между делом. При создании технических заданий для команды приходится глубоко анализировать игру, затем разбивать её на крошечные кусочки, давая им чёткое и однозначное описание, чтобы работать по такой задаче исполнителю было комфортно. Это долго. Занимаясь этим в свободное от работы время и в выходные, мне пришлось потратить около двух месяцев на «Survive the Winter».
Не меньше времени уходит на поиск информации. Многие задачи требуют предварительной подготовки, проведения исследований, фильтрования информационного шума. Например, при создании кроссплатформенной мобильной игры, описывая для художника техническое задание по рисованию иконок для приложения, нужно заранее перелопатить увесистые гайды от магазинов Apple, Android, Amazon и WP8 (самая замороченная платформа, очень много иконок и тайлов, но гайд грамотный). Вы не можете просто накидать в задаче ссылок, вам надо самостоятельно пойти и сделать из тонны текста выжимку, оставив исполнителю только важную для него информацию. Между тем, разбивая документацию на небольшие, но выполнимые задачи, хорошим тоном будет рассказывать команде, где и какая ещё информация доступна. Ведь всегда есть интересные и важные документы за пределами их обособленной задачи, запланированной на текущий спринт.
Заключительные мысли
Документация находится в постоянном состоянии Work in Progress. Это значит, что хоть основная работа выполнена и крепкий фундамент заложен, но хочется развивать и улучшать проект, добавляя новый контент и допиливая существующий. Если у вас есть пожелания или предложения – всегда рад услышать. Этот пример документации – не истина в последней инстанции. Автор допускает, что есть более продвинутые и гибкие методы работы, но в свободном доступе примеров нет. Я предлагаю свой вариант и призываю к обсуждению. Предполагается, что от этого выиграют все.
Войти
Примеры дизайн-документации
В связи с тем, что одна из самых сложных и не всем дающихся областей работы геймдизайнера – это дизайн-документация, многие меня просят показать примеры тех документов, о которых я говорила в своих статьях и уроках. Попробую ответить на все просьбы в этой статье.
Излагать свои мысли четко, внятно, структурировать их так, чтобы другому специалисту без болезненного вчитывания легко удалось ухватить суть – это непросто. Навык писать документацию приходит с опытом, и причем не только с опытом непосредственно написания, а в том числе и с опытом давания этой документации на прочтение, а также чтения документации чужой.
Дело в том, что дизайн документация – это что-то сугубо личное и особенное для каждого специалиста. У каждого есть свой метод, который зависит от многих факторов: как и от личных пристрастий, так и от коллектива, в котором геймдизайнер работает.
Первое: какая разница, каким способом, с помощью каких материалов и в каком стиле вы доносите свою мысль, если это удобно вам и понятно окружающим?
Второе: если вы уже пришли на чужой, живущий до этого своей жизнью проект, то какая разница, каким образом вы умеете блестяще писать дизайн документацию, если на проекте принят другой формат?
В таком случае можно задать резонный вопрос: зачем я вообще пишу эту статью, если дизайн-документация – это дело настолько индивидуальное? Фишка в том, что тут нужна некая отправная точка, от которой уже вы сами будете отшлифовывать и отрабатывать свой собственный стиль. И в этой статье я попробую вам такую отправную точку дать.
Итак, я сделала два документа: дизайн-документ и питч. Остальные, о которых я говорила в этом видео, в общем и целом, вы сможете смоделировать сами, поняв принципы этих двух. Я написала документацию по уже существующей игре, которая называется Tap Titans 2 – это довольно-таки интересный мидкорный кликер.
Важный момент: перед тем, как читать дизайн документы, поиграйте в эту игру пару дней, чтобы лучше понять, как описаны те, или иные механики.
Tap Titans 2 на Google Play
Tap Titans 2 в App Store
Тут, в принципе, все понятно, если смотреть по очереди то на питч, то на содержание этой и вот этой статьи. При написании питча важно помнить, что человек, который его будет читать, понятия не имеет о вашей игре, и, скорее всего, вообще не очень заинтересован в том, чтобы что-то читать и во что-то вникать. Поэтому меньше деталей, имен, тонкостей, непонятных слов, несущественных нюансов. Напоминаю главные правила:
1. Предложения должны быть короткими и емкими. Несколько раз подумайте, прежде чем утвердить очередное свое предложение.
Сравните два отрывка:
“Когда игрок нажимает на монстра, он наносит ему урон. Когда у монстров заканчивается здоровье, они умирают, а еще есть герои, которых игрок может нанимать, которые располагаются по двум сторонам экрана и сами по себе наносят урон, игроку не надо тапать”
“Игрок убивает монстров, тапая по экрану, а также покупая армию героев, которые формируют урон в секунду.”
2. Все, что вы говорите, должно быть вкусно, приятно читать.
Сравните два отрывка:
“Питомцы. Это такие сущности, которые тоже наносят урон монстру, когда игрок тапает на экран, а также они обладают своими пассивными навыками”
“ Питомцы. Огромный набор питомцев, которые наносят урон, когда игрок тапает, и обладают собственными уникальными пассивными способностями”
3. Все, что вы пишите, должно быть разбито на списки и классификации. Даже если человек не захочет читать весь текст, он прочитает первые несколько слов в строчке и поймет общую суть.
Сравните два отрывка:
“Модель free-to-play. Продажа паков премиум валюты, которую игрок может потратить на покупку бустеров, которые действуют определенное количество времени, добавляя игроку новые возможности и существенное преимущество в бою, а еще на покупку сундуков с рандомными ценными наградами и на покупку питомцев.”
“Модель free-to-play. Продажа паков премиум валюты, которую игрок может потратить на:
- покупку бустеров, которые действуют определенное количество времени, добавляя игроку новые возможности и существенное преимущество в бою;
- покупку сундуков с рандомными ценными наградами;
- покупку питомцев.”
Я уже упоминала, что я люблю вести дизайн-документацию в таблицах – по ним удобно ориентироваться и в них удобно писать. Но можно также и в обычных текстовых документах, делая каждый документ – описанием отдельной механики.
Первая страничка дизайн-документа – это оглавление.
Тип
Впоследствии механик может быть много, поэтому я разбиваю их на типы. Например, “Игровые валюты”, “Персонаж” и так далее. Даже если будут такие типы, в которых только по одной механике – это не страшно.
Название механики
Здесь – непосредственно сама механика. Краткое ее название, которое в то же время будет описывать ее суть.
Ссылка
Если документ разрастется, то будет тяжело ориентироваться между вкладками, поэтому лучше использовать внутренние ссылки.
Статус
Тут все понятно: описано / не описано / в процессе.
Описание
Очень удобный раздел, в котором надо как можно короче дать ответ на вопрос “что это такое”. Пригодится для того, чтобы новый человек лучше ориентировался в вашем документе и быстрее разобрался с игрой. Тут тоже не всегда можно дать четкое определение, но это не страшно.
Обновлена
Некоторые механики устаревают, и когда работы много и она совершенно разная, можно легко забыть, что вы уже обновляли, а что нет. Иногда будет просто полезно пробежаться по датам и перечитать самые старые механики на предмет актуальности.
Автор
Если на проекте работают несколько геймдизайнеров, будет понятно к кому обращаться с вопросами по тексту.
Комментарий
Это поле для каких-то заметок и напоминаний. Если другой геймдизайнер будет читать этот документ, он сможет задать тут вопрос. Также и вы можете оставить памятку для себя, или какое-то пояснение.
Каждая вкладка в табличном дизайн-документе – это описание конкретной механики. С опытом я поняла, что описывать механики лучше тезисно. Короткими, емкими предложениями. Даже если это один абзац текста, относящийся к одному и тому же предмету, то все равно, чаще всего, его можно разбить на конкретные, законченные мысли. Такой стиль написания документов удобен потому, что читающий получает информацию порционно: он прочитывает короткое предложение и думает про себя: “ну окей, кажется все понятно, поехали дальше”.
Нумерация строк призвана облегчить обсуждение документа с другими людьми. Например, если вы будете разговаривать с человеком, работающим удаленно, или у специалиста возникнет короткий вопрос, ему достаточно будет просто спросить: “У тебя в пункте 1.3 написано то-то, можешь мне пояснить вот этот момент”.
Еще таблицы удобны тем, что можно легко выделить какую-то строку и с помощью цветовой дифференциации отметить спорные моменты, или моменты, которые хочется обсудить.
В столбце “Комментарий” можно сделать пометку, или указать ссылку, ведущую к материалам по теме.
Также я добавляю к каждой странице ссылки, которые ведут к механикам, упоминаемым в описании. В таком урезанном варианте документа это выглядит немного комично, но когда документ у вас большой, ссылки будут вести не только на соседние странички, но и по всему документу с механиками, а зачастую и на совершенно другие документы.
Надеюсь теперь дизайн-документация стала для вас прозрачнее и вы, взяв за основу мои идеи, сможете изобрести удобный для себя способ ее ведения.
