Играй как гейм-дизайнер

1
Шкоркин Алексей Вячеславович3/13/2020

Играй как гейм-дизайнер — одна из самых популярных рекомендаций для тех, кто делает свои первые шаги в профессии. Что же на самом деле скрывается за этими словами? Авторы книг и статей рекомендуют играть как можно больше, играть в игры разных жанров, играть не только в хорошие игры, но и в плохие, всячески повышая свою «‎наигранность».

В повышении ее уровня ничего плохого нет, но почему-то не для всех очевидно, что одной «‎наигранности» недостаточно. Неплохо было бы не просто потреблять игры, но еще и критически к ним относиться.

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

Предлагаю вам ознакомиться с вариантом проведения такого критического разбора.

ПОДГОТОВИТЕЛЬНЫЙ ЭТАП

Что делать?

  • Поиграйте в игру. Требование может показаться очевидным, но здесь основная задача не в том, чтобы провести несколько часов перед экраном (или за столом), а в том, чтобы рассмотреть все аспекты игры с разных сторон, чтобы ваш отзыв был более объективным.Желательно пройти игру до конца, если конец вообще подразумевается. Если прохождение занимает десятки часов, нужно закончить хотя бы главную сюжетную линию.Если в игре асимметричный геймплей (как, например, в StarCraft) с разнообразными стратегиями, нужно поиграть за разные стороны и против разных противников.Если в игре есть разные уровни сложности, попробуйте сыграть на каждом.Если в игре есть разные режимы (однопользовательский, многопользовательский и др.), желательно попробовать каждый из них. То же правило применительно к настольным играм — играть в разных составах и с разным количеством игроков.
  • Ваша основная цель — не получить удовольствие от игры, а зафиксировать наблюдения, которые вы в дальнейшем будете использовать для анализа. Требований к записи наблюдений нет — главное, чтобы вам удобно было с ними работать.  На что следует обращать внимание? Фиксируйте связи между дизайнерскими решениями и геймплеем (какое решение было принято, как это отразилось на игровом процессе, за счет каких внутриигровых ресурсов это было достигнуто, какая задача при этом решалась). Эти решения могут лежать в разных плоскостях: в интерфейсе, графике, звуке, балансе, управлении, компонентах игры и т.д.
  • Также можете записывать личные впечатления. В критическую статью они не пойдут, но могут натолкнуть вас на мысли о том, как то или иное решение влияет на опыт игрока. Записывайте впечатления в виде пары «решение разработчиков — ваша реакция», например: «Нет точки сбора для строящихся юнитов — раздражает».

Чего не делать?

  • Не читайте обзоры и рецензии на игру, пока не сыграете в нее сами, и до того, как будет написан черновик статьи. Во-первых, вряд ли вы вынесете оттуда что-то полезное (скорее всего, вас ждёт реклама, эмоции, пересказ сюжета, необоснованные суждения и никому не нужные подробности), а во-вторых, чужое мнение может сбить ваш фокус.
  • Не приступайте к анализу до тех пор, пока не выполнены все требования пункта «Поиграйте в игру». Есть вероятность, что на более поздних этапах игры вы будете эту игру видеть совершенно по-другому, и тогда либо придется все переписывать (на что уйдёт время), либо вам будет лень это делать, и работа потеряет в качестве.
  • Не пренебрегайте записями и не надейтесь на свою память. Есть риск того, что вы совсем забудете упомянуть какой-то важный момент, либо вспомните о нем и потратите дополнительное время на его поиск в игре, чтобы уточнить детали.
  • Не путайте черновик статьи с анализом и не спешите публиковать свои наброски. Сначала выполните рекомендации следующего этапа.

АНАЛИЗ ИГРЫ И НАПИСАНИЕ СТАТЬИ

Что делать?

  • На подготовительном этапе вы зафиксировали связи между дизайнерскими решениями и геймплеем. Сейчас их нужно упорядочить и дополнить. Если для этого требуется еще раз сыграть, играйте. Результатом могут быть связки такого рода:

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

  • Сформулируйте задачи, которые стояли перед разработчиками (это проще сделать, поработав со связками, полученными на предыдущем шаге). Укажите, как эти задачи были решены (или решены не полностью) и за счет чего. Если вам известен результат, укажите и его. Постарайтесь описать решенные задачи так, чтобы решения были воспроизводимы, например:

Задача: облегчить перевод и локализацию игры. 

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

