Как жаль, что нельзя себя клонировать и одновременно заниматься несколькими задачами

Как жаль, что нельзя себя клонировать и одновременно заниматься несколькими задачами.

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

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

Это особенно привлекательно, потому что используя Mass Entity - я уже отказался от некоторых принципов ООП в пользу дата ориентированного дизайна и событийной системы. В игре объекты более не являются главными на сцене. Главные - это данные, которые работают в многопотоке, удобные для процессора, а вместо объектов - визуальные пустышки, которые ничего из себя не представляют.

И вот я сейчас для каждой системы делаю плагин. Это для меня удобнее и легче ими делиться и использовать в других проектах. И как оказалось, Lyra тоже полностью построена на плагинах. Но там они не для каждой системы, а для всего, включая контент. И Game Mode там используется лишь в качестве пустышки. Основную роль выполняет система игрового опыта. Она отвечает за то, какие плагины будут загружены для выбранной игровой сессии. Таким образом в игре только тот контент, который реально используется.

Если кратко, то как это будет выглядеть. У нас есть стратегия. Игровой опыт - это Data asset, игровые данные - это Data Registry, игровой менеджер - это Subsystem.

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

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

А игровой опыт сообщает, какие именно наборы таблиц доступны для данной игровой сессии.

Значит, data asset определяет, какие таблицы доступны для данной игровой сессии, data registry отправляет по приоритету какие именно нужно использовать данные из таблиц, а subsystem просто работает с полученными данными. И передаёт их, к примеру, в mass entity.

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