Некоторое время назад по геймдев каналам разошёлся список с интересными интервью представителей индустрии. Его основная идея: «хватит смотреть Ромеро и Кармака, есть другие замечательные дизайнеры и разработчики». Однако… список состоит в основном из мастодонтов индустрии: Сигэру Миямото, Тодд Говород, Хидео Кодзима и так далее. Кто о них не слышал? По сути мы не далеко ушли от «Ромеро и Кармака». Предлагаю список блогов, которые пишутся глобально менее известными людьми, но не менее эрудированными в своих областях.

На русском

• Анатолий Шестов (Executive Producer, Owlcat Games)

• Святослав Торик (Head of Game Design, Dragon Machines)

• Александр Номотеши (ex-Game Designer, Zeptolab)

• Василий Скобелев (Level Designer, Pixonic)

• Михаил Кадиков (Level Designer, Crytek)

На английском

Game Design

• Javier Barn (Product Manager, King)

• Matthew Gallant (Game Director, Naughty Dog)

• Harshal Karvande (Game Designer, Rovio)

• Eric Williams (Game Director, Santa Monica Studio)

• Emily Short (Narrative Designer, Sunless Sea)

• Daniel Cook (Chief Creative Officer, Spry Fox)

• Kynan Pearson (Creative Director, Discord)

• Raph Koster (ex-Chief Creative Officer, Sony)

• Keith Burgun (Game Designer, Indie)

• Soren Johnson (ex-Game Designer, Firaxis Games)

• Stephen Mortimer (Design Director, Riot)

• Stanislav Costiuc (ex-Game Designer, Ubisoft)

Level Design

• Dave Johnston (ex-Level Designer, Valve)

• David Shaver (Level Designer, Blizzard)

• Michael Barclay (Level Designer, Naughty Dog)

• Jared Mitchell (Level Designer, Life is Strange: True Colors)

• Andrew Yoder (ex-Level Designer, Warframe)

UX Design

• David Candland (UX Design Director, WB Games)

• Matt Butler (UX Design Director, Activision)

• Celia Hodent(ex-UX Design Director, Epic Games)

Приятного чтения / просмотра!

У некоторых значится «ex-» должность. Я не стал писать их текущую позицию, ведь кто-то ушел из индустрии, стал независимым или просто не говорит где работает… поэтому выбрал одну из самых «высоких» должностей, которую авторы занимали.

Game Development

difficulty: medium

Начнём с книг, которые имеют прямо отношение к разработке игр. В них не так много математики, написаны они просто, и имеют самое прямое отношение к гейм-дизайну.

• Игровой Баланс (Ian Schreiber) — единственная книга [известная мне], полностью посвященная балансу: транзитивность, кривые стоимости, системы рейтинга и многие другие умные слова отлично раскрываются на её страницах. Для закрепления знаний используются упражнения. Более того, последняя часть книги полностью посвящена таблицам — крайне важному инструменту гейм-дизайнеров.
  Более подробно про книгу.

• Virtual Economies: Design and Analysis (Vili Lehdonvirta & Edward Castronova) — книга с углублением в тему экономики с примерами из EVE Online. Автор лично работал над EVE, а также является профессор экономической социологии и цифровых социальных исследований в Оксфордском институте. К сожалению, в книге больше воды, чем в первой, но, тем не менее, интересные идеи и концепции можно найти.
• Игра в цифры (Василий Сабиров) — книга не про гейм-дизайн, а аналитику, но аналитика и баланс всегда идут рука об руку, ведь без неё практически невозможно узнать, а работает ли ваш теоретический баланс в реальной среде и как правильно скорректировать его на основе данных. Data-driven [-oriented] подход — наше всё.
  Неплохая выжимка.
  

Научно-популярная литература

difficulty: easy

К сожалению (или счастью), баланс строится на математических моделях, а они, как следует из термина, на математике. Многие не любят читать учебники по ней и разбираться в её тонкостях. На помощь здесь приходит научпоп. Он не уходит в глубины доказательств, но при этом даёт необходимые базовые знания.