Результат: игра вышла сразу на 10 языках.

  • Если в игре есть что-то еще, заслуживающее внимания (например, новая механика, неожиданное решение), укажите это. То же относится к понравившимся вам элементам, для которых вы не смогли указать задачу или функцию — складывайте эти записи отдельно, в будущем они могут пригодиться.
  • Если у вас есть рекомендации по улучшению игры, они должны быть конкретными и обоснованными:конкретными рекомендациями считаются такие, которые описывают КАК решать проблему: вместо простого «Я бы поменял баланс оружия» стоит написать, например, как бы вы изменили характеристики того или иного предмета;обоснованными рекомендациями считаются те, из которых понятно ЗАЧЕМ нужно изменять принятое решение. Обосновывая свои предложения, лучше ссылаться на аналогичные решения в других играх, а не просто брать их из головы.
  • Рекомендации по оформлению статьи:укажите автора и издателя, год издания, жанр, платформу;дайте ссылку на трейлер с геймплеем для тех читателей, кто в игру не играл — это сэкономит им время, и они будут вам благодарны;для наглядности вставляйте скриншоты из игры, иногда лучше сделать гифку;SPOILER ALERT: предупреждайте о спойлерах, скрывайте текст, содержащий спойлеры;если вы, вопреки рекомендациям, все же решаете рассказать о своих впечатлениях от игры, отформатируйте их таким образом, чтобы они отличались от основного текста статьи.

Чего не делать?

Здесь перечислены типовые ошибки, связанные, в основном, с тем, что автор разбора путает критику с чем-то еще.

  1. Не ставьте игре оценку и не оценивайте отдельные ее аспекты (например, за графику 3, а за геймплей 4). Во-первых, оценки не информативны, а во-вторых, перед вами не стоит задача сравнить эту игру с другими. Качество критического разбора и качество игры вообще слабо коррелируют между собой. Разбор тем лучше, чем больше уроков из него может извлечь читатель, и перечень конкретных ошибок из неудачной игры будет ценнее эмоционального хвалебного отзыва 10/10.
  2. Не выражайте свои эмоции. Если же вы не можете удержаться и даёте эмоциональную оценку тому или иному решению, потрудитесь обосновать свою точку зрения.
  3. Не пересказывайте сюжет. Описание сюжета обычно мало что даёт сценаристам. Лучше будет указать на интересные сюжетные ходы и на влияние сюжета на геймплей.
  4. Не пересказывайте правила (если речь о настольной игре). Критический анализ — это не обучающий ролик! Стоит сосредоточиться на том, как то или иное правило влияет на игровой процесс.
  5. Избегайте лишних подробностей, особенно в описании механик. Критика — это не декомпозиция! Подробный разбор механики прыжка может быть важен для анализа платформера, но для игр, где это не ключевая механика, вероятно, нет. Если в вашем анализе появились математические формулы или строки кода, скорее всего, вы двигаетесь не в ту сторону.

ЧТО МОЖЕТ ПОЛУЧИТЬСЯ В РЕЗУЛЬТАТЕ?

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

Я разобрал компьютерную игру, но то же самое можно делать и с настольными. Это немного более сложный объект для исследования, так как, во-первых, они в среднем дороже, во-вторых, они материальны (за ними надо ехать, их надо где-то хранить – если у вас 100 коробок, это может стать проблемой), но самое главное — нужны игроки, которые будут с вами играть, притом регулярно. Если перечисленное для вас не является барьером, тогда замечательно.

Минимум переключений между меню

При использовании карты и / или компаса игра не переключается в другой режим. Компас появляется в правой руке, а карта в левой. Таким образом закрывается часть экрана, но при этом продолжаются игровые события, а протагонист может перемещаться.

При необходимости компас можно приблизить.

Если приблизить карту, то она будет закрывать собой все поле зрения, зато ориентироваться будет гораздо удобнее. Бегать при этом герой не может.

При поднятии других предметов также не появляется дополнительных меню

Есть возможность рассмотреть каждый поднятый предмет, даже если он не оказывает никакого влияния на сюжетную линию. 

  • Вращение предмета позволяет глубже погрузиться в игровой мир (например, у подобранной книги можно рассмотреть не только переднюю обложку, но и корешок, и прочитать аннотацию на задней стороне).
  • Приближение предмета позволяет прочитать документ, не открывая специальное меню.

Какая задача решается: погружение в игру, т.к. игрок не отвлекается на дополнительные меню и не покидает игрового мира

Предложения по улучшению:

В игре есть возможность читать найденные документы как в виде изображения, так и в виде текста, открыв отдельное меню. Если открыть меню, то игра ставится на паузу (это проявляется, например, в том, что диалог с Дилайлой обрывается на полуслове и продолжается, когда вы закончите чтение документа). Поскольку документы всё равно малого объёма, от этого меню можно отказаться. Вместо этого можно воспроизводить их как изображение и при необходимости приближать, как карту. (Но, скорее всего, такая двойная запись нужна для облегчения перевода и локализации).

