Примечание: полный исходный код этого проекта можно найти [здесь]. Так как он является частью более масштабного проекта, я рекомендую смотреть коммит на момент выпуска этой статьи, или файл /source/helpers/arraymath.h, а также /source/world/blueprint.cpp.

В этой статье я хочу подробно рассказать о принципах использования цепей Маркова и статистики для процедурной генерации 3D-зданий и других систем.

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

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

Игры FPS (first-person shooter, шутер от первого лица) стали неотъемлемой частью видеоигровой индустрии ещё с момента появления в 1992 году популярнейшей Wolfenstein 3D. С тех пор жанр эволюционировал: улучшалась графика, увеличивались бюджеты на разработку, развивалась экосистема киберспорта. Но что насчёт их фундамента — механики стрельбы? Как проходило развитие на этом фронте? Почему в некоторых играх оружие кажется реальными, а в других похоже на игрушки?

Hitscan

В предыдущую эпоху многие игры для рендеринга 3D-сцен в 2D-изображения использовали технику под названием raycasting («бросание лучей»). Raycasting позволяет движку определять первый объект, с которым пересечётся луч. Но потом разработчики задались вопросом: «Что, если выпустить луч из ствола оружия, чтобы имитировать пулю?» Благодаря этой идее родился hitscan («сканирование попадания»).


Пример raycasting

В большинстве реализаций оружия с hitscan при выстреле игрока физический движок выполняет следующие операции:

• Определяет направление, в котором указывает оружие.
• Выпускает из ствола оружия луч на заданное расстояние.
• Использует raycasting для определения того, попал ли луч в объект.

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

Примечание: полный исходный код этого проекта выложен здесь: [source].

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

После выпуска первоначального концепта Task-Bot [перевод на Хабре] я почувствовал, что меня ограничивает двухмерное пространство, в котором я работал. Казалось, что оно сдерживает возможности емерджентного поведения ботов.

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

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

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

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

В этом посте мы рассмотрим этап работы с вершинами. То есть нам придётся снова достать учебники по математике и вспомнить линейную алгебру, матрицы и тригонометрию. Ура!

Мы выясним, как преобразуются 3D-модели и учитываются источники освещения. Также мы подробно объясним разницу между вершинными и геометрическими шейдерами, и вы узнаете, на каком этапе находится место для тесселяции. Чтобы облегчить понимание, мы используем схемы и примеры кода, демонстрирующие, как в игре выполняются вычисления и обрабатываются значения.

На скриншоте в начале поста показана игра GTA V в каркасном (wireframe) режиме отображения. Сравните её с намного менее сложным каркасным отображением Half-Life 2. Изображения созданы thalixte при помощи ReShade.

Кто: Гвенаэль Массе, художник студии Motion Twin

Привет, меня зовут Гвенаэль Массе, мы с Тома Вассё — единственные художники инди-студии Motion Twin. Среди прочего, передо мной была поставлена задача создания дизайна фонов Dead Cells. Надеюсь, что информация о моём производственном процессе может кому-нибудь пригодиться.

Давайте приступим. Фундамент художественного стиля Dead Cells основывался на трёх столпах: насыщенной цветовой палитре, кельтской архитектуре и теме алхимии.

Что: насыщенная цветовая палитра в мрачных окружениях

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

Благодаря этому игрок лучше понимает происходящее, а значит, и быстрее реагирует на потенциально смертельные источники опасности. И это замечательно подходит к такой активной игре, которой мы стремились сделать Dead Cells.

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


Комплементарные палитры, используемые в закрытом уровне (Toxic Sewers)


Палитра из близких цветов, использованная на открытом уровне (Promenade of the Condemned)

Введение

Цель этого проекта — создание клона движка DOOM, использующего ресурсы, выпущенные вместе с Ultimate DOOM (версия со Steam).

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

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

Вот список ресурсов и ссылок.

Книга Game Engine Black Book: DOOM Фабьена Санглара. Одна из лучших книг по внутреннему устройству DOOM.

Doom Wiki

Исходный код DOOM

Исходный код Chocolate Doom

