Reverse Engineering — необходимый инструмент “заимствования” для Game Designer
Всем привет! Меня зовут Юра Сысоев, и вот уже
Таким подходом стал «обратный инжиниринг» (Reverse Engineering) — исследование некоторого готового устройства (или программы), а также документации на него с целью понять принцип его работы © Wiki. Используя данный подход, я начал тратить меньше времени на запросы, выдавать качественный результат в короткие сроки, и проект получил финансирование. Для удобства далее я буду называть обратный инжиниринг реверсом.
В ходе анализа запросов я часто прибегал к реверсу, так как времени на более глубокую обработку запроса не всегда было достаточно, чтобы предложить уникальный подход к решению задачи. Сразу оговорюсь, в данной статье я описываю свой личный опыт и подходы, которые для вас могут быть не такими эффективными. Примеры, увы, будут без конкретных цифр и названий компаний, так как, надеюсь, все понимают, что такое NDA.
Вот один из примеров, когда нет времени на анализ и док, а результат нужен. Допустим, вам приходит запрос на создание документа, который описывал бы некую механику/игру, и на это дается
Что такое Reverse Engineering
Давайте коротко разберем, что же такое реверс-инжиниринг. Вы без труда можете найти определение в Википедии, но мне больше нравится то, что есть в Лурке :)
Некоторые слова в цитате пришлось заменить, так как в Лурке обычно пишут более экстравагантно — мат через мат.
Так вот, Reverse Engineering (ревёрсинг, обратная разработка) — это процесс «заимствования», восстановления исходников из конечного продукта инженерной и/или научной деятельности с интуитивным конструированием внутренней механики по принципу «а какие процессы должны вызвать такое внешнее поведение этого продукта?». Ориентируясь на нюх, так сказать. Иногда приводит к написанию собственного дока. Много их, ибо ваистену... © Lurkmore
Простыми словами, это когда вы берете чужой продукт и на его базе воссоздаете поведение игровых механик или игровых элементов с помощью наблюдения и анализа. Обычный процесс создания механики начинается с понимания цели и ожидаемого результата, с реверсом то же самое: сначала определитесь, чего хотите достичь, потом начинайте.
Совет: никогда не пишите документы «просто, чтобы написать документы». Поставьте конкретную видимую цель и конкретный результат, которого хотите достичь. К примеру, вы хотите, чтобы прыжок вашего героя отлично ощущался с точки зрения контроля, например как в Super Mario Bros. Вы начинаете долгую разработку документации с тестированием с прототипами и т. д. Но что вы можете сделать вместо этого? Включить «Супер Марио» и проанализировать механику прыжка, выписать это все в документ и отдать в разработку. Важно понимать, что реверс нужно делать только тогда, когда вы точно понимаете, зачем он нужен, и только в случае, когда вы не делаете артхаус инди Death Stranding для эмуляторов андроид-устройств...
То есть, если вы делаете «Матч-3», то не выдумываете велосипед, вы идете играть в Candy Crush Saga или Homescapes и смотрите, как у них все работает. В данных проектах аудитория давно известна, и она привыкла к некоторым стандартным механикам игр «Матч-3». Если им предложить что-то «слишком уникальное», есть шанс, что вы отпугнете свою целевую аудиторию (ЦА). Я не говорю о том, что нужно создавать клоны, речь о грамотном анализе с целью сокращения вашего же времени при написании или создании общеизвестных игровых механик.
Зачем нужен Reverse Engineering
Один из примеров я описал выше. Другой пример — обучение. В моей практике не раз встречалось, когда начинающим гейм-дизайнерам ставят задачи по реверсу механик конкурентов. Такие задачи для молодого бойца — отличный инструмент не только научиться описывать механику художественным текстом, но и начать мыслить структурно. Если в вашей команде есть trainee или junior-гейм-дизайнер, поставьте ему задачу по реверсу той части продукта, в которой у вашего коллеги есть пробелы, и вы удивитесь, как быстро он начнет расти. Естественно, с вашей стороны или со стороны лида потребуется четкий и внятный фидбэк по завершении задачи.
Разберем на примере. Вы делаете продукт из серии «Матч-3». Вам нужно понять, какие М3-элементы-«блокеры» необходимо вставить в начальный игровой цикл (самые важные для продукта
Следующий пункт, который я хотел бы отметить, — «наигранность». В моем понимании этот термин означает то, насколько хорошо вы знаете продукты схожего жанра и рынок в целом, а также, как хорошо вы ориентируетесь в игровых механиках. Приведу пример из личного опыта. Мой телефон выглядит как игровая приставка, на нем установлены на текущий момент порядка
Таким образом каждую неделю я развиваю «наигранность» и получаю личную базу с интересными и уникальными механиками, которые впоследствии могу воплотить в будущих проектах. Также понимаю, какие продукты вышли на рынок в последнее время, какие из них получили позитивные отзывы от ЦА и попали в фичеринг. По моему мнению, «наигранность» важна для любого человека, который занимается разработкой игр, особенно для гейм-дизайнеров, так как банально может случиться, что вы будете разговаривать с командой о продукте на разных языках.
Типы Reverse Engineering
Далее хочу поговорить о типах реверса, которые я лично для себя выделяю и считаю необходимым проводить.
Глобально реверс можно разделить на софтовый (Software), «ощущения» (How does it feel) и железо (Hardware). Последний нас не интересует, поскольку в рамках данной статьи мы затрагиваем только софт. Возможно, некоторые из вас могут разрабатывать новый Nintendo Switch, но реверс железа — это тема для другой статьи. Мы же остановимся на софтовом реверсе и реверсе «ощущений».
- Software.
- Code and technical approaches.
- Core and meta mechanics.
- Balance.
- Interface.
- Art style and animations.
- Lvl design.
- How does it feel.
- User experience.
- Sounds and music.
- Narrative.
- Overall impression.
- Hardware.
Софт-реверс — это реверс, направленный на поиск интересных гейм-дизайнерских и технических решений. Тот же пример с «Супер Марио», о котором было написано ранее, — это софтовый реверс. Другой пример: как ведет себя звук на экране загрузки в Death Stranding (далее DS). Те из вас, кто уже успел оценить игру, могли заметить, что при полной загрузке уровня или главы в DS есть звук, который проигрывается на экране загрузки уровня. Дело в том, что загрузки в игре достаточно продолжительные, поэтому может случиться так, что игрок попросту уйдет, а то и вовсе забудет, что он ждет загрузку уровня. Я лично, пока идет загрузка в DS, играю на мобильном телефоне. Как этот вопрос решили гейм-дизайнеры? Через несколько секунд после полной загрузки звук на экране становится громче! :)
Вот так, простым софтовым решением — увеличением звука — гейм-дизайнеры снова привлекают внимание игрока к экрану его телевизора. Заметьте, в данном примере упоминаются звуки, которые я отношу к другому типу реверса, но не рассматривается техническая составляющая звука, его качество, используемые инструменты или что-то подобное. Софтовый реверс оценивает только техническую часть.
Реверс «ощущений». Называю я его так потому, что слово «ощущения» наиболее полным образом описывает то, что входит в задачу: описать ощущения от игры или игрового элемента. Возьмем в пример тот же DS. В игре, особенно в самом ее начале, имеются большие локации. На этих больших локациях Хидео Кодзима, на мой взгляд, хотел показать одиночество, и у него это получилось, потому что делать там реально нечего. И чтобы локация вызывала у вас именно «нужное ощущение», был применен ряд технических моментов, например: отдаление камеры в нужные моменты, звуки ветра и т. д. Помимо этого, была добавлена очень грустная музыка, которая подчеркивает одиночество игрока в данный момент. Если вы выключите звук и захотите пройти начальные локации DS без музыкального сопровождения, игра покажется вам очень скучной. Это и есть реверс «ощущений»: когда вы подмечаете эмоциональную составляющую игровой механики или элемента либо понимаете, какой опыт пользователя (user experience) создается в данный момент.
Далее, в софтовой части, идет реверс механик. С помощью реверса вы можете быстро получить информацию по интересующей вас игровой механике, скажем по прыжку главного героя (ГГ). Например: если вы хотите достичь идентичного результата, как в игре «Х», можно расчертить поле и считать по пунктам, пикселям или как вам будет удобнее расстояние прыжка, приземление, скольжение и прочие параметры механики. В Super Smash Brothers Ultimate, кстати, есть тренировочная локация, где разметка уже есть. Все, что вам необходимо, выписать это в документ в удобной для вас и ваших разработчиков форме. Также одним из решений «готового реверса» механик являются постмортемы и дневники разработчиков, в которых описываются приемы, методологии и другие подходы, с помощью которых создавались игровые механики.
Возможно, кто-то из читателей уже видел дневники разработчиков, постмортем игры Shovel Knight или другие материалы по платформерам либо метроидваниям. В подобных материалах можно встретить подробное описание того, как гейм-дизайнеры делали и рассчитывали баланс прыжка ГГ и как на базе этого строились уровни, какими навыками обладал герой, как это влияло на расстояние прыжка, какие дополнительные механики применялись для создания продвижения ГГ по уровням, — все это является уже «готовым реверсом» механики и поможет вам в написании собственного документа.
Баланс. На нем не буду подробно останавливаться, потому что лично для меня это самая нелюбимая часть реверса. Как и в ходе создания баланса, во время реверса ваша задача — воссоздать математическую/экономическую модель продукта, основываясь на имеющихся данных. Я советую отдавать данный тип реверса гейм-дизайнеру по балансу или другому специалисту, который занимается математикой в вашем продукте.
Далее к софтовому реверсу я отношу интерфейсы (UI), но не опыт пользователя при их использовании (UX). Дело в том, что при софтовом реверсе вы подмечаете технические детали интерфейса, такие как зона или область нажатий — место, куда игрок достает пальцем и жмет чаще всего. Очень простой пример. Ваш продукт — Idle/Clicker (например, Tap Titans 2) в вертикальной ориентации, наиболее часто нажимаемая кнопка — улучшить ГГ. Вы берете и ставите данную кнопку в левый верхний угол, а 95% вашей ЦА — правши, которые играют на устройствах Android с
Как вы думаете, как скоро к вам прилетят «благодарственные» письма разъяренных игроков за такое «удобное» расположение кнопки? Уверен, очень быстро.
Небольшая ремарка по поводу «нужно ли делать реверс, а потом это имплементить в собственном проекте?». Короткий ответ: «Нет». Если вы где-то увидели пример реализации интерфейса, как я описал, поверьте, он не лучший. Думайте всегда своей головой, даже если в похожих с вашим продуктом играх есть аналогичный подход. Ваша игра — только ваша, и вам решать, какой в ней будет интерфейс. Конечно же, ваша задача как разработчика — сделать интерфейс как можно более удобным для максимального количества игроков, но не стоит бездумно гнаться за трендами и копировать неудачные кейсы. Всегда руководствуйтесь здравым смыслом и по возможности данными. Все вышеописанное касается софтового реверса интерфейса — того, что несет в себе технический характер. Все, что касается опыта пользователя от использования такого интерфейса, я отношу к реверсу «ощущений».
К последнему также я причисляю анимации, поведение кнопок или (ВАЖНО!) самого устройства. Приведу пример. Некоторые игры, в частности мобильная Call of Duty, для взаимодействия с пользователем и привлечения его внимания используют вибрации (доступны в большинстве современных мобильных устройств) — Haptic technology. Такие вибрации дают вам знать, когда игра найдена или стартует, когда вашего героя убили и так далее. Или, скажем, вы можете найти игры, в которых применяются красивые анимации и звуки при появлении окон, и они гармонично вписаны в игровой процесс. Все это я отношу к реверсу «ощущений» опыта игрока от использования интерфейсов.
На самом деле граница очень размыта, порой она и вовсе может исчезать, поэтому выбор, куда относить и как объединять элементы реверса, зависит только от вас. Если ваш продукт — игра, основанная на повествовании, к примеру красочная визуальная новелла, скорее всего, нужно будет сделать лаконичные окна, которые подчеркнут все прелести геймплея, а не миллион кнопок, как, например, в ММОРПГ-проектах.
Как итог, реверс «ощущений» — это то, как игрок чувствует происходящее на экране устройства, какие эмоции испытывает и какой опыт получает; и неважно, какой это будет тип реверса.
Давайте перейдем к арту. На мой взгляд, гейм-дизайнер может делать реверс артовых составляющих до определенной стадии, например: указать стилистику, размеры объектов, описать, какие части объекта будут анимироваться и что с ними будет происходить. Но более тонкие моменты: толщина линий, форма, подходы в построении теней и направление света — лучше делать техническому художнику или арт-директору/лиду. Все это тоже софтовый технический реверс. Гейм-дизайнер при реверсе арт-составляющих продукта должен понять, как было сделано, для чего, сколько анимаций имеется и для каких типов объекта используется и т. д., и описать все это в гейм-дизайн-документе. По сути, реверс арта напоминает написание ГДД, но только при реверсе у нас уже есть пример. Считайте, что вы списываете контрольную, но почерк человека разбираете с трудом :) При правильном подходе при реверсе арта на выходе вы получите документ, который будет выглядеть как ассет-лист: в нем будет указан персонаж, сделан его скриншот, описаны анимации, даны их тайминги и т. д.
Реверс дизайна уровней. Как и с артом, для более детального анализа лучше привлекать специализированного исполнителя, особенно если вы делаете большую игру со сложными уровнями и взаимодействиями на них. В остальном в плане реверса все схоже; единственное, результатом такой работы обычно является схема уровня с описанием объектов и, если таковые есть, описание заскриптованых сцен: что и где должно упасть, когда взорвется бочка, где находятся спауны противников и т. д.
Как видим, софтовый реверс направлен в первую очередь на выявление технических параметров игровых элементов. А вот как эти элементы должны ощущаться и какой опыт передавать/создавать, это уже реверс «ощущений», о котором мы и поговорим далее.
Я выделяю следующие типы реверса «ощущений»:
- опыт пользователя от использования интерфейсов и игровых элементов (User Experience), об этом мы уже поговорили;
- звуки и музыка (Sounds and music);
- повествование (Narrative);
- общее впечатление (Overall impression).
По данным пунктам пройдемся быстрее, чем по предыдущим, так как здесь упор идет на ощущения, и в целом суть реверса перечисленных элементов очень похожа. Для хорошего гейм-дизайнера важно уметь абстрагироваться и играть в свой продукт с точки зрения пользователя. В конце концов, если вы нацелены на то, чтобы заработать на игре, нужно делать ее интересной для пользователей, а не только для себя. Во время реверса «ощущений» важно абстрагироваться и непредвзято описать чувства, которые вызывает у вас тот или иной элемент игры. Реверс «ощущений» направлен на понимание и описание креативной составляющей. Например, для концепт-художника и аниматора важно передать характер персонажа, как он себя ведет, его ключевые особенности и т. д. Это и есть реверс «ощущений». В звуке и музыке это то, какие эмоции у вас вызывает трек, для нарратива — это интересность текстов, голос диктора и прочее.
Документ с реверсом «общего впечатления» от игры впоследствии может использоваться в создании концепт-ГДД, питч-документах и презентациях для продюсеров/ гейм-директоров.
Представленный выше список типов реверса не статичен, вы можете без труда добавлять к нему те типы реверса и то количество пунктов, которые считаете необходимыми. Возьмем тот же нарратив, начитку диктора; они ведь тоже содержат технические параметры, например длину звуковой дорожки; если это текст, то его размеры и стиль шрифта, то есть, по сути, можно добавить нарратив в софтовый раздел. Я веду к тому, что все продукты разные («Спасибо, Капитан Очевидность!»); и в зависимости от жанра игры и содержащихся в ней элементов вы можете варьировать типы реверса, добавляя или удаляя ненужные куски. Нет же смысла делать реверс «ощущения» по звукам для продукта, в котором их не будет?
С типами элементов, по которым можно делать реверс, разобрались. Теперь я хочу привести два других примера, с помощью которых можно делать хороший реверс-инжиниринг.
Reverse Engineering по тетраде элементов
Существует много способов разбивки игры на элементы и их группировки. Одним из них является тетрада элементов. Уверен, большинство читающих уже слышали о книге «Искусство гейм-дизайна» Джесси Шелла. Тем же, кто не в курсе, советую обязательно ее прочитать. Книга вышла давно, и какие-то вещи утратили актуальность, но в ГД-кругах некоторые называют ее библией гейм-дизайнера. Так вот, в данной книге автор описывает то, как он видит компоненты игры, и называет данную схему «тетрада элементов». Тетрада состоит из четырех основных элементов: «механики», «эстетики», «технологии» и «повествования». Подробнее об этом читайте в книге. Если же коротко, то суть тетрады в том, что чем более видимым является элемент игры для пользователя, тем он находится выше.
То есть, если у вас игра — классический платформер, самым верхним элементом чаще всего будет механика. В визуальной новелле с упором на сюжет верхний элемент эстетика. Почти во всех случаях элемент «технология» будет в самом низу, так как крайне редко выходят игры, в которых основным элементом является технология; например, это могут быть игрофицированные проекты для обучения программированию. Кстати, в конце статьи будет небольшой бонус для всех, кто дочитал :)
Итак, что есть реверс по тетраде элементов? Все просто: схема тетрады позволяет разбить игру на конкретные элементы, по ним и можно делать реверс. Берем условный платформер. Как говорилось выше, верхним элементом в большинстве платформеров является механика. Вот с нее и начинаем. Запускаем интересующую нас игру, в которой есть то «нужное», что мы можем «заимствовать» в собственный проект или принцип работы чего хотим понять, берем тетрадку и ручку или создаем новый документ в Google Docs и начинаем декомпозицию увиденного на экране. Подробно записываем все детали и делаем скриншоты-референсы, чтобы не только вы понимали, что описано в документе, но и ваша команда смогла уяснить, о чем идет речь. Визуальные референсы в целом отлично облегчают понимание документа.
Закончили с «механикой» — приступаем к следующему элементу, например к «эстетике». Ваша задача — понять, что, как и почему работает в референс-игре, а затем успешно реализовать это в собственном проекте.
Благодаря реверсу по тетраде элементов вы будете получать результат, уже разбитый на конкретные составляющие, а затем использовать данные заметки/наработки в своем проекте. Минус такого подхода в том, что более «крупные» игры, те, в которых много механик и игровых элементов (MMORPG, Battler, RTS), будет сложно реверсить, поэтому данный метод больше подходит для реверса более «простых» проектов, например гиперказуальных и некоторых казуальных.
Reverse Engineering с помощью AERM-таблицы
Следующий и, пожалуй, мой любимый тип реверса — это реверс с использованием AERM-таблицы. Любимый он потому, что дает наиболее полную, понятную и структурированную, на мой взгляд, систему реверса и анализа конкурентной игры.
Тем, кто не знаком с AERM-таблицей, я советую зайти в блог Александра Штаченко и обязательно ознакомиться не только с рекомендуемой статьей, но и с другими заметками. Саша уже давно ведет блог, делится опытом и регулярно обновляет сайт полезной информацией.
AERM-таблица состоит из стадий: A — Acquisition/привлечение; E — Engagement/вовлечение; R — Retention/возвращаемость; M — Monetization/монетизация. Именно в этом порядке пользователь в вашем проекте в идеале должен проходить стадии. Например: мы не сможем заработать на проекте (M), если не купили или не привлекли органический трафик на первой стадии (А). Помимо стадий, AERM-таблица разделена на столбцы согласно основным составляющим игры — Core, Meta, Social. Полагаю, все читающие уже знакомы с перечисленными базовыми понятиями.
Когда начинается новый проект, я всегда заполняю AERM-таблицу как можно раньше и как можно подробнее, так как при ее заполнении могут возникнуть вопросы относительно финального продукта, и лучше ответить на них пораньше, чем менять в середине продакшена пол-игры. Заполненную таблицу обычно добавляю в питч, концепт и вижен-документы. В идеале она не должна меняться до выпуска проекта. Но если все же случилось так, что виденье проекта изменилось, потратьте время и внесите корректировки в том числе в таблицу. AERM-таблица более подробная и разделена на большее количество составляющих, чем тетрада элементов. Благодаря этому, делая реверс по таблице, вы получите больше информации, что, в свою очередь, улучшит качество, наполнение и количество полезной информации в вашем ГДД.
Простой пример. Вы выпустили игру, к вам приходит пользователь. Первое, что должна делать хорошая игра, конечно же, сунуть пользователю под нос 5 красивых баннеров «Купи все за 99,99»... Конечно же, это не так :) Первое, что должна делать игра, это вовлекать пользователя в процесс (E), чтобы он остался в игре так долго (R), чтобы впоследствии заплатить (M). Как и в случаях с предыдущими подходами, вы сами вольны выбирать, какой из участков нуждается в реверсе.
AERM-таблица хороша не только на ранних стадиях проекта, когда вы начинаете разрабатывать первичную документацию, но и для анализа конкурентов. Как и в случае с тетрадой, здесь все просто: выберите необходимую стадию/составляющую и сделайте по выбранной части реверс. Например, вы скачали новую игру, и core-геймплей вас настолько увлек, что были готовы даже заплатить. Вы думаете: «Ничего себе, я тоже хочу, чтобы в моей игре Engagement работал так же хорошо!» И садитесь за реверс Core — Engagement. Или же, к примеру, вы делаете «Матч-3» и хотите, чтобы социальные взаимодействия ежедневно возвращали ваших пользователей в игру. Вы берете несколько игр жанра и делаете реверс Social — Retention. И так далее. Плюс реверса по AERM-таблице в том, что она покрывает все аспекты игры и при всей своей простоте является понятным, простым и очень эффективным инструментом. Дальше все зависит только от вас и жанра вашего проекта.
Советы по применению Reverse Engineering
Далее я хотел бы дать несколько советов по применению реверс-инжиниринга и подвести итог.
- Прежде чем приступить, решите для себя, нужно ли это вам? Как уже говорилось выше, не делайте реверс, только чтобы сделать его. Он должен иметь смысл.
- Реверс будет полезен не только в жанре своей игры, но и в других жанрах. Это поможет развивать наигранность, будет ориентировать в других жанрах. Да и кто знает, какой «клад» вы найдете в другой игре :)
- Выберите тип и установите правила реверса. Сформулируйте правила игры: чем конкретнее будет поставлена задача, тем лучше вы получите результат.
- Всегда записывайте то, что показалось вам стоящим. Все запомнить невозможно, и, увы, иногда случается так, что новая интересная механика, которую вы нашли в одной из сотен игр, просто забудется. Поэтому настоятельно рекомендую делать даже минимальные записи элементов, которые вы сочли интересными.
- Делайте скриншоты, а еще лучше — видео интересующих вас элементов. Визуальные референсы отлично подкрепляют описанную механику, вашей команде будет намного проще ориентироваться в документе, а вам — лучше понимать, какого результата ждете и о чем идет речь.
- Не стоит реализовывать функционал, который вы зареверсили, только потому, что в другой игре он работает. То, что работает в референс-игре, необязательно подойдет вашей; поэтому никогда не спешите с реализацией функционала. Обсудите с командой или посоветуйтесь со старшими коллегами.
- Старайтесь оперировать цифрами и непредвзятым фидбэком. Данный совет связан с предыдущим. Если вам кажется, что вы «нащупали» что-то интересное, лучше потратить еще немного времени на поиск дополнительной информации и подтверждения эффективности найденной механики.
- Сделав реверс, покажите его коллеге и получите фидбэк. Всегда старайтесь получать фидбэк по выполненной работе, это позволит вам расти как профессионалу.
- Давая задачу по реверсу начинающему ГД, не забывайте о качественном фидбэке. Если вы ведущий гейм-дизайнер или продюсер и запросили джуна сделать реверс, непременно дайте своему коллеге фидбэк: это поможет вам быть на одной волне и качественно улучшит создаваемые реверс-документы.
В заключение
Хотелось бы привести одно высказывание. Пабло Пикассо сказал: «Хорошие художники копируют, а великие — воруют». В случае с реверсом это высказывание как нельзя хорошо подходит, т.к. эту фразу можно истолковать так: «Плохой Гейм-дизайнер создаст клон, а хороший сворует так, что в итоге создаст новый продукт — игру, которая принесет яркие эмоции и новый крутой опыт вашим пользователям». Делайте хорошие игры и радуйте своих пользователей!
Бонус
P. S. Обещанные бонусы всем, кто дочитал до конца. По данным ссылкам вы найдете мою личную базу знаний, которая пополняется интересными материалами: Knowledge Base, а также доклады и выступления с прошедших конференций: Conference Reports.
