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

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

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

В этой статье описывается подход к дизайну и реализации высокоточной сенсорной системы для ИИ в игре от первого лица с упором на стелс. Описанные здесь техники взяты из опыта разработки ИИ для Thief: The Dark Project, а также из ознакомления с кодом Half-Life. В первой части статьи изложены базовые концепции чувств ИИ на мотивирующем примере Half-Life. Во второй части излагаются более строгие требования к сенсорным системам в дизайне стелс-игр и описывается система, созданная для Thief.

Из этой статьи вы узнаете, как создать аудиодвижок на основе синтезатора, способный генерировать звуки для игр в ретро-стиле. Звуковой движок будет генерировать все звуки во время выполнения и ему не требуются никакие внешние зависимости, например, файлы MP3 или WAV. В конечном результате у нас получится рабочая библиотека, которую можно удобно встраивать в игры.

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

В этом туториале используется язык программирования ActionScript 3.0, но применяемые техники и концепции можно легко преобразовать в любой другой язык, предоставляющий доступ к низкоуровневому API работы со звуком.

[Прим. пер.: оригинал статьи называется GPU Performance for Game Artists, но, как мне кажется, она будет полезной для всех, кто хочет иметь общее представление о работе видеопроцессора]

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

Мы надеемся, что художники создадут ресурсы, которые не только хорошо выглядят, но и будут эффективны при рендеринге. Если художники немного больше узнают о том, что происходит внутри видеопроцессора, это может оказать большое влияние на частоту кадров игры. Если вы художник и хотите понять, почему для производительности важны такие аспекты, как вызовы отрисовки (draw calls), уровни детализации (LOD) и MIP-текстуры, то прочитайте эту статью. Чтобы учитывать то влияние, которое имеют ваши графические ресурсы на производительность игры, вы должны знать, как полигональные сетки попадают из 3D-редактора на игровой экран. Это значит, что вам нужно понять работу видеопроцессора, микросхемы, управляющей графической картой и несущей ответственность за трёхмерный рендеринг в реальном времени. Вооружённые этим знанием, мы рассмотрим наиболее частые проблемы с производительностью, разберём, почему они являются проблемой, и объясним, как с ними справиться.

Делать видеоигры сложно. Но ещё сложнее делать их в одиночку.

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

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

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


До...


… и после.

Все крупные магазины игр (Steam, GOG, Origin, Uplay, itch и т.д.) обслуживают различные группы людей одновременно. Многие из этих групп имеют противоположные интересы. Говоря упрощённо, их можно разделить на:

1. Покупателей
2. Разработчиков
3. Издателей
4. Сами платформы магазинов

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

В начале 90-х создание трёхмерного игрового движка означало, что вы заставите машину выполнять почти не свойственные ей задачи. Персональные компьютеры того времени предназначались для запуска текстовых процессоров и электронных таблиц, а не для 3D-вычислений с частотой 70 кадров в секунду. Серьёзным препятствием стало то, что, несмотря на свою мощь, ЦП не имел аппаратного устройства для вычислений с плавающей запятой. У программистов было только АЛУ, перемалывающее целые числа.

При написании книги Game Engine Black Book: Wolfenstein 3D я хотел наглядно показать, насколько велики были проблемы при работе без плавающей запятой. Мои попытки разобраться в числах с плавающей запятой при помощи каноничных статей мозг воспринимал в штыки. Я начал искать другой способ. Что-нибудь, далёкое от $$ и их загадочных экспонент с мантиссами. Может быть, в виде рисунка, потому что их мой мозг воспринимает проще.

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

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

Что такое инкрементная игра?

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

В сущности, такова общая структура «инкрементной» игры. Она кажется простой, даже примитивной, но в игровом процессе есть неожиданная глубина и привлекательность. Стили игры могут быть разными — от коммерчески успешных и казуальных Clicker Heroes и AdVenture Capitalist до более экспериментальных или хардкорных примеров, таких как Candy Box, Cookie Clicker и Sandcastle Builder.


Cookie Clicker, самое начало.

Что же самое важное в инкрементной игре? Хотя в этом жанре есть множество вариаций и экспериментов, фундаментальными аспектами дизайна являются:

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

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

Unity, C#, Steamworks.NET и Facepunch.Steamworks

Введение

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

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

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

Поэтому я решил написать высокоуровневый обзор для людей, которые только начинают разбираться в том, как заставить Steam работать с их играми. В частности, я подробно рассмотрю Steamworks SDK, программную библиотеку Valve, предоставляющую доступ к таким аспектам, как мастерская (Workshop), таблицы лидеров (Leaderboards), достижения (Achievements) и так далее.

