Привет, Хабр!

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

И начнем мы сегодня с ролика о том, как создать играбельного 2D-персонажа в Unity 5 — если вы еще не попытались этого сделать, то сейчас самое время. Важные моменты о физике, коллайдерах, спрайтах и перемещении персонажа по сцене.



Рекомендуем, кстати, посмотреть этот курс целиком вот здесь.

Несколько десятилетий назад профессор Университета Эссекса Ричард Алан Бартл придумал модель сегментации игроков по психологическим типам. Сегодня её используют разработчики игр во всем мире, в том числе и в Mail.Ru Group. Например, психотипы Бартла применяются в социальных сетях для оптимизации каталога игр под каждого пользователя. Так что же придумал этот замечательный человек?

30 лет назад Бартл написал одну из первых многопользовательских игр — MUD (Multi-User Dungeon), по имени которой теперь называют целый жанр. Фактически, это прародитель всех современных ММО. Вот такая замечательная консольная текстовая игра:



То, на что опирается Бартл, — это программный код игры, распечатанный для защиты научной работы.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

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

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

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

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

Многие игры были рассмотрены на сайте Fabien Sanglard. Если вам интересны подробности их работы, то пожалуйте к нему.

Можно заметить, что многие игры принадлежат id Software/Apogee. Совпадение? Не думаю. id славится открытостью и привычкой выпускать исходники. Старые коммерческие игры уже не имеют ценности и были бы потеряны – не лучше ли, чтобы кто-то учился чему-то полезному на их основе?

Итак, приступим (в хронологическом порядке):

В предыдущей части урока мы научились базовой работе с VPC и печати сообщений в консоль разработчика.

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

В этой статье мы поговорим о «магической» константе 0x5f3759df, лежащей в основе элегантного алгоритмического трюка для быстрого вычисления обратного квадратного корня.

Вот полная реализация этого алгоритма:

float FastInvSqrt(float x) {
  float xhalf = 0.5f * x;
  int i = *(int*)&x;  // представим биты float в виде целого числа
  i = 0x5f3759df - (i >> 1);  // какого черта здесь происходит ?
  x = *(float*)&i;
  x = x*(1.5f-(xhalf*x*x));
  return x;
}

Этот код вычисляет некоторое (достаточно неплохое) приближение для формулы



Сегодня данная реализация уже хорошо известна, и стала она такой после появления в коде игры Quake III Arena в 2005 году. Её создание когда-то приписывали Джону Кармаку, но выяснилось, что корни уходят намного дальше – к Ardent Computer, где в середине 80-ых её написал Грег Уолш. Конкретно та версия кода, которая показана выше (с забавными комментариями), действительно из кода Quake.
В этой статье мы попробуем разобраться с данным хаком, математически вывести эту самую константу и попробовать обобщить данный метод для вычисления произвольных степеней от -1 до 1.

Да, понадобится немного математики, но школьного курса будет более, чем достаточно.

Всем привет. Все кто хоть немного разбирался в теме OpenGL знают, что существует большое количество статей и курсов по этой теме, но многие не затрагивают современный API, а часть из них вообще рассказывают про glBegin и glEnd. Я постараюсь охватить некоторые нюансы нового API начиная с 4-й версии. Ссылка на вторую часть статьи

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

• сравнивая с одним псевдослучайным числом (которое тоже можно получать по разному [1]);
• сравнивая с наибольшим или наименьшим из двух псевдослучайных чисел;
• сравнивая среднее из двух и более случайных чисел (среднее тоже можно считать по разному).

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

Точно также по разному можно рассчитывать наносимый урон, особенно на основе дайсов (кубиков).

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

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

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

• 80% попадания выстрела в игре — ну это почти гарантированное попадание;
• 80% того, что ваш товарищ хоть когда-нибудь отдаст долг — не-не-не, так не пойдёт, это слишком большой риск;
• 5% получения критического урона он NPC врага — маловероятно, риск можно игнорировать;
• 1% риск падения сосульки, если пройти под крышей с капающими метровыми сосульками — ещё чего, лучше обойти с другой стороны тротуара;
• 51% вероятность выигрыша в мини-игре в большой РПГ — можно рассчитывать на то, что после 20 ставок я чуть-чуть выиграю или, как минимум, останусь при своих… через 20 ставок… как такое могло случиться, что я проиграл половину всего своего золота? Тут явно сломан генератор случайных чисел!

В статье будут рассмотрены следующие вопросы:

• ошибочные допущения в оценке вероятностей;
• конкретные примеры заблуждений игроков и фактические вероятности «редких» событий;
• генератор случайных чисел (вообще-то псевдослучайных);
• ранние простые генераторы псевдослучайных чисел на примере Final Fantasy I;
• подходы к реализации случайных событий с воспроизводимостью и без;
• примеры удачно внедренных разных подходов и манипуляции в Fire Emblem.

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

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

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

Ну, давайте начнём с объяснения задачи!

Введение

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

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

