Фев. 21

Reverse Engineering — необходимый инструмент “заимствования” для Game Designer

Всем привет! Меня зовут Юра Сысоев, и вот уже 7-й год я занимаюсь в индустрии задачами разного плана — от создания концептов новых проектов до детализации гейм-дизайн-документа (ГДД) и пострелизного анализа продуктов. Долгое время анализировал входящие запросы на создание продукта, и благодаря порой «очень качественным» из них был вынужден найти решение, которое позволяло бы получать результат за короткий промежуток времени.

Таким подходом стал «обратный инжиниринг» (Reverse Engineering) — исследование некоторого готового устройства (или программы), а также документации на него с целью понять принцип его работы © Wiki. Используя данный подход, я начал тратить меньше времени на запросы, выдавать качественный результат в короткие сроки, и проект получил финансирование. Для удобства далее я буду называть обратный инжиниринг реверсом.

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

Вот один из примеров, когда нет времени на анализ и док, а результат нужен. Допустим, вам приходит запрос на создание документа, который описывал бы некую механику/игру, и на это дается 1–2 дня. Конечно же, вы можете в силу своей креативности придумать что-то невероятно крутое, что впоследствии, по вашему мнению, изменит мир. Но есть большая вероятность того, что продюсер или директор игрового направления скажет «работать это не будет, давай сначала», а вы уже потратили все доступное время. Именно в таких случаях я предпочитаю путь реверс-инжиниринга.

Что такое Reverse Engineering

Давайте коротко разберем, что же такое реверс-инжиниринг. Вы без труда можете найти определение в Википедии, но мне больше нравится то, что есть в Лурке :)

Некоторые слова в цитате пришлось заменить, так как в Лурке обычно пишут более экстравагантно — мат через мат.

Так вот, Reverse Engineering (ревёрсинг, обратная разработка) — это процесс «заимствования», восстановления исходников из конечного продукта инженерной и/или научной деятельности с интуитивным конструированием внутренней механики по принципу «а какие процессы должны вызвать такое внешнее поведение этого продукта?». Ориентируясь на нюх, так сказать. Иногда приводит к написанию собственного дока. Много их, ибо ваистену... © Lurkmore

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

Совет: никогда не пишите документы «просто, чтобы написать документы». Поставьте конкретную видимую цель и конкретный результат, которого хотите достичь. К примеру, вы хотите, чтобы прыжок вашего героя отлично ощущался с точки зрения контроля, например как в Super Mario Bros. Вы начинаете долгую разработку документации с тестированием с прототипами и т. д. Но что вы можете сделать вместо этого? Включить «Супер Марио» и проанализировать механику прыжка, выписать это все в документ и отдать в разработку. Важно понимать, что реверс нужно делать только тогда, когда вы точно понимаете, зачем он нужен, и только в случае, когда вы не делаете артхаус инди Death Stranding для эмуляторов андроид-устройств...

То есть, если вы делаете «Матч-3», то не выдумываете велосипед, вы идете играть в Candy Crush Saga или Homescapes и смотрите, как у них все работает. В данных проектах аудитория давно известна, и она привыкла к некоторым стандартным механикам игр «Матч-3». Если им предложить что-то «слишком уникальное», есть шанс, что вы отпугнете свою целевую аудиторию (ЦА). Я не говорю о том, что нужно создавать клоны, речь о грамотном анализе с целью сокращения вашего же времени при написании или создании общеизвестных игровых механик.

Зачем нужен Reverse Engineering

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

Разберем на примере. Вы делаете продукт из серии «Матч-3». Вам нужно понять, какие М3-элементы-«блокеры» необходимо вставить в начальный игровой цикл (самые важные для продукта 20–30 минут игровой сессии). Чтобы не отпугнуть пользователя и не сделать игру слишком простой или сложной, делать это нужно очень аккуратно. Поэтому вы можете потратить кучу ресурсов и человеко-часов на создание документации, прототипирование и анализ или «выписать» задачу для гейм-дизайнера на реверс-инжиниринг 3–5 топ-игр данного жанра. Впоследствии вы получите небольшую выборку по элементам типа «М3-блокер» для первых 30 минут игровой сессии и сможете на основании этих данных либо принять решение об интеграции какого-то из «блокеров» в свой продукт на ранних стадиях, либо будете анализировать дальше. В любом случае такой подход даст быстрый результат и сэкономит время.

Следующий пункт, который я хотел бы отметить, — «наигранность». В моем понимании этот термин означает то, насколько хорошо вы знаете продукты схожего жанра и рынок в целом, а также, как хорошо вы ориентируетесь в игровых механиках. Приведу пример из личного опыта. Мой телефон выглядит как игровая приставка, на нем установлены на текущий момент порядка 100–150 игр, все они отсортированы по жанрам, типам и т. д. Что я делаю каждую неделю, так это иду в App Store или Play Market, захожу в фичер и скачиваю все игры, которые показались мне интересными. Дальше минимум 30–60 минут играю в каждую из них. Во время игровой сессии я делаю быстрый поверхностный реверс. В случае, если нахожу интересную или уникальную, не известную мне до сих пор механику, начинаю углубляться в ее изучение.

Таким образом каждую неделю я развиваю «наигранность» и получаю личную базу с интересными и уникальными механиками, которые впоследствии могу воплотить в будущих проектах. Также понимаю, какие продукты вышли на рынок в последнее время, какие из них получили позитивные отзывы от ЦА и попали в фичеринг. По моему мнению, «наигранность» важна для любого человека, который занимается разработкой игр, особенно для гейм-дизайнеров, так как банально может случиться, что вы будете разговаривать с командой о продукте на разных языках.

Типы 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 с 7-й диагональю...

Как вы думаете, как скоро к вам прилетят «благодарственные» письма разъяренных игроков за такое «удобное» расположение кнопки? Уверен, очень быстро.

Небольшая ремарка по поводу «нужно ли делать реверс, а потом это имплементить в собственном проекте?». Короткий ответ: «Нет». Если вы где-то увидели пример реализации интерфейса, как я описал, поверьте, он не лучший. Думайте всегда своей головой, даже если в похожих с вашим продуктом играх есть аналогичный подход. Ваша игра — только ваша, и вам решать, какой в ней будет интерфейс. Конечно же, ваша задача как разработчика — сделать интерфейс как можно более удобным для максимального количества игроков, но не стоит бездумно гнаться за трендами и копировать неудачные кейсы. Всегда руководствуйтесь здравым смыслом и по возможности данными. Все вышеописанное касается софтового реверса интерфейса — того, что несет в себе технический характер. Все, что касается опыта пользователя от использования такого интерфейса, я отношу к реверсу «ощущений».

К последнему также я причисляю анимации, поведение кнопок или (ВАЖНО!) самого устройства. Приведу пример. Некоторые игры, в частности мобильная 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.