Рюкзак со снаряжением

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

Какая задача решается: это решение повышает доверие к происходящему в игре. Не возникает вопросов типа «А что, персонажи спят в доспехах?»

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

Перемещения героя

В целом, перемещения героя гораздо больше соответствуют реальности, чем в FPS или Action RPG. Это удачно вписывается в игровой мир (в конце концов, вы играете толстого мужчину за сорок с полным рюкзаком за спиной), однако может доставлять боль любителям указанных жанров из-за неспособности персонажа преодолеть препятствия, которые сам игрок бы смог преодолеть в реальной жизни.

Недоступные области:

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

Непреодолимые препятствия. Герой не может заходить в озеро, даже по колено, не может преодолевать небольшие ямы и карабкаться по безобидным склонам.

Безопасность. Герой не может шагнуть с обрыва или навредить себе каким-то другим способом.

Прыжки. Герой может прыгать только тогда, когда это нужно, т.е. при преодолении препятствия. Просто так, по воле игрока, прыгать нельзя.

Бег. Здесь разработчики пошли на уступки. Бег доступен в любое время (кроме тех моментов, когда вы пользуетесь картой). Кроме того, не накладываются ограничения на бег в гору. Конечно, двигаться со скоростью мотоцикла нереалистично, но все готовы закрыть на это глаза, если речь идет об экономии времени и нервов.

Как вы заметили, указанные решения, принятые разработчиками Firewatch, так или иначе направлены на иммерсивность или погружение. Теперь возникает вопрос: что с ними делать?

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

Целесообразно также фиксировать ошибочные и неудовлетворительные решения тех же самых задач.

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

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

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

Безопаснее и полезнее, таким образом, публиковать именно выводы с примерами из нескольких играх одного жанра. 

Спустя какое-то количество разобранных игр (ориентируйтесь на пару десятков, если игры не совсем уж из разных жанров) у вас появится достаточно материала для того, чтобы выкладывать ролики типа «10 способов…», причем эти ролики могут быть содержательнее и полезнее большей части того, что есть на YouTube сейчас. А если будете работать дисциплинированно, то в долгосрочной перспективе никаких проблем с наличием контента у вас не будет.

Статья автора издательства LIVREZON.
Следующая статья
IT
5 способов провалиться на внедрении DDD
Спустя годы после выхода «‎Domain Driving Design», идеи Эванса вошли в мейнстрим. Разработка через моделирование должна была устранить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло. На собеседованиях и митапах я слышу > Мы пытались внедрить DDD, но у нас не получилось DDD — очередной мем, за которым стояла здравая и очевидная идея: программа есть реализация модели процесса. Предполагалось, что так же как физики решают сво...
IT
5 способов провалиться на внедрении DDD
Livrezon-технологии
Миф 11. «А у тебя есть ген гениальности?» Фрагмент книги М. Гуменной «ПРОФЕССИЯ: технология поиска себя»
Livrezon-технологии
Выбор исследовательской темы. Фрагмент книги А. Рыжачкова и Д. Матвеева «Как написать умную книгу?»
Livrezon-технологии
Виды «блефов» в бизнес-технологиях
Livrezon-технологии
Как написать сильные выводы?
Бизнес и экономика
Стандарты сервиса в США 30-х годов по наблюдениям Ильфа и Петрова
Livrezon-технологии
Как получить Нобелевскую премию? Пример Сигрид Унсет
IT
Искусственный разум по Акселю Бергу
IT
Иностранные языки: компьютер в помощь
IT
О персональном компьютере глазами 1984 года
Искусство и дизайн
Сюжет как карьер — развитие сюжета и его виды
IT
Различия между человеком и компьютером по А. Тьюрингу
IT
Мир реальный или мир виртуальный? Выбор за вами!
IT
Различия между человеком и компьютером по Алану Тьюрингу
Искусство и дизайн
Почему игра может наскучить?

Медиа

Комментарии (1)

Сотников Вадим 8:58:32 PM 3/15/2020
Пользователь

Вот с этим правилом не согласен: "Не выражайте свои эмоции" - с одной стороны это правильно. С другой игра захватывает игрока именно вызыванием эмоций.

Для разработки игры надо понимать, как эти эмоции создаются. Это можно сделать следующим образом:
1. Отмечать моменты, которые вызывали переживания, эмоции или атмосферу.
2. Обдумать, почему данный момент вызвал в вас переживания.
3. Определить какими средствами создатели создавали в вас эти эмоции, переживания.

Это относится к любому художественному произведению.