Очень длинный пост

Очень длинный пост. Откровение #101.

Вот у меня уже год скоро, как я изучаю C++ в контексте Unreal Engine и имею определенный опыт.

Вот что я выяснил - очень важна конкретика.

Делать универсальную систему = делать узкое горло в плане производительности. Чем больше неопределённостей - тем хуже система.

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

Красные флаги: что хочешь, что угодно, универсально, в любом месте.

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

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

То есть для того, чтобы все летало - нужно делать конкретные, а не универсальные вещи. Так, разбираясь с Mass Entity, я решил, что юниты, здания и ресурсы у меня будут сущностями. Определил для них все возможные теги состояний и наборы данных, которые у них могут быть. Причём разделил на 4 группы. Данные, которые относятся абсолютно ко всем сущностям, например здоровье (максимальное и текущее), меш, имя, описание, иконка. И далее так же конкретные для юнитов, ресурсов и зданий. И получается, что я могу собирать разнообразные сущности из заранее созданных наборов данных, которые движок уже знает.

Наверное, за все время я не испытывал такого прилива вдохновения и желания работать. Уже скоро будут появляться первые новости по Mass Entity. Это по истине классная система.

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

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

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

Так вот, на сцене будет сравниться всего 1 или максимум 3 актора. Они будут заниматься визуализацией и создавать на месте сущности Instance Static Mesh, если это юнит, и Hierarchical Instance Mesh, если это здание или ресурс неподвижный.

Юнитов собираюсь анимировать через вертексные анимации VAT.

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

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

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

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

В общем, сейчас работа идёт быстрее, подтягиваю базу C++, изучил стандарты кодинга Unreal Engine, почитал документацию по C++ API и невероятно прокачался.

Кстати, всех Дам поздравляю с праздником!