Steamworks хорошо задокументирована компанией Valve, но документация написана с точки зрения человека, использующего нативную библиотеку C++ и уже имеющего представление о том, как все эти функции пересекаются. Если это не ваш случай, то так даже лучше! Ниже представлено объяснение для другого человека, который пишет игру на языке более высокого уровня и просто хочет обеспечить простую интеграцию со Steamworks (а это возможно, я гарантирую!). Конкретнее, этот пост предназначен для людей, использующих в той или иной форме C#, а в идеале — работающих в игровом движке Unity.

Кейт Холман и Зак Барт — разработчики из игровой студии Zachtronics. Если вы любите запутанные технические статьи о создании игр для 25-летних компьютеров, возможно, вам понравятся наши игры-головоломки: SpaceChem, Infinifactory, TIS-100 и SHENZHEN I/O!

Приступаем

Смогут ли два программиста, привыкшие к созданию игр для современных компьютеров с гигабайтами ОЗУ и полноцветными HD-дисплеями, портировать свои игры под MS-DOS? Никто из нас не имел опыта разработки на таком старом оборудовании, но работа в искусственно ограниченных системах — основа дизайна игр Zachtronics, поэтому мы были обязаны попробовать!

Проект начался с того, что Зак создал макет SHENZHEN SOLITAIRE, мини-игры в пасьянс из нашей игры SHENZHEN I/O (также продаваемой как отдельная игра). Вот как пасьянс мог выглядеть на экране 256-цветного VGA-дисплея:



Похоже на игры, которые можно было увидеть на экранах PC начала 90-х! Теперь осталось только написать код, правда?

Я познакомлю вас с полным туториалом на HTML5 с демо по алгоритму машинного обучения видеоигре Flappy Bird. Цель этого эксперимента — написать игровой контроллер искусственного интеллекта на основе нейросетей и генетического алгоритма.

То есть мы хотим создать ИИ-робота, который сможет учиться оптимальной игре во Flappy Bird. В результате наша маленькая птица сможет спокойно пролетать через препятствия. В наилучшем сценарии она не умрёт никогда.

Прочитав теорию, лежащую в основе этого проекта, можно скачать исходный код в конце этого туториала. Весь код написан на HTML5 с использованием фреймворка Phaser. Кроме того, мы использовали библиотеку Synaptic Neural Network для реализации нейросети, чтобы не создавать её с нуля.

Демо

Для начала посмотрите демо, чтобы оценить алгоритм в действии:



Запустить в полноэкранном режиме

Тем, кто знаком с криптографией с открытым ключом, наверно известны аббревиатуры ECC, ECDH и ECDSA. Первая — это сокращение от Elliptic Curve Cryptography (криптография на эллиптических кривых), остальные — это названия основанных на ней алгоритмов.

Сегодня криптосистемы на эллиптических кривых используются в TLS, PGP и SSH, важнейших технологиях, на которых базируются современный веб и мир ИТ. Я уже не говорю о Bitcoin и других криптовалютах.

До того, как ECC стала популярной, почти все алгоритмы с открытым ключом основывались на RSA, DSA и DH, альтернативных криптосистемах на основе модулярной арифметики. RSA и компания по-прежнему популярны, и часто используются вместе с ECC. Однако несмотря на то, что магия, лежащая в фундаменте RSA и подобных ей алгоритмов легко объяснима и понятна многим, а грубые реализации пишутся довольно просто, основы ECC всё ещё являются для большинства людей загадкой.

В этой серии статей я познакомлю вас с основами мира криптографии на эллиптических кривых. Моя цель — не создание полного и подробного руководства по ECC (в Интернете полно информации по этой теме), а простой обзор ECC и объяснение того, почему её считают безопасной. Я не буду тратить время на долгие математические доказательства или скучные подробности реализации. Также я представлю полезные примеры с визуальными интерактивными инструментами и скриптами.

Для вычисления урона от атаки в таких настольных ролевых играх, как Dungeons & Dragons, используются броски урона. Это логично для игры, чей процесс основан на бросках кубиков. Во многих компьютерных RPG урон и другие атрибуты (сила, очки магии, ловкость и т.д.) вычисляются по похожей системе.

Обычно сначала пишется код вызова random(), а затем результаты корректируются и подстраиваются под нужное игре поведение. В этой статье будут рассмотрены три темы:

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

Введение

Для игры World Void нам понадобилось портировать в Unreal Engine 4 исторический памятник. Моей задачей было сканирование замка. Я ожидал финансирования, которое всё задерживалось, поэтому решил наконец просто взять и сделать всё самостоятельно, без денег, и у меня получилось — я отсканировал замок! Прошло уже несколько месяцев, а я до сих пор в восторге! В этой статье я расскажу, как мне это удалось. Но сначала я хочу поблагодарить Милоша Лукача, Джеффри Иэна Уилсона и 3D Scanning User Group, без которых это бы оказалось невозможным.