• Серия «Образовательная Манга» — коллекция про статистику, тервер, машинное обучение и всё-всё. В каждой из них есть уникальный сюжет, который проводит нас через весь материал. Вдобавок есть упражнения и выкладки с доказательствами для особо интересующихся читателей. В моих заметках частенько можно встретить вырезки из данной серии.
• Математика с дурацкими рисунками и Математический анализ в безумном мире (Орлин Бен) — две книги, которые описывают концепции из школьной алгебры и начала матанализа с «дурацкими рисунками» [хотя я считаю их прекрасными]. Знание матанализа совершенно не обязательно для хорошего дизайнера, но иногда понимание производной помогает для анализа функции, а интеграла для сложных расчетов (которые, впрочем, вероятно можно выполнить и другими способами).
• Игра случая (Джозеф Мазур) — когда-нибудь слышали задачу о печатающей обезьяне? В ней спрашивается: сможет ли обезьяна (если дать ей сколько угодно времени), нажимающая случайным образом на кнопки клавиатуры компьютера, написать первую строку из сонета Шекспира? Книга расскажет о нескольких подобных увлекательных задачах в виде историй. Они, в свою очередь, затрагивают закон больших чисел, теорию скрытых переменных и закон действительно больших чисел — эти знания вам точно пригодятся в работе.
• Статистика и котики (Владимир Савельев) — справочник по статистике с простыми примерами. Как мне кажется, данный материал не стоит читать как учебник, потому что всё очень поверхностно и бегло. Никаких упражнений и доказательств, голые факты.
• Как лгать при помощи статистики (Дарелл Хафа) — классическая книга, которая учит критически подходить к статистическим данным и их интерпретации. Несмотря на провокационное название, она показывает, как данные могут быть представлены так, чтобы вводить в заблуждение или формировать определённый нарратив. Для гейм-дизайнеров это особенно полезно: вы сможете корректно показывать игрокам информацию [причём определение корректности каждый может определить для себя сам], а также правильно интерпретировать аналитические данные, избегая ошибок в работе с игровыми метриками.
  Обзор всей книги.
  

Портал в Data Science

difficulty: medium

Коллегам, занимающимся Data Science, тоже часто приходится опираться на статистику, так почему бы не почитать то, что читают они?

• Доверительное АB тестирование (Кохави Р., Тан Д., Сюй Я.) — гейм-дизайнерам часто приходится работать с A/B тестами: проводить эксперименты, следить за их корректностью и делать выводы. Культура A/B тестирования достаточно сложна, и, чтобы избежать базовых ошибок, стоит ознакомиться с этой книгой. Она поможет лучше понять, как правильно сетапить эксперименты, интерпретировать результаты и учитывать все нюансы.
• Практическая статистика для специалистов Data Science (Питер Брюс, Эндрю Брюс, Питер Гедек) — эта книга станет отличным пособием для тех, кто хочет глубже разобраться в основах статистики, необходимых для работы с данными, но не уходить в дебри. Авторы наглядно объясняют ключевые концепции на базовом уровне: от анализа данных и визуализации до проверки гипотез и машинного обучения.
• Заставьте данные говорить (Алексей Колокольников) — гейм-дизайнерам нередко приходится визуализировать данные, будь то для внутреннего анализа, общения с коллегами или демонстрации игрокам. Эта книга поможет научиться строить понятные, информативные и эффектные графики, избегая визуального "шума".

Учебники

difficulty: hard

Если вы хотите хардкора, то можно обратиться к настоящим учебникам. Если первые главы будут понятны большинству, то для оставшихся необходимы начальные знания математического анализа. Личные рекомендации:

• Письменный Д.Т., Конспект лекций по теории вероятностей и математической статике.
• Гмурман В.Е, Теория вероятностей и математическая статистика.
• В. Феллер, Введение в теорию вероятностей и ее приложение в двух томах.

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

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

Онлайн

difficulty: custom

В эпоху интернета было бы глупо не воспользоваться его дарами.

• Математика в геймдизайне от dev2dev — онлайн курс, который покрывает необходимый минимум.
• GDC — самая большая конференция разработчиков видеоигр в мире. Море полезного контента, в частности по балансу и экономике. Мои любимые доклады:
• Slay the Spire: Metric Driven Design and Balance
• Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3
• Balancing the Economy for Albion Online
• Machinations — веб-инструмент для симуляции игровых систем, но у разработчиков есть ютуб канал. На нём периодически проводятся вебинары с приглашенными гостями, например, с Шрайбером про 4X and Abstraction in Game Design. На семинарах не стоит надеяться увидеть или услышать идеальную формулу баланса, но на них определенно можно найти новые подходы к дизайну или концепции.

Задачники

Пришло время готовиться к собеседованию. Где же это делать?

• Открытые тестовые. Таких можно найти очень много, например, вот тут.
• Dungeons of Probability — небольшая игра, в которой надо решать простые задачки на теорвер.
• Мостеллер Ф., 50 занимательных вероятностных задач с решениями — сборник задач на тервер. Говорят, что если прорешать все задачи из сборника, то любое тестовое покажется пустышкой. На самом деле почти так и есть, потому что идей решения задач на теорию вероятностей с дискретными случайными величинами не так уж и много, а другие дают редко.

Заодно можно открыть любой из учебников и прорешать задачки оттуда. Обычно они интереснее тех, что дают на тестовых (по очевидным причинам).

Заключение

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