Любому программисту будет полезно понимание различных структур данных и способов анализа их производительности. Но на практике мне ни разу не пригождались АВЛ-деревья, красно-чёрные деревья, префиксные деревья, списки с пропусками, и т.д. Некоторые структуры данных я использую только для одного конкретного алгоритма и ни для чего больше (например, кучи для реализации очереди с приоритетом в алгоритме поиска пути A*).

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

• Общие массивы данных (Bulk data) — способ эффективного хранения большого количества объектов.
• Слабые ссылки (Weak reference) (или дескрипторы (handle)) — способ обращения к объектам в bulk data без сбоев программы в случае, если объект удалён.
• Индексы — способ быстрого доступа к отдельным подмножествам в bulk data.
• Массивы массивов — способ хранения объектов bulk data с динамическими размерами.

Я посвящу несколько статей тому, как я обычно реализую все эти структуры. Давайте начнём с простейшей и самой полезной — bulk data.

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

Можно ли всё это как-то ускорить?!

В этой статье я расскажу о том, как мы разрабатываем тайлы 2D-окружений для таких игр, как Levelhead и Crashlands, и покажу методику, позволяющую нам сэкономить немного времени и повысить универсальность графических ресурсов окружений. Этот метод также упрощает создание органически выглядящих типов рельефа, хорошо сочетающихся друг с другом. Я не предлагаю при создании тайлсетов окружений пользоваться только этим способом, но он станет хорошим пополнением набора инструментов для любого художника.

Этот способ называется SPLATTER TILE!

В Unity 2018.3 появилась поддержка изометрических тайловых карт, очень напоминающая поддержку тайловых карт шестиугольников, которая была добавлена в версии 2018.2. Новые функции Tilemap позволяют быстро и эффективно создавать 2D-окружения на основе изометрических и шестиугольных сеток, которые использовались во многих классических играх, в том числе в первых частях Diablo и Fallout, Civilization, Age of Empires, и многих других.

Обе системы построены на основе уже существовавшей системы Tilemap, появившейся в Unity 2017.2, и сегодня работать с ними так же просто! Кроме того, они имеют нативную интеграцию с Editor. В дальнейших версиях Unity они могут быть перенесены в package manager.

Если вам интересно поэкспериментировать с этими системами, мы создали заранее подготовленный проект Isometric Starter Kit с анимированным персонажем и несколькими тайлсетами окружений. Скачать его можно здесь.

Я всегда начинаю с того, что задаю много вопросов и провожу активные исследования. За свою карьеру я успел поработать над множеством сиквелов уже существовавших франшиз. Лучшее, что ты можешь сделать в этом случае — полностью освоить жанр игры и изучить мир. Среди прочих проектов, мне приходилось с головой нырять в Halo, StarWars, Hellboy и Division. Хорошие гейм-дизайнеры — это хорошие исследователи.

Naughty Dog мастерски реализовала The Last of Us: Left Behind, и прежде чем браться за этот проект, мне нужно было хорошо подготовиться. Если вы не играли в Last of Us, то сыграйте! Это одна из самых потрясающих историй и несравненный пример развития персонажей. Другие разработчики очень многому могут научиться у создателей этой игры. Из-за сильного упора на повествование Naughty Dog называет свои дизайн-документы миссий «набросками глав». Мне кажется, это очень милый штрих. Это заставляет больше думать о повествовании при создании контента и придавать дизайну более сюжетную структуру.

Предупреждение — в статье содержатся спойлеры Last of US и Last of Us DLC.

Холивар о том, нужно ли использовать для создания игр движки, начался сразу после появления первых игровых движков. Этот пост на reddit не является идеальным примером разумных контраргументов против постоянного использования движков, но я считаю, что непреодолимое желание их применения немного отдаёт фанатизмом.

Давайте рассуждать разумно

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

Уровень навыков

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

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

Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.

Если вы опытный/профессиональный программист, способный уверенно освоить стороннее ПО, то можете воспользоваться этим навыком и решить, насколько минималистичным/максималистичным будет ваш подход (будет ли это исключительно минимальный SDL или же полностью оборудованный Unreal Engine).

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

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