Что такое фотограмметрия?

Если вкратце, то фотограмметрия — это процесс создания 3D-моделей из нескольких фотоснимков одного объекта, сделанных под разными углами.

Я не буду рассматривать трёхмерное сканирование объектов, эта тема уже достаточно освещена.

Если вы хотите начать осваивать фотограмметрию, то рекомендую это короткое видео Джеймса Кэнди с YouTube. Хоть в нём и упоминается Agisoft Photoscan, рассмотренные концепции сработают в любом другом ПО для фотограмметрии. Можно также изучить Руководство по фотограмметрии для бедных.

В своём рабочем процессе фотограмметрию используют очень многие художники, её применяли для демо Kite компании Epic games, в Star Wars Battlefront и бесконечном числе других проектов. Однако большинство этих студий сканировало камни и деревья. Epic games написала пост о том, как создавались ресурсы для демо с открытым миром. Сотрудники компании даже написали пост о выборе оборудования и ещё один, описывающий процесс устранения освещения. Крайне рекомендую прочитать эти посты, если вы ещё их не видели.

Техника автоматического выбора нужного тайла из тайловой карты.

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

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

Тайлы, учитывающие своих соседей

Тайлы в Super Mario не учитывают своих соседей: каменный блок всегда выглядит одинаково, и как отдельный фрагмент, и как часть стены.



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

«Я экспериментировал с задачами кубического представления в стиле предыдущей работы Эндрю и Ричарда Гая. Численные результаты были потрясающими…» (комментарий на MathOverflow)

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

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


«95% людей не решат эту загадку. Сможете найти положительные целочисленные значения?»

Вы наверно уже видели похожие картинки-мемы. Это всегда чистейший мусор, кликбэйты: «95% выпускников МТИ не решат её!». «Она» — это какая-нибудь глупая или плохо сформулированная задачка, или же тривиальная разминка для мозга.

Но эта картинка совсем другая. Этот мем — умная или злобная шутка. Примерно у 99,999995% людей нет ни малейших шансов её решить, в том числе и у доброй части математиков из ведущих университетов, не занимающихся теорией чисел. Да, она решаема, но при этом по-настоящему сложна. (Кстати, её не придумал Сридхар, точнее, не он полностью. См. историю в этом комментарии).

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

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

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

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

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

Когда игры едва работали, лёгкие подвисания конечно были, но не вызывали больших проблем. Однако, эмуляция во многих играх постепенно улучшилась до почти идеального состояния, а подвисания оставались неизменными в течение многих лет. С момента выпуска Dolphin 4.0 пользователи начали ещё сильнее жаловаться на подвисание при компиляции шейдеров. Частично это было вызвано повышением требований к видеопроцессору из-за целочисленной математики, но в основном подвисание стало заметно потому, что других серьёзных проблем в эмуляторе не осталось.

Художник по оружию Грегор Копка рассказал о своём опыте создания трёхмерного оружия для видеоигр и о том, как перспектива и расположение камеры влияют на этот процесс.

Введение

Меня зовут Грегор Копка, в разработку 3D-игр я попал в конце девяностых. Мы с моими друзьями участвовали в модсцене и работали над модом Quake III под названием «Navy Seals Covert Operations». Фактически это был мой первый опыт в создании игровых ресурсов для движка. Я занимался персонажами и оружием и совершенно не понимал, что я делаю! Но постепенно мы с друзьями научились всему необходимому. Этот серьёзный труд завершился успехом благодаря поддержке друг друга. Кроме того, нам удалось добиться и большей цели — создать свою собственную компанию. В университете, где я изучал дизайн, я продолжал заниматься 3D-графикой и поверхностно осваивал графику для фильмов. В те времена качество моих работ было намного ниже того, на что способны сегодня даже дети, просто потому что единственным источником знаний тогда были дорогие книги, целиком посвящённые созданию сфер в 3ds Max. Сегодня достаточно зайти на YouTube или на ArtStation, чтобы научиться приёмам оптимальной работы, перенять опыт других пользователей и вдохновиться огромной подборкой потрясающей 3D-графики.

Часть 1: точки, векторы и базовые принципы

Современные трёхмерные игровые движки, используемые в крупнейших проектах — это тонкая смесь математики и программирования. Многие программисты игр признают, что всецело понять их очень непросто. Если вам не хватает опыта (или профессионального образования, как мне), эта задача становится ещё более сложной. Я хочу познакомить вас с основами графических систем 3D-движков.

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