• Математический анализ — чтобы разобраться в дифференциальном и интегральном исчислении, что может быть полезным при анализе сложных игровых экономик.
• Линейная алгебра — для работы с системами линейных уравнений и понимания таких фундаментальных понятий, как векторы, матрицы и операторы.
• Дискретная математика — для более глубокого погружения в комбинаторику, например, изучение чисел Каталана, Стирлинга, Белла и других концепций может значительно упростить решение некоторых задач.

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

Вы прочитали всё?

• https://education.yandex.ru/journal/matematika-v-data-science
• https://habr.com/ru/articles/541064/
• https://blog.skillfactory.ru/knigi-analitiku-dannyh/

Наконец-то добрался до непрочитанных книг про разработку игр: «История Серии Zelda», «Hey, Listen!», «Mass Effect: восхождение к звездам». В основном они состоят из многочисленных интервью и забавных историй, и почти не затрагивают процессы разработки. Лишь малая часть содержания посвящена анализу: почему было сделано так, а зачем было сделано это, чего хотелось добиться этим... Ответов на эти вопросы почти нет, поэтому я практически потерял желание читать такие книги. Вот добрался до последней, надежды на что-то хорошее почти не осталось. И о чудо, я ошибся! Это была «DOOM. Как в битвах с демонами закалялся новый жанр».

В SCARYDARKFAST в разы больше рассуждений на тему гейм-дизайна и около. Многие вещи подкинули мне почву для размышлений. Начнём с цитаты Кевина Клауда, которая идеально описывает, каким должен быть шутер:

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

Документация

В начале разработки Том Холл создал «Библию DOOM». Своего рода концепт док игры. Он содержит много полезной информации и описаний, задающих тон игры. Как мне кажется, устанавливать такие «правила» на раннем этапе разработки крайне полезно, потому что в дальнейшем помогает быстро отсекать бредовые идеи.

Также в документе стоит выделить две полезные секции, о которых порой забывают:

1. Глоссарий. Команда должна общаться на одном языке, и он должен быть зафиксирован;
2. Random Extremely Important Info Too Small To Rate Having Its Own Section. Немного дополнительных сведений, которые могут лишь косвенно влиять на производство, например, время работы и номер ближайшее пиццерии, но при этом улучшать его.

Враги

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

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

• Зомби — рядовой враг / массовка;
• Барон ада — танк / босс;
• Потерянная душа — раздражитель / камикадзе;
• Какодемон — летающий.

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

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

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

Подробный разбор оружия и врагов от Джоржа Белла.

Дизайн Пространства

Игрок и монстры должны где-то сражаться, а именно на аренах. Основные правила дизайна уровне освящены в John Romero's Level Design Rules. Не буду повторяться, поэтому рассмотрим другие не менее интересные моменты.

E3M6 «Mt. Erebus» — первая карта, которая идеально подходит для режима deathmatch. Её создатель, Тим Уиллитс, говорит следующее:

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

Как не самый опытный дизайнер уровней, взял себе этот подход на заметку.

А вот так выглядит E3M2 «Slough of Despair»:

Начинаешь невольно задумываться, а что если дизайнеры матч-3 стали делать уровни в виде силуэтов после игры в DOOM?

Какие же отношения выстраиваются между игроком и пространством? В DOOM игрок находится в реактивных отношениях с ним, а не в проактивных, как, например, в Far Cry (Proactive vs Reactive Combat). Таким образом, в проактивных играх игровой процесс несколько замедляется из-за тактических элементов: какое оружие взять, что выкинуть из инвентаря, как напасть на врага. В DOOM хотелось всё это минимизировать, поэтому, например, в игре нет перезарядки.

Все прятки нужно было убрать. Если я могу пригнуться или укрыться за чем-нибудь и впитывать урон как губка, то зачем вообще учиться играть? Где здесь вызов? Я начинал с аркадных автоматом, а там скорость — это всё.

Вот что говорит Ромеро по поводу динамики игры.

Серия прогрессировала, а вместе с ней и правила. Так в DOOM 2016 можно столкнуться с «математически выверенными» аренами, их математика заключается в том, что если игрока прижмут к стене, у него должны оставаться один-два варианта для отступления и маневра. Появляется двойной прыжок и механика добиваний, так игра провоцирует вас бежать и убивать врагов всё больше и больше. Враги же в свою очередь стараются сократить дистанцию до игрока, чтобы нанести сокрушительный удар. Всё движется!

Заключение

