7 советов — Анализ гейм-дизайна игры
Анализ гейм-дизайна игры не только очень часто включают в тестовые задания. Это ещё и полезный инструмент работы над своими ошибками в низкоуровневом дизайне. Хочу поделиться парой полезных советов по использованию анализа гейм-дизайна в работе.
Совет 1. Абстрагируйтесь
Забудьте про полученные от игры впечатления. Впечатления всегда субъективны. Впечатления — это не то, с чего необходимо начинать анализ игрового дизайна. Фирменная метафора Рафа Костера:
Looking at the experience is like seeing the top of a mountain without knowing about tectonic plates.
Наши впечатления во многом сформированы вещами, которые мы не видим. Задача анализа — докопаться именно до таких вещей. Начните с «мотора под капотом»: правил игры, механик, игровых активностей.
Если смотреть в корень, то Papers, Please — игра в «найди 10 отличий», Her Story — симулятор написания запросов в базу данных, а Firewatch — поиск на полке аудио-кассет и их воспроизведение.
Передвижение в Stanley’s Parable почти не имеет игрового смысла. Это просто цикл мелких решений игрока, происходящий только ради создания впечатления. По сути, Stanley’s Parable — это просто нелинейный аудиоспектакль в стиле Choose-Your-Own-Adventure.
Просто отбросьте все лишнее. Ваша первая задача — исследовать системы, лежащие в основе. Нащупайте «скелет» игры.
Определите, как кор-механики будут развиваться в игре с течением времени. Какие у игрока есть рычаги воздействия на системы, и каковы будут последствия этих воздействий? Есть ли уязвимости систем, которые игрок сможет использовать для обхода правил игры? Чему учится игрок по мере прогресса? Влияет ли вообще умение игрока на его успешность в игре? Для этого необязательно проводить в игре десятки часов — экстраполируйте.
Совет 2. Обдумайте принятые решения и их причины
Разберите игру на отдельные решения, принятые гейм-дизайнером. Определите самые важные из них. Подумайте над причинами этих решений. Какие цели преследуются? Какие проблемы решаются?
Например:
- Почему мультиплеер в игре асинхронный?
- Почему в игре отсутствует friendly fire?
- Почему в игре выбор реплик протагониста нивелирован до «колеса диалогов» ?
Чаще всего системы проектируются гейм-дизайнером для вполне очевидных целей:
- игрок продолжает играть
- игрок платит деньги
- игрок сосредоточен на впечатлениях, а не на системах
- игрок чувствует удовлетворение (чаще всего через ощущение могущества)
- игрок хочет помогать другим игрокам
- игрок хочет побеждать других игроков
- игрок удивлён
- и т.д.
Например, удивление. Иногда гейм-дизайнер нарочно проектирует привычные опытному игроку системы так, чтобы они работали неожиданным образом, либо не работали вовсе. Яркий пример — Undertale и момент с камнями.
Совет 3. Используйте списки
- Все любят списки!
- Их проще читать
- Они экономят время читающего
- Сразу привлекают внимание
- Автоматически структурируют информацию
- Снижают объём воды в тексте
- Списки — это круто!
Но злоупотреблять ими, разумеется, тоже не нужно. Обойдитесь без списков там, где явно требуется развёрнутый описательный текст.
Совет 4. Каталог объектов и активностей
Во время анализа систематизируйте информацию по всем найденным игровым элементам. Проще всего завести каталог объектов в форме таблицы с необходимыми для анализа полями и записывать информацию туда.
Например:
- Краткое описание объекта (Тяжёлые каменные блоки)
- Когда вводится игровой объект (В середине игры)
- Его основная функция (Их можно перемещать и использовать для доступа к высоким платформам на уровне)
- Есть ли у него взаимосвязь с другими объектами и какая (Если сбросить тяжёлый блок на деревянный мост, то мост сломается)
- и т.д.
Объект необязательно должен иметь физическое воплощение в игре. Это может быть даже отдельная игровая механика (Механика лечения — в самом начале игры — восстановление HP персонажей — вместо восстановления HP наносит повреждения нежити)
В соседнюю таблицу можно заносить все возможные воздействия игрока на игровые системы и их связь с игровыми объектами.
Каталог необязательно прилагать к финальному тексту анализа, если вы делаете его не только для себя. Но он поможет вам разобраться в связях между игровыми элементами.
Совет 5. Анализ — это не рецензия
Очень часто юные падаваны в своих опусах начинают подражать единственному известному им стилю письменной речи про игры — обзорам игрожуров. Они пишут про «красивую» графику, «захватывающий» геймплей и «удивительное» звуковое оформление.
Анализ всегда должен быть основан только на объективных характеристиках продукта.
Не «красивая графика», а «яркий минималистичный аниме-стиль, позволяющий сэкономить на производстве контента и отвечающий вкусам целевой аудитории».
Не «захватывающий геймплей», а «набор игровых механик, основанный на успешных продуктах из целевого сегмента рынка и ряде оригинальных идей, продиктованных мета-системой».
То же самое и с негативными с вашей точки зрения дизайнерскими решениями. Не говорите «Плохо!» или «Круто!». Говорите «Круто, потому что…» и «Плохо, потому что…»
Анализ всегда рассуждает о принятых во время разработки игры решениях и их причинах. Не забывайте, что причины не всегда могут быть продиктованы замыслом дизайнера. Фирменный туман Silent Hill появился из-за того, что PS1 просто не тянула крутую графику первой части SH — команде срочно пришлось ограничивать поле зрения игрока, чтобы справиться с этой проблемой. Это, разумеется, решение больше в поле экспириенса, чем систем, но общую мысль понять можно.
Совет 6. Адвокат Дьявола
Выработайте привычку думать не только о присутствии в игре каких-то механик, элементов или решений, но и об их отсутствии . Задавайте себе вопрос «По какой причине гейм-дизайнер этой игры не сделал так?» Знать, какик решения принимать не стоит — одна из самых важных и нечасто встречающихся черт профессионального гейм-дизайнера.
Совет 7. Следуйте плану и будьте краткими
Неважно, анализируете ли вы гейм-дизайн для тестового задания или для себя лично. Анализ все равно остаётся техническим документом, а не собранием сочинений. Пишите по делу. Избегайте сложных оборотов. Сократите количество красочных эпитетов. Сухие факты и ваши наиболее практичные размышления о них — вот правильный стиль. Если у вас есть план — следуйте ему. Если нет — напишите план! 🙂
Разумеется, у каждого свои ноу-хау по анализу гейм-дизайна. Не стесняйтесь — делитесь в комментариях.
Надеюсь, что кому-нибудь было интересно или полезно.
Увидимся!
P.S. Спасибо Барисби Алборову за Совет #6 🙂
Источники
10 комментариев
FYPIIN
Что-то очередность странная. Сначала абстрагируемся и ищем принятые решения, попутно думая о них. А потом начинаем каталогизировать. Разве не нужно сначала выявить все элементы, а потом уже думать о принятых решениях. Да и в целом если убрать пункт “Анализ — это не рецензия”, то с таким же успехом статью можно назвать “6 советов – рецензия игры”.
Хотя это просто советы, а не гайд по анализу игр, так что наверное я перегибаю палку.
Пока писал, возник немного философский вопрос: “А действительно ли нужно пытаться понять почему?”. В 90% случаев найденная нами причина принятия какого-либо решения будет отличаться от авторской. Причин может быть миллионы, начиная от банальной копии чужой механики и заканчивая снами, фантазиями или извращенными математическими апроксимациями. Не принесут ли больше вреда чем пользы такие ошибочные догадки.
Matsukaze
Анализ чужих продуктов – это как гимнастика для ума.
Поиск решений, взаимосвязей и логических цепочек сам по себе тренирует рациональный образ мышления, так что это в любом случае не лишнее, имхо.
И даже если догадки не будут верны на 100%, во время размышлений вас может посетить какая-нибудь отличная идея 🙂
FYPIIN
Сразу предупреждаю – размышляю вслух. Это не значит, что я свято верю в нижесказанное:)
Узнать все составные элементы и их связи вполне полезно. Но я не говорю о поиске решений и взаимосвязей, я говорю о поиске причин принятия этих решений. То что решение А связано с решением Б, абсолютно ничего не говорит о причине принятия решения А или Б.
Представим мы хотим узнать как работает теорема пифагора (как аналогия, мы хотим узнать как работает игра). Разве нам важно доказательство теоремы Пифагора? Нам важен сам факт равенства суммы квадратов катетов квадрату гипотенузы. Так же и с игрой. Если нам нравится прыжок в платформере и мы хотим в свою игру такой же. Разве нам важно в данном случае почему формула прыжка такая? Нам важна сама формула.
Попытки понять причины решений растут из гиблых попыток попытаться повторить успех. Игра мега успешна, а давайте ка проанализируем ее и сделаем тоже такую крутую. В итоге анализаторы анализируют и ничего не выходит. Думают, думают и такие: “Ага, игра это верхушка айсберга, там еще куча всего в виде причин принятия решений. Ну давай узнаем причины”. В процессе анализа приходят к неправильным причинам, выдавая их за правильные, свято веря в их правильность (мы же проанализировали все связи, полюбому они сделали так поэтому и потому). Но в итоге опять провал.
Так стоит ли знать доказательство или достаточно самой теоремы? Разработка игры – это как разработка автомобиля, мы применяем законы физики, математики и т.д., мы не пытаемся узнать их доказательство.
Но згимнастику для ума – да, никто не отменял)
FYPIIN
Немного не так написал. Речь даже не о доказательстве, а о опыте и мыслях Пифагора. И не важности их при изучении данной теоремы
Matsukaze
Ну вот не соглашусь – важно знать, почему прыжок именно такой, и как это связано с остальными игровыми элементами.
Это поможет принять решение, применима ли эта формула к твоему проекту, или нет.
Иначе ты можешь принять неправильное решение, основываясь на “давайте сделаем прыжок, как в X”, а не на “давайте сделаем прыжок, как в Х, потому что у нас такие-то и такие-то механики и игровые элементы”.
Слепое копирование скорее приведет к провалу, чем анализ.
FYPIIN
Ну вы опять о связях. Понятно, что прыжок, например связан с пропастями и расстояние зависит от их размера или наоброт дыры, зависят от размера прыжка. И эта связь частично влияет на параметры прыжка. Но я не об этом. Я о причинах принятия более комплексных решений. Как, например, нужен ли прыжок в его игре и какой именно в целом. Создатель платформера мог создать дыры в игре по миллиону причин и важно ли нам знать почему? разве недостаточно знать, как связан прыжок с другими элементами. К тому же перепрыгивание может быть реализовано тысячью способов и связи в игре не всегда скажут, почему был выбран конкретный способ.
Можно еще с другой стороны. Как вы думаете, Микеланджело анализировал работы других художников и пытался ли понять почему они такое нарисовали? Анализ и поиск причин ведет только к подражательству. Если хочешь создать что-то стоящее, то сомнительно, что анализирование других полезно.
Matsukaze
Знать, как связан прыжок с другими элементами = знать, почему он в игре 🙂
Геймплейных причин не может быть миллион. Другие причины нас не интересуют.
Аналогия с художественным искусством слишком эфемерная, чтобы обсуждать её всерьёз.
В нашей индустрии, как и, скажем, в кино, невозможно создать что-то новое, не обладая опытом и восприятием инфосферы.
Если ГД не анализирует другие игры, то шанс изобретения им “стоящего” велосипеда близится к 100%. При этом скорее всего велосипед будет качественно плох или даже просто нефункционален – ведь ГД не имеет ни малейшего представления о том, насколько его идея оригинальна или правильна.
На своих ошибках учатся сами знаете кто 🙂
FYPIIN
“Знать, как связан прыжок с другими элементами = знать, почему он в игре :)”
Вот это точно нет. Иногда да, но в большинстве случаев – нет.
У вас принятие решения Б – следствие того, что не работало решение А и такое действительно можно выявить. Но не все решения такие.
Прыжок могли добавить, потому что продюссер увидел реймена и сказал, что наш герой должен прыгать. Его могли добавить потому что сын гд круто прыгает и он захотел передать это в игре. Прыжок могли добавить, чтобы показать радость персонажа. И так до бесконечности. И среди этой бесконечности некоторые механики могли быть добавлены всего лишь как следствие других механик.
KZ
«Firewatch — поиск на полке аудио-кассет и их воспроизведение» — не понял аналогии =) Скорее, Firewatch — симулятор ориентирования на местности с упором на сюжет.
Matsukaze
Ну так это одно и то же в плане смысла, отличается только масштаб 🙂
В самом сердце – поиск и прослушивание диалогов.