11 лайфхаков для ускорения процесса дизайна вашей игры

[pullquote align=right]
Натан Ловато, игровой дизайнер и журналист, рассказал GameAnalytics как правильно разрабывать игры
[/pullquote]

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

Большой, всеобъемлющий документ разработки игры (Game Design Document или GDD) — это миф. Я говорю здесь о гипотетическом файле, который содержит каждый бит информации, которую нужно знать об игре. В больших командах слишком много деталей, которые надо записать и отслеживать, чтобы их можно было все скомпилировать в один документ. А секции GDD соответствуют только одной из частей команды разработки.

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

1. Короткий прототип лучше тысячи слов

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

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

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

Конкурс Ludum Dare дал нам много примеров того, как целые серии игр рождались из прототипов

2. Лаконичные документы

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

Вы можете брать в пример сценаристов: сценарий фильма всегда написан простым, описательным языком. Шрифт очень большой, а в документе так много выделений, насколько это возможно. Все упорядочено, поэтому читатель очень быстро читает, независимо от его читательских скиллов. Скрипты фильмов делаются для занятых продюсеров и его коллег, которые должны понять точку зрения автора.

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

3. Пишите, помня о ваших коллегах

Как дизайнеры мы пишем документы по дизайну для других. Для клиента, менеджера, разработчиков и т.д. У них у всех разные нужды и ожидания. Клиенту может быть все равно на детали выбранной вами технологии для реализации. С другой стороны, вашим разработчикам скорее всего понадобятся детали для оценки технических ограничений, которые последуют из вашего выбора. Другими словами, вы должны адаптировать стиль и контент для ваших читателей. Часть работы дизайнера в том, чтобы понимать ваших коллег и их нужды. То, что пишете вы, не только должно стать необходимым источником для работы других. У вас есть возможность упростить их работу.

Если вы хотите оказать услугу своим коллегам и улучшить навыки писательства: просто просите фидбека у читателей! Ваши коллеги будут рады сказать вам, каких изменений им хотелось бы видеть. Или, что поможет им работать быстрее. В идеале, вам нужно понимать, как работает каждый в студии. Что включает в себя должность каждого? Это лучший способ понять других: разделите их работу. Получение отклика должно быть достаточно для удовлетворения кого угодно.

4. Делайте тесты для предотвращения ненужной болтовни

Этот пункт связан с первым в списке. Ваши идеи оставляют пространство для интерпретации… и дискуссии! Это особенно верно для клиентов, которые не работают в индустрии игр. Им может не понравиться ладный и эффективный дизайн, если они не увидят конечной игры. Только потому, что они вам не доверяют, или потому, что у них еще что-то на уме! Куда легче показать с контроллером в руке, что решение работает или нет, чем объяснить. Общее место — поспорить по поводу конкретной механики и застопориться на обсуждении преимуществ некоторых решений.

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

5. Проводите эксперименты в начале дня

Поиск новых идей — сложная для головы задача. Это истощит вас за несколько часов. Продвижение туда-обратно между разработкой концепта, программированием, набросками и письмом высосет из вас все соки сразу. Это общая подсказка по продуктивности: если вы хотите оставаться эффективными в течение 8 часов в день, вам нужно кратковременный рабочий план. Список задач, которые нужно выполнить, в правильном порядке. Вам нужно собрать все первичные материалы, идеи, которые вам понадобятся, когда вы придете в офис. Или даже днем раньше!

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

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

6. Научитесь кодить

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

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

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

7. Используйте изображения

«Картинка стоит тысячи слов», или как-то так говорят. Это выражение правильное, если картинка релевантная. Вы можете иллюстрировать разные уровни эскизов и задачи с планом. Ничто не даст вам такого понимания игры, как нарисованный концепт. Вы можете также описывать системы с удобочитаемыми диаграммами, а не простым текстом.

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

8. Сократите итеративные циклы

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

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

9. Используйте аналитику как можно раньше

Независимо от того, сколько у вас тестировщиков, включая вас, вы можете отслеживать все полезные данные с помощью API аналитики. Сколько раз каждый тестировщик не смог пройти этот уровень? Сколько справились с ним? Эти простые данные дадут вам представление о том, насколько ваша игра сбалансирована. Их сложно отследить вручную. Но они особенно важны на ранних стадиях проекта. И они все еще нужны во время бета-тестов… И даже после выпуска игры!

Инструменты, вроде GameAnalytics, будут отслеживать данные и строить графики. Если вы используете Unity, SDK будет в виде удобного пакета для загрузки в ваш IDE.

10. Работайте с эффективными инструментами

Некоторые IDE более эффективны, чем остальные, когда речь идет о прототипировании. До недавнего времени мой выбор для создания 2D прототипов — это HTML5 IDE construct 2. В любом проекте за 1 или 2 часа я мог сделать простой, но точно работающий прототип. Это HTML5, поэтому я мог дать игру коллегам, находящимся на расстоянии, очень быстро.

Настоящий разработчик игры может выбрать любой движок для разработки конечного продукта. Очевидно, внутри какой-то сложившейся команды идеально работать с общим набором инструментов. Как вы знаете, инструменты вроде Unity отлично подходят и для прототипирования, и для долгой работы. Идеально, если вы хотите разработать нативную игру. Если вы одинокий дизайнер игр или фрилансер вроде меня, вам также хорошо подойдут HTML5 и Haxe.

11. Используйте заглушки

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

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

Обобщая

В целом, весь список можно свести к трем пунктам:

1. Используйте и эксплуатируйте прототипы.
2. Пишите и программируйте, помня о ваших коллегах.
3. Не забывайте о ясности презентации.