В целом существует два основных типа сетевых архитектур: peer-to-peer и клиент-серверная. В архитектуре peer-to-peer (p2p) данные передаются между любыми парами подключенных игроков, а в клиент-серверной архитектуре данные передаются только между игроками и сервером.

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

[Первая, вторая, третья и четвёртая части туториала]

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

Это пятая часть серии туториалов, посвящённых созданию простой игры в жанре tower defense. В ней мы научимся создавать геймплейные сценарии, порождающие волны разнообразных врагов.

Туториал создавался в Unity 2018.4.6f1.


Становится довольно уютно.

В мае этого года я участвовал в качестве игрока в MMO-мероприятии KatherineOfSky. Я заметил, что когда количество игроков достигает определённого числа, через каждые несколько минут часть из них «отваливается». К счастью для вас (но не для меня), я был одним из тех игроков, которые отключались каждый раз, даже при наличии хорошего подключения. Я воспринял это как личный вызов и начал искать причины проблемы. Спустя три недели отладки, тестирования и исправлений ошибка наконец устранена, но это путешествие было не таким уж простым.

Проблемы многопользовательских игр очень трудно отследить. Обычно они возникают в очень конкретных условиях параметров сетей и при очень специфичных состояниях игры (в данном случае — наличие более 200 игроков). И даже когда удаётся воспроизвести проблему, её невозможно должным образом отлаживать, потому что вставка контрольных точек останавливает игру, путает таймеры и обычно приводит к завершению соединения из-за превышения срока ожидания. Но благодаря упорности и замечательному инструменту под названием clumsy мне удалось выяснить, что же происходит.

Если вкратце: из-за ошибки и неполной реализации симуляции состояния задержки клиент иногда оказывался в ситуации, когда ему приходится за один такт отправлять сетевой пакет, состоящий из вводимых игроком действий выбора примерно 400 игровых сущностей (мы называем его «мегапакетом»). После этого сервер не только должен правильно получить все эти действия ввода, но и отправить их всем остальным клиентам. Если у тебя 200 клиентов, это быстро становится проблемой. Канал к серверу быстро забивается, что приводит к утере пакетов и каскаду повторно запрошенных пакетов. Откладывание действий ввода затем приводит к тому, что ещё больше клиентов начинает отправлять мегапакеты, и их лавина становится ещё сильнее. Удачливым клиентам удаётся восстановиться, все остальные «отваливаются».

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

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

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

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

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

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


Буквами E помечены враги-монстры на арене, а буквой P — игрок, изначально находящийся в коридоре.

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


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

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

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

Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.

/bin

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

Там ожидается присутствие таких команд:

cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.

Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.

/sbin

Утилиты, используемые для системного администрирования (и другие команды только для root), /sbin содержит двоичные файлы, необходимые для загрузки, восстановления, восстановления и/или восстановления системы в дополнение к двоичным файлам в /bin. Программы, выполняемые после того, как /usr монтируется (когда проблем нет), обычно помещаются в /usr/sbin. Локально установленные программы системного администрирования должны быть помещены в /usr/local/sbin.

Ожидаются:

fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.

Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, установкой атрибута x.
К тому же, замена /bin и /sbin на копии из архива (одинакового для всех однотипных систем) является быстрым способом починки систем без пакетного менеджера.

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

---

Пространственные отношения

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

Такие отношения постоянно используются в видеоиграх и могут предоставлять очень полезную информацию ИИ, а также самому игроку.

---

У Вороного есть ответ

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

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


Какое-то время назад этот пост появился на главной странице Hacker News. Его обсуждение можно прочитать здесь.

Введение

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

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

• Упаковка и покрытие
• Выпуклые оболочки, ячейки Вороного и треугольники Делоне
• Ядра $$-энергии Риса
• Кубатура и определители

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

Ради краткости в этом посте мы рассмотрим только два критерия: минимальное расстояние упаковки и выпуклую оболочку/сетку Делоне (объём и площадь).

От переводчика:
Представляю вашему вниманию статью авторства Andy Gainey, в прошлом независимого разработчика игровых инструментов, ныне сотрудника Paradox Development Studio. На мой взгляд, автор играючи создал один из лучших процедурных генераторов планет с открытым исходным кодом.