[Предыдущие части анализа: первая и вторая и третья.]

Часть 1. Перистые облака

Когда действие игры происходит на открытых пространствах, одним из факторов, определяющих правдоподобность мира, является небо. Задумайтесь об этом — бОльшую часть времени небо в буквальном смысле занимает примерно 40-50% всего экрана. Небо — это намного больше, чем красивый градиент. На нём есть звёзды, солнце, луна и, наконец, облака.

Хотя современные тенденции, похоже, заключаются в объёмном рендеринге облаков при помощи raymarching-а (см. эту статью), облака в «Ведьмаке 3» полностью основаны на текстурах. Я уже рассматривал их ранее, но оказалось, что с ними всё сложнее, чем я изначально ожидал. Если вы следили за моей серией статей, то знаете, что есть разница между DLC «Кровь и вино» и остальной игрой. И, как можно догадаться, в DLC есть некоторые изменения и в работе с облаками.

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

В последнее время я много экспериментировал с процедурной генерацией на основе ограничений. В частности, с алгоритмом Wave Function Collapse (WFC, коллапс волновой функции). Я даже написал собственную open source-библиотеку и ассет unity.

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

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

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

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

Практически в каждой игре необходимо наполнять игровые уровни объектами, которые создают визуальное богатство, красоту и вариативность виртуального мира. Возьмите любую игру с открытым миром. Там деревья, трава, земля и вода основные «заполнители» картинки. Сегодня GPGPU будет совсем немного, но я попробую рассказать, как нарисовать в кадре много деревьев и камней, когда нельзя, но очень хочется.

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

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

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

Проблема хрупкого базового класса

Часть 1: обработка вершин

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

Главная тема этой статьи — важный этап рендеринга, на котором трёхмерный мир точек, отрезков и треугольников становится двухмерной сеткой разноцветных блоков. Очень часто этот процесс кажется незаметным, потому что преобразование из 3D в 2D оказывается невидимым, в отличие от процесса, описанного в предыдущей статье, где мы сразу же могли увидеть влияние вершинных шейдеров и тесселяции. Если вы пока не готовы к этому, то можете начать с нашей статьи 3D Game Rendering 101.

Подготовка к двум измерениям

Подавляющее большинство читателей читают этот веб-сайт на совершенно плоском мониторе или экране смартфона; но даже если у вас есть современная техника — изогнутый монитор, то отображаемая им картинка тоже состоит из плоской сетки разноцветных пикселей. Тем не менее, когда вы играете в новую Call of Mario: Deathduty Battleyard, изображения кажутся трёхмерными. Объекты движутся по сцене, становятся больше или меньше, приближаясь и отдаляясь от камеры.

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

Вернее, не так.

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

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

Завершение цикла статей от Cem Ugur Karacam о реализации MVC в Unity с помощью Scriptable Objects. Прочитать предыдущие части вы можете здесь и здесь.

В этой статье ведущий UI/UX художник Никита Кандыбин и технический UI художник Ольга Кинчак поделятся эффективными базовыми практиками по оптимизации Unity UI, которые используются в компании Banzai Games при создании игровых интерфейсов, а также укажут на подводные камни тех или иных решений в дизайне и верстке. Практически во всех перечисленных ниже пунктах можно обойтись без кода, настраивая компоненты непосредственно в редакторе, а что-то даже предусматривая заранее на стадии проектирования макетов интерфейса.

MVC (Model-View-Controller) — это схема, предполагающая разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента, чтобы каждый из них можно было независимо модифицировать. Разработчик Cem Ugur Karacam поделился своим опытом программирования в Unity и коротко рассказал о Scriptable Objects. Мы представляем перевод его статьи, опубликованной на сайте dev.to.

Алгоритм Wave Function Collapse генерирует битовые изображения, локально подобные входному битовому изображению.

Локальное подобие означает, что

• (C1) Каждый паттерн NxN пикселей в выходных данных должен хотя бы раз встречаться во входных данных.
• (Слабое условие C2) Распределение паттернов NxN во входных данных должно быть подобным распределению паттернов NxN в значительно большом количестве наборов выходных данных. Другими словами, вероятность встречи определённого паттерна в выходных данных должна быть близка к плотности таких паттернов во входных данных.

Нередко встречающаяся в разработке под iOS задача — раскрывающиеся/складывающиеся секции в UITableView. Сегодня мы реализуем эту задачу, используя SwiftUI. В качестве небольшого twist'a добавим анимированный треугольник в заголовке секции и сделаем ячейки также раскрывающимися.

Разработка проходила на XCode 11.2 под macOS Catalina 10.15.1

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

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

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

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

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

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

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