Конечно же, я покрыл не весь материал книги, а лишь выдернул самые яркие для себя моменты. Возможно книга получилась такой интересной, потому что автор – учёный-искусствовед, который в своей научной диссертации анализировали FPS, а ещё он креативный директор The Chinese Room (Dear Esther, Everybody's Gone to the Rapture). Так, если кто-то думал брать или не брать книгу, то смело берите. Хотя со своими советами я опоздал на пару лет... но лучше поздно, чем никогда.

Кто такой Чен? Дизайнер, который когда-то работал в Activision, где и придумал данный подход. Во время анализа чужих игр (чем он и занимался в рабочее время) он понял, что значимость фичи надо измерять совместно с другими фичами, то есть измерять влияние одной фичи на другие.

Так сформировался принцип: «Любая фича в игре ценна только в той мере, в какой она влияет (или находится под влиянием) на другие фичи игры». Ключевой идеей здесь является концепция «влияния». Одна фича находится под влиянием другой только в том случае, если она каким-то образом задействуется её.

Введем следующие обозначения:

• => влияние одной фичи на другую;
• <=> совместное влияние.

Например, если в игре можно убивать монстров, чтобы получать экспу, чтобы становиться сильнее, чтобы убивать более классных монстров, получаем: Комбат => XP => Прокачка => Комбат. Более простой пример: если мир вокруг изменяем, то он подвержен влиянию, например, в Minecraft: Инструменты => Мир, иначе система мира не находится под влиянием (но может влиять!)

Попробуем изобразить всё это в виде диаграммы, а не кор-лупа (или любого другого лупа). Каждая фича — прямоугольник, связи — стрелки.

Полная диаграмма выдуманной Action / Adventure игры (почти как Ratchet and Clank):

Получается, что чем больше стрелок указывает на какой-либо блок, тем важнее этот блок для общего дизайна. Интересная особенность этой диаграммы заключается в том, что, взяв общее среднее число ссылок на фичи (количество линков, разделенные на количество фич), получим отношением ссылок к фичам или просто Links-to-Features / score. Это число является показателем того, насколько связаны между собой ваши функции. Перефразировав принцип, озвученный выше: чем больше LtF, тем лучше. Точно так же для «категорий» фич можно посчитать LtF, чтобы определить, какие части вашей игры вносят наибольший вклад. Например, LtF категории «world» — единица (не фичи!).

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

Так суть всего этого процесса просто понять, а насколько связаны ваши системы и нет ли чего-то «просто так». Ведь на любое «просто так» сжигаются ресурсы (материальные, человеческие, креативные, etc).

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

1. Бессмысленно выделять прокси ресурсы или производные, потому что это просто +1 фича и +1 линк. Например, в оригинале был Level от XP, но ведь Level — это просто более удобный вид представления XP;
2. Стрелок получается очень много, поэтому имеет смысл рассматривать системы на разных уровнях. Например, бой можно рассмотреть более детально и понять, какие механики внутри него более значимые, а какие менее;
3. У экономических систем заведомо больше LtF, так как связей банально больше, чем у мировых, поэтому сравнивать их между собой не совсем корректно;
4. Имеет смысл разделять действия и ресурсы на 2 группы поменьше: core и meta, чтобы отслеживать всё по отдельности (см. пункт 2);
5. Наличие большого LtF — не залог успеха, это простой большой LtF.

Кстати, в оригинале диаграмма называется «Chen Diagram», но это название уже забито за особой диаграммой для баз данных, поэтому пусть будет диаграмма LtF.

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

Небольшая математическая вводная, которая необходима для плодотворного диалога:

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

Например, y = x^2 - 5x + 25 — функция и полином второй степени.

Теперь можно переходить к сути.

Интерполяция

Предположим, что мы делаем простенький point-and-click. Игрок сейчас находится в точке A, и щелкает в B. Как плавно его переместить из A в B? Необходимо построить какую-то функцию, которая обязательно проходит через точки начало и конца и находит значения между ними. Вот и есть простой пример интерполяции.

Интерполяция — приближенное нахождение промежуточных значений между известными.

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

1. (0, 1);
2. (1, 1);
3. (2, 0.5);
4. (3, 0.3).

Если применить метод линейной интерполяции, то получится ломанная:

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

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

Полезные видео по интерполяции и чуть более углубленно, почему оно работает так:

1. Lagrange Interpolation
2. Cosine Interpolation
3. The Beauty of Bézier Curves

Вот, вы когда-нибудь задумывались что такое Lerp и Slerp в Unity? Это же просто Linear Interpolation и Spherical Linear Interpolation.

Экстраполяция

Методы экстраполяции во многих случаях сходны с методами интерполяции, но их основная задача кардинально отличается.

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

Например, мы делаем мультиплеерный FPS шутер. Игрок находится в позиции X и нажимает кнопку "W" в течение последней секунды. Можно предположить, что он будет продолжать это делать в следующую секунду, потому что это наиболее частое поведение в нашей игре, поэтому можно экстраполировать положение, в котором он будет в следующем кадре.

Ещё несколько полезных ссылок:

1. Интерполяция и экстраполяция на примере Planteside 2
2. Using Pre and Post Extrapolation in Timeline (Unity)
3. Серия из 4 статей про мультиплеер в быстрых играх (перевод)

Аппроксимация

Аппроксимация — приближенное представление сложной функции более простой, имеющей минимальное отклонение от исходной.

Такую операцию можно легко сделать в Google Sheets / Excel:

1. Выбираем необходимый диапазон данных;
2. Строим по этим данным диаграмму;
3. Включаем линию тренда в настройках диаграммы.

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

Выбора типа линии остаётся за исследователем, также как и особые настройки конкретного типа (например, порядок полиномиального приближения).

Два важных свойства линии тренда:

1. Ярлык > уравнение покажет уравнение функции, что в последствии можно (и нужно) использовать;
2. R2 (Коэффициент детерминации) — значение, которое измеряется от 0 до 1 и показывает, как хорошо линия тренда описывает имеющиеся значения.

Уходить в регрессивный анализ не хотелось бы, потому что это требует отдельной заметки (ха-ха, серии лекций в курсе математической статистики). Однако вот базовая статья.

По итогу получается вот такой график:

Коэффициент детерминации — единичка, значит функция проходит через все имеющие точки и может заодно выступать интерполяцией. Если задуматься, то на самом деле получился просто «приведенный» полином Лагранжа.

Рассмотрим другой пример, пусть наши точки имеющие следующие координаты:

1. (0, 1);
2. (1, 2.05);
3. (2, 2.9);
4. (3, 4.1).

Если приглядеться и подумать, то они практически образуют линейную зависимость. Метод Лагранжа естественно выдаст полином 3 степени, а вот аппроксимировать можно линейно, тогда R-квадрат будет 0.93. В точности почти не теряем, но выиграем за счет значительного упрощения функции.

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

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

PS Как можно было догадаться, интерполяция и экстраполяция — особые виды аппроксимации.

Заключение

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

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

Напоследок:

1. Интерполяция — внутри;
2. Экстраполяция — вовне;
3. Аппроксимация — примерно везде.

• UX Flow — абстрактная карта экранов и связей между ними с возможными действиями юзера / системы;
• Wireframe — черновой экран;
• Карта экранов — связанные wireframes.

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

1. Как составлять User Experience Flow
2. Карта экранов в разработке игрового интерфейса
3. Инструментарий для ГДД

К сожалению, очень часто предлагается использовать разные инструменты под каждый из пунктов, мол накидывать экран в Balsamiq, а карту экранов или флоу в Miro. Однако, как показывает практика, чем больше инструментов и всяких проектов в них, тем сложнее что-то найти и связь вместе. Именно поэтому в своей рабочей практике я использую Figma и всё делаю там. Сейчас расскажу, как это происходит и какие есть хитрости.

Подготовительные работы

Регистрируемся, создаём пустой проект, а в нём 3 страницы:

1. Flow — тут будет наш UX Flow;
2. Wireframes — мокапы экранов и карта экранов;
3. References — рефы UI.

К сожалению, в бесплатной версии Figma это лимит. Можно отказаться от References и заменить их на User Interface, где будут финальные версии экранов, отрисованные художником. Другой вариант — купить премиум подписку.

Всё, что ещё нужно уметь делать в Figma:

1. Создавать фигуры (квадрат, круг) — иконка квадратика в верхнем баре;
2. Создавать текст — буква «T» в верхнем баре.

Flow

В каждой студии под флоу понимается что-то своё и частенько состоит из разных логических блоков, я выделяю следующие:

1. Процесс — начало игры, геймплей, любая другая игровая активность;
2. Экран — что-то, что видит игрок и как-то может переходить на соседние экраны;
3. Проверка — системная проверка, например, первая ли это игровая сессия за день.

Предположим, что мы делаем Archero 2.0:

1. Расширилась легенда: появились обозначения стрелок от условия;
2. Обрисовался начальный флоу:
1. Если новый игрок, то запустить тутор. Иначе главный экран;
2. С главного экрана можно перейти в геймплей при наличии достаточного количества энергии. Если нет, то предложить докупить энергию;
3. После геймплея всегда открывать результаты.

Wireframes

После флоу можно переходить на уровень ниже, то есть прикидывать экраны.

Перед этим процессом хорошо бы изучить рефы и заполнить соответствующую страницу, чтобы не изобретать велосипед:

Wireframes также создаём с помощью Frame, но теперь имеет смысл выбрать конкретный размер из предложенного списка:

Frame называем так, как называется экран на Flow.

На фрейм набрасываем кнопки, бары, иконки, всё что нам надо. Главное не переборщить.

Как только экран готов, желательно объединить элементы внутри него в группы, чтобы в случае чего их было проще выключать / включать, перемещать, увеличивать, etc.

Screens Map

Карту экранов будем делать непосредственно на странице с wireframes, причём она сразу же будет и интерактивным прототипом.

1. Выбираем Prototype в настройках вместо Design;
2. Выделяем нужную кнопку на экране;
3. Создаем связь между кнопкой и нужным экраном;
4. Определяем настройки перехода, например, полный переход на экран или оверлей.

Пока будет включен режим прототипа, то будут отображаться все связи, которые и отражают карту экранов:

У одного экрана может быть несколько состояний, например, у главного: достаточно энергии для старта геймплея или нет. В таком случае имеет смысл прокинуть между ними «чит» и обозначить, что он не доступен игрокам.

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

Более того, теперь можно запустить кликабельный прототип через кнопку «Present»:

Заключение

Figma — крайне удобный инструмент, потому что:

1. Можно создавать несколько страниц в одном прототипе;
2. Есть возможность строить как флоу, так и накидывать сами экраны;
3. Доступен функционал объединения экранов в карту и кликабельный прототип.

К тому же, иногда Figma упрощает диалог с UI/UX дизайнером. Как и у любого инструмента, у неё есть свои минусы, например, не очень удобные стрелки на этапе UX Flow. Однако небольшие минусы часто чинятся плагинами от сообщества, которых очень много.

Полезные ссылки для дальнейшего изучения:

1. Как улучшить организацию проектов в Figma
2. Intro to Figma - Beginners guide to Figma Basics
3. How to Create Game Prototypes in Figma

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

Продюсер, дизайнер и проект выдуманные.

I. Неожиданные кнопки

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

Дизайне подметил, что большинство игроков:

1. Не покупают ничего;
2. Не смотрят офферы, а просто закрывают их.

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

Опа! Вот и первые успехи. Парочка игроков попалась.

II. Отрицательная скидка

Раз игрок «случайно» покупает оффер, то почему бы не сделать его необычным? например, отрицательным?

III. Умный ежедневный бонус

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

Элементы экрана:

• Ввод дня осуществляется посредством слайдера;
• Если была нажата кнопка «idk», выдать награду дня.

Проверка введенго дня:

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

Элементы экрана «поражения»:

• Если была нажата кнопка «Watch AD», показать рекламу, восстановить прогресс и выдать награду дня;
• Если была нажата кнопка «Ignore», выдать прогресс первого дня.

IV. Платная реклама

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

1. Увлекательное занятие;
2. Даёт различные бонусы.

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

V. Умная реклама

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

• Если игрок ответил правильно, то просмотр рекламы засчитывается;
• Иначе предлагается посмотреть рекламу ещё раз на тех же условиях, в случае отказа просмотр не засчитывается.

Заключение

Вот и всё! Пять «гениальных» фич, которые повысили доход проекта в раз и он даже превзошел Diablo.

Конечное же, всё это шутки и сатира. Это совершенно ужасные примеры, которые ни к чему хорошему не приведут. Пожалуйста, не делайте так.

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

Тут нам на помощь и приходит такой вид графика, потому что с его помощью легко визуализировать набор характеристик сущности и в последствии использовать для сравнения.

Подготовительные работы

Пусть в выдуманном проекте буду роботы (кхе-кхе, это уже классика примеров, надо придумать что-то ещё), у каждого из которых есть статы:

1. HPs — здоровье;
2. DEF — защита;
3. SPD — скорость;
4. DMG — урон;
5. DEX — ловкость.

Выделяем нужные значения и строим лепестковую диаграмму:

Однако есть огромная проблема. У величин разные максимальные и минимальные значения, то есть DMG может быть в один пределах, а SPD в совершенно других. В случае примера:

1. HPs: [50; 100];
2. DEF: [10; 200];
3. SPD: [1; 10];
4. DMG: [100; 1000];
5. DEX: [1; 10];

Соответственно, если оставить всё как есть, то график будет выглядеть криво, так как DMG будет всегда выделяться, а SPD и DEX будут совершенно незаметны. Следовательно, надо перейти к относительными величинам. Будем считать, какой % составляет каждая из величин от её отрезка допустимых значений:

value - minValue / maxValue - minValue

• value — конкретное значение величины;
• minValue — минимальное значение, например, у DEX оно 1;
• maxValue — максимальное, например, у SPD оно 10.

Например, если HPs = 75, то его относительно значение - 50%.

Как определять минимальное и максимальное значения остается на откуп дизайнера. В примере они заданы ручками, а можно, например, искать минимум и максимум каждой из величин среди всех сущностей.

Теперь в таблице есть 2 листа:

1. Robots. Содержит роботов, у каждого есть брат, который отражает относительные значения величин.
2. Stats. Содержит статы.

Если инженеры должны делать гибкий код, то дизайнеры — гибкие таблицы, поэтому было сделано следующее:

1. Именованный диапазон характеристик StatsData;
2. Дублирующие данные диапазона StatsData на листе роботов через =ТРАНСП(StatsData), так как данные используются для расчета относительных значений, а огромное число =VLOOKUP не очень хорошо;
3. Общая формула для расчета всех относительных значений, =ARRAYFORMULA(ЕСЛИ(D6:6 > 0; ОКРУГЛ((D6:6 - D$2:$2) / (D$3:$3 - D$2:$2); 2); "")), то есть мы считаем не каждую характеристику по отдельности, а берем всю строку и делаем с ней одинаковые действия, а именно:
1. Проверяем, что абсолютные значения больше 0;
2. Если всё ок, то считаем какой процент составляет каждая из характеристик из соответствующего ей диапазона;
3. Иначе пустая строчка.
4. Специальное выделение для столбца ID, так как оно считается само;
5. Особое обозначение имён дополнительных роботов, начинающиеся с «#».

Важные моменты:

1. Специальные выделения стоит фиксировать, например, в условном Sheets Style Guide;
2. Особое символы дублирующих или расчетных данных также стоит фиксировать;
3. Всё это было сделано лишь для того, чтобы при добавлении/удалении характеристики ничего не могло сломаться;
4. Дополнительные данные по-умолчанию скрыты;
5. На абсолютные значения были накинуты кастомные проверки вида =ЕСЛИ(И(C4 >= C$2; C4 <= C$3); 1; 0), то есть значение должно попадать в отрезок допустимых.

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

Построение диаграммы

Подготовительные работы завершены. Теперь построим сводную таблицу, где будут только необходимые значения, то есть отфильтруем все данные с диапазона роботов: будем использовать только те, что начинаются с "#". Далее выделяем данные и строим лепестковую диаграмму.

По настройкам диаграммы:

1. Строки/столбцы включены (в нашем случае);
2. Сглаживание отключено в стиле диаграммы.

Готово! У нас есть диаграмма, через которую мы можем сравнивать роботов или смотреть на их характеристики в более удобном виде.

Power

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

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

Каждый треугольник образуется двумя соседними характеристиками, например, HPs и DEF. Его площадь посчитаем по формуле двух сторон и угла между ними:

1. Синус угла находим через количество характеристик N. =SIN(РАДИАНЫ(360/N)), так как весь круг, то есть 360° разбивается на N равных частей;
2. Стороны — значения характеристик;
3. Перемножаем величины из предыдущих пунктов, делим на два, получаем площадь одного треугольника. Осталось так сделать с каждыми соседними характеристиками, то есть треугольниками.

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

В процессе проценты стали просто числами, но сути это не меняет. Теперь точно всё!

Таблица доступна по ссылке.

Определенно в таблице есть минусы, например, отсутствие истории обновлений, фильтра по роботам и так далее... но идея раскрыта.

Заключение

Знание о существовании такого вида диаграммы может пригодиться, потому что она сильно упрощает визуализацию характеристик и мощи сущности. Игрок может бегло посмотреть на диаграмму и понять, какие есть слабые / сильные стороны у объекта или в чём он уступает другому объекту.

Однако, у неё есть определенные минусы:

1. Наличие большого количества переменных создает много осей, что делает диаграмму сложной для восприятия;
2. Нахождение нескольких сущностей на одной диаграмме делает ее трудночитаемой, поэтому обычно используют не более 3;
3. Трудности могут возникнуть при сравнении значений на разных осях, поскольку они могут иметь различную шкалу абсолютного измерения и вносить разный вклад в настоящую эффективность сущности, даже несмотря на то, что в примере мы их нормализовали.

Примеры в реальных проектах:

Примеров ещё много: PUBD, FIFA, Stellaris, Tennis Manager, Captain Tsubasa, etc. В некоторых из них, например, в Wild Rift, используется как отображение стиля игры игрока.

Теперь точно всё! Графиков сегодня было много, самое время поиграть в какой-нибудь тайкун, где их будет не меньше, например, в Cartel Tycoon.

Сюжетный бизнес-симулятор Cartel Tycoon вдохновлен историей наркоторговли в 80-х годах. Расширяйте свою сеть и поглощайте другие, не привлекая внимания конкурентов и властей.

by Chaotic Game Design

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

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

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

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

1. Missions - таблица миссий
2. Locations - таблица локаций
3. Enemies - таблица врагов
4. Behaviours - таблица поведений

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

1. Таблицы - mind maps (в случае Miro)
2. Столбцы (или строки?) таблицы - ветви mind map
3. Зависимости - стрелки с указанием от чего к чему и что вписывать
4. Около карт ещё удобно оставлять заметки, чтобы подсветить наиболее важные и неочевидные моменты

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

Кстати, минутка интересных фактов из мира математики. Самая первая карта в заметке покрашена в 4 цвета не просто так - именно этого количества цветов достаточно, чтобы никакие соседние области не имели одинаковой раскраски. Подробнее про теорему (да-да, это теорема) можно почитать в википедии, а прикладную часть вот тут. Если кто-то вдруг очень заинтересовался, то рекомендую к прочтению книгу профессора Стюарта «Невероятные Числа» (Professor Stewart's Incredible Numbers). Каждая глава книги посвящена какому-то числу, так в главе 4 (про число 4 соотвественно) поднимается и эта теорема.

Кто куда, а я пойду играть в Mini Metro. Буду считать, что станции - это конфиги, перегрузку которых нельзя допустить, а пассажиры - новые дизайнеры на проекте, которые и пытаются разобраться во всех тонкостях местных таблиц.

Источник примера ERD

by Chaotic Game Design

Например, как-то раз я видел сон, в котором начинающий дизайнер начал строить таблицу с середины листа. Таблицу естественно он переименовывать не стал, ведь всем очевидно, что «Новая Таблица 0456» — это та самая таблица.

Сразу за этим последовало прекрасное форматирование:

1. Яркая заливка ячеек;
2. Модные шрифты;
3. Разный кегель.

Задача на день была простая: сравнить эффективность роботов (не будем уходить от классики). Урон и здоровье каждого известны. Формула знакома каждому джуну — просто перемножаем величины, чтобы получить мощь.

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

Ох, точность и класс робота были забыты! Ничего, сейчас всё будет исправлено. Точность (Accuracy) измеряется в проекте от 0 до 1, и есть 3 класса: Light, Medium и Heavy. В зависимости от класса конечная мощь умножается на определенный коэффициент, а урон умножается на точность.

В спешке автор сокращает Accuracy до ACR, ведь какая разница, а на поля не вешает валидацию, ведь зачем оно надо? ошибок то не будет! Хотя, если приглядеться, то можно заметить, что в ACR проскочила двойка (G9), а в Class какой-то новый класс (I14). Формула расчета стала больше, может быть стоило разделить её на несколько строк? Ну, нет, еще терпит. Роботов, кстати, тоже стало больше, но закреплять строку автор не решился. Да и тем более, она по середине листа.

Переход к заключительному этапу — сравнению мощностей. Это было решено сделать через относительное сравнение каждого робота с самым мощным. Сказано — сделано.

Наш персонаж находит максимум (на всякий еще и минимум) через стандартные функции, применяя их к диапазону. Можно было бы использовать именованные диапазоны (named ranges), но это как-то сложно непонятно да и зачем? Диаграмма строится по щелку пальца, кажется, что видоизменять её смысла нет, всё легко читается.

Потребовалось сравнить легких роботов. Было решено создать дополнительный лист, который называется «Лист2», а на нем своего рода сводную таблицу.

1. С «Лист1»перетащить нужные данные с помощью =ARRAYFORMULA;
2. Создать столбец Flag, который проверят, что класс равен легкому;
3. Пересчитать Result;
4. Покрасить всё в модные цвета.

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

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

1. Адекватные названия листов;
2. Простое форматирование;
3. Отдельные листы для важных сущностей/абстракций, например, классов;
4. Понятные формулы и примечания к ним.

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

Таким образом, я использовал:

1. Закреплние строки;
2. Проверку данных в нужных столбцах;
3. Именованные диапазоны в формулах;
4. Филтр.

Кстати, проверка данных подсветила ошибки. Фильтр же просто частенько может пригодиться, для него я ещё специально сделал столбец ID.

Далее создал сводную таблицу через заложенный функционал, поэтому, например, её форматирование не было изменено. Многие привыкли к такому, поэтому пусть так и будет.

Заодно я разделил листы по цвету и листу со сводной таблицей приписал PT (Pivot Table), но что же такое Update Log? Это просто лист, в котором удобно обозначать изменения, которые были внесены в таблицу. Если в офлайн конфиге всё можно отследить через VSC (при условии, что команда пишет вменяемы коммиты), то тут чуть сложнее.

На этом у меня всё! Кстати, я сам мог допустить где-то ошибки и/или что-то сделать лучше, но это всё было сразу после сна :D

Таблицы можно посмотреть тут.

Любите таблицы и уважайте своих коллег.

Во что же можно поиграть? Я мог бы посоветовать EVE Online, но это слишком банально. Кажется, что Stardew Valley — идеальный кандидат на роль игры, в которую можно играть и параллельно заполнять таблички, чтобы научиться лучше с ними работать. Вот у какого растения лучший ROI в игре?

Полезные материалы:

• Как удобно вести игровой баланс и не сломаться от количества ячеек в таблицах
• Google Sheets для геймдизайнера
• Practical tips on technical Game Design Documentation (Part 3)

PS Сон и проект естественно выдуманные.

by Chaotic Game Design