Что же такое «игровой ИИ»?

Игровой ИИ в основном занимается выбором действий сущности в зависимости от текущих условий. В традиционной литературе по ИИ называет это управлением "интеллектуальными агентами". Агентом обычно является персонаж игры, но это может быть и машина, робот или даже нечто более абстрактное — целая группа сущностей, страна или цивилизация. В любом случае это объект, следящий за своим окружением, принимающий на основании него решения и действующий в соответствии с этими решениями. Иногда это называют циклом «восприятие-мышление-действие» (Sense/Think/Act):

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

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

• Регистры и их назначение при вызове функций.
• Передача и возврат простых типов и структур.
• Как передача по ссылке и по значению влияют на оптимизации тела функции компилятором.
• Как используется место при многочисленных вызовах функций.
• Механизм виртуальных вызовов.
• Оптимизация хвостовых вызовов и рекурсии.
• Инициализация структур, массивов и векторов.

Осторожно! Статья содержит большое количество кода на C++ и ассемблере (Intel ASM с комментариями), а также множество таблиц с оценками производительности. Всё написанное актуально для x86-64 System V ABI, который используется во всех современных Unix операционных системах, к примеру, в Linux и macOS.

В последнее время имена GridGain и Apache Ignite нередко мелькают в интернетах. Однако, судя по комментариям (например, здесь), мало кто понимает, что же это за продукт и с чем его едят.

В этой статье я попытаюсь доступным языком объяснить, и на примерах кода показать, что умеет Apache Ignite.

Введение

Использование функций обратного вызова (callback) — популярный подход к построению сетевых приложений с использованием библиотеки Boost.Asio (и не только ее). Проблемой этого подхода является ухудшение читабельности и поддерживаемости кода при усложнении логики протокола обмена данными [1].

Как альтернатива коллбекам, сопрограммы (coroutines) можно применить для написания асинхронного кода, уровень читабельности которого будет близок к читабельности синхронного кода. Boost.Asio поддерживает такой подход, предоставляя возможность использования библиотеки Boost.Coroutine для обработки коллбеков.

Boost.Coroutine реализует сопрограммы с помощью сохранения контекста выполнения текущего потока. Этот подход конкурировал за включение в следующую редакцию стандарта C++ с предложением от Microsoft, которое вводит новые ключевые слова co_return, co_yield и co_await. Предложение Microsoft получило статус Technical Specification (TS) [2] и имеет высокие шансы стать стандартом.

Статья [3] демонстрирует использование Boost.Asio с Coroutines TS и boost::future. В своей статье я хочу показать, как можно обойтись без boost::future. Мы возьмем за основу пример асинхронного TCP эхо-сервера из Boost.Asio и будем его модифицировать, используя сопрограммы из Coroutines TS.

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

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

В Unreal Engine создавать ИИ можно с помощью деревьев поведения. Дерево поведения (behavior tree) — это система определения поведения, используемого ИИ. Например, у него может быть поведение боя или бега. Можно создать дерево поведения, при котором ИИ будет драться с игроком, если его здоровье выше. Если оно ниже 50%, то он будет убегать.

В этом туториале вы научитесь следующему:

• Создавать ИИ-сущность, которая может управлять элементом Pawn
• Создавать и использовать деревья поведения и blackboard
• Использовать AI Perception, чтобы дать Pawn зрение
• Создавать поведения, чтобы Pawn мог ходить и атаковать врагов

В конце 2016 года была опубликована аналогичная статья. С тех пор список был обновлен на основе наблюдений и анализа нескольких ресурсов (постов в популярных блогах, обсуждений на Quora, поисковых запросов в Google и обсуждений на форумах, таких как reddit/learnprogramming и Hacker News).

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

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

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

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

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

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

Художники нарисовали яркую графику, программисты встроили ее в игру, аниматоры добавили движения — казалось бы, все, готово. Но нет, менеджерам не нравится:

«Надо убрать серые пятна и белые линии. Тут пульсирующая кнопка дергается, там прогресс-бар лесенкой идет».

Смотришь игровые ресурсы — нет в них ничего такого, все спрайты обрезаны. Читаешь код — формулы правильные, точности шейдера хватает. Но результат все равно получился неважный. Где ошибка?



Небольшой опрос для тех, кто уже знает откуда берутся артефакты. Что делать в такой ситуации?

1. Нужна мощная видеокарта и свежие драйверы;
2. Стоит сделать скачиваемые наборы графики для всех возможных разрешений экрана;
3. У квадратных текстур с размерами степени двойки нет таких проблем;
4. Это все из-за сжатия графики (PVRTC/DXT5/ETC1/...);
5. В графическом редакторе придется слегка размазать края;
6. Так и должно было получиться, ведь мы не подготовили графические данные;
7. Поможет только антиалиасинг;
8. Нужны текстуры и таргеты в режиме premultiplied alpha.

Какой вариант ответа правильный, почему именно он и как побороть артефакты графики читайте под катом.