В некоторый момент ваших графических приключений вам захочется вывести текст через OpenGL. Вопреки тому, что вы могли ожидать, получить простую строку на экране довольно сложно с низкоуровневой библиотекой, такой как OpenGL. Если вам не нужно больше 128 различных символов для отрисовки текста, тогда это не будет сложно. Сложности появляются, когда у символов не совпадают высота, ширина и смещение. В зависимости от того, где вы живете, вам может потребоваться больше 128 символов. А что, если вам захочется спецсимволов, математических или музыкальных символов? Как только вы поймете, что отрисовка текста — не самое простое занятие, то к вам придет осознание того, что это, скорее всего, не должно принадлежать такому низкоуровневому API, как OpenGL.

Поскольку OpenGL не предоставляет никаких средств для отрисовки текста, все трудности этого дела оказываются на нас. Поскольку не существует графического примитива "Символ", нам придется придумывать его самим. Уже есть готовые примеры: рисовать символ через GL_LINES, создать 3D-модели символов или отрисовывать символы на плоские четырехугольники в трехмерном пространстве.

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

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

Зачем это необходимо? Программа — это последовательность команд по обработке данных (в самом общем случае). Эти данные необходимо некоторым образом хранить, загружать, передавать и т.д. Все эти операции не происходят мгновенно, следовательно, они непосредственно влияют на скорость работы вашего конечного приложения. Умение оптимально управлять данными в процессе работы позволит вам создавать весьма нетривиальные и очень требовательные к ресурсам программы.

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

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

В прошлый раз мы остановились на том феномене, что игра, которая изначально задумывалась как кооператив (например, D&D или многопользовательская песочница типа Space Station 13), почему-то может использоваться игроками совершенно по другому назначению, становясь пространством насилия и травли. Сегодня, соответственно, будем разбираться в том, как устроена детская (и не только детская) агрессия, как работает формат песочницы, что делает агрессия в песочнице (и вообще в игре) и как можно ей управлять.

Физика эмоции

В дальнейшем изложении мы будем использовать гидродинамическую модель эмоции. Представим себе, что, например, гнев – это жидкость. Чем больше накапливается гнева, тем сильнее становится напор жидкости в трубе – отдельно взятом индивидууме. На выходе есть два вентиля. Один соответствует внутреннему тормозу – представлению, например, о том, что обижать других людей дурно, некрасиво, недостойно… Второй соответствует внешнему тормозу – страху перед наказанием или какими-то другими негативными последствиями. Что будет, если давление жидкости нарастает, а вентили (хотя бы какой-то один из них) намертво закручены?

Я занялся изучением процессов распознавания коллизий, и это привело меня к алгоритму Гилберта — Джонсона — Кирти (Gilbert-Johnson-Keerthi, GJK).

Все примеры кода в посте написаны на TypeScript. В примерах используются созданные мной структуры, которые подробно в посте не рассмотрены. Они просты и их можно посмотреть в репозитории GitHub:

• Vector
• IShape
• Collision

Весь код из поста хранится в репозитории GitHub:

https://github.com/jthomperoo/gjk-ts-implementation

Пост написан на основании этой статьи и рекомендованного в ней видео:

• http://www.dyn4j.org/2010/04/gjk-gilbert-johnson-keerthi/
• http://mollyrocket.com/849

Введение

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

На прошлой неделе мы говорили в своём блоге об изменениях, которые позволят врагам (biters, кусакам) не наталкиваться друг на друга, но это было не единственное обновление, связанное с biter-ами. Совпало так, что в обновления этой недели вошло то, над чем мы работали предыдущие несколько недель — обновление системы поиска пути для врагов.

Поиск пути

Когда юнит хочет куда-то переместиться, ему сначала нужно понять, как туда добраться. В самом простом случае можно двигаться прямиком к цели, но на пути иногда возникают препятствия — скалы, деревья, гнёзда врагов (spawners), юниты игрока. Чтобы проложить дорогу, мы должны сообщить функции поиска пути (pathfinder) текущую и конечную позиции, а pathfinder вернёт нам (возможно, через много тактов) путь, который просто является набором промежуточных точек (waypoints), по которым должен двигаться юнит, чтобы добраться до места назначения.

Для выполнения своей работы pathfinder использует алгоритм под названием A* (произносится «A star»). Простой пример поиска пути при помощи A* показан на видео: biter хочет найти путь в обход скал. Функция поиска пути начинает исследовать карту вокруг biter-а (исследование показано белыми точками). Сначала она пытается пойти напрямик к цели, но как только достигает скал, «разливается» в обе стороны, пытаясь найти позицию из которой снова можно будет двигаться к цели.

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

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

Введение

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

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

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

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

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

Doom Wiki

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

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