Когда будет новый движок в танках. BigWorld Engine - Игровые движки - Файлы для игроделов - Создание игр

Пора покупать новые видеокарты или анонс нового движка WOT.

На WG Fest объявили о выходе совершенно новых танков. По сути это уже совсем другая игра, так как новый движок, звуки, HD карты. Несмотря на визуальные улучшения, разработчики обещают, что производительность не упадёт. Если сейчас играете с 30 FPS, то и на новом движке будет столько же.

Пока доступен лишь один трейлер:

Что известно на данный момент?

• Обновление выйдет в марте 2018 года.

• Новый движок под названием Core . (текущий движок WOT) неспеша уходит в прошлое.
  • Из существующий движков ни один не смог удовлетворить разработчиков, поэтому было принято решение всё сделать с нуля самим.
  • На разработку ушло 4 года: 3 года на сам движок и еще год на создание контента (карт).
• Для оценки производительности можно уже сейчас скачать специальный софт enCore , который проведёт тест, по результатам которого можно оценить насколько Ваш ПК пригоден к новой игре.
  • enCore можно запустить в трёх режимах графики: минимальные, средние и ультра.
  • Тест идёт три минуты, показывается реплей постановочного боя с демонстрацией новых графических возможностей и эффектов.

Результат теста enCore World of Tanks .

• HD карты - все локации переделаны под высокую четкость. И это касается всех аспектов: ландшафт, текстуры, освещение, звуки, эффекты, окружение и прочее.

Полный список переделанных в HD карт .

• Полностью переписан саундтрек. У каждой карты теперь будет своя музыка, передающая уникальною атмосферу локации.
• Обещают, что работа над оптимизацией проделана хорошая и сильной потери FPS быть не должно.

Со 2 по 8 октября в Минский центр разработки находились представители сообщества и блогеры из различных регионов. Польский портал dom1n публикует большую выдержку, который предоставил MatchyHK (азиатский Community Contributor). В ответах могут быть мелкие неточности, ибо оригинал подвергался переводу 2 раза: английский – польский – русский.

На вопросы отвечал Алексей (Inaki) Ильин - глобальный продюсер проекта World of Tanks, а также другие разработчики. Огромная и подробная подборка. Часть 2.

Глава 4. Экономика и игровая механика:

* Некоторым игрокам реально не нравится «клоунский камуфляж» (напр. Patriot или Liberte). Какого мнение разработчиков по этому поводу?
- Это очень хороший вопрос! Мы работаем над новой системой кастомизации, где игроки смогут детальней настраивать свои машины.
Мы хотим сделать эту систему очень хорошей, так что пока не можем назвать вам сроков выхода и мы не спешим вводить ее. Но с ее помощью мы сможем дать игрокам много настроек текстур и кастомизации танков.

// Интересная история:
Когда мы вводили Skorpion G, мы на самом деле создали 3 визуальные модели. Был обычный Skorpion (в немецком сером) и Skorpion, который мы все знаем. Третий имел очень неисторичную/нереальную текстуру и был посчитан неподходящим для игры.
* Что стало с новогодним ивентом с ящиками? Wargaming думает над системой ящиков со скинами как в CS:GO или Overwatch?
* Можно ввести что-то похожее на систему контейнеров в World of Warships?
- Нам нравится идея. Но в отличии от WoT, WoWS относительно новая игра. Контейнеры были внедрены, когда в игре прошла реформа экономики. Для нас это сложней, так как надо учитывать прошлое WoT. Трудно вводить что-либо, вносящее изменения во внутриигровую экономику. Если мы будем вводить что-либо подобное, нам необходимо очень тщательно это спланировать. Это может повлечь негативные впечатления у игроков, если мы уменьшим их прибыль для компенсации нововведения, и они будут считать, что зарабатывают меньше кредитов.
* Будет ли больше вариативности в рандоме? Например ночные бои или погода?
- Если мы будем вводить ночные бои или погоду, то нам надо решить, будут ли эти изменения только косметическими или также затронут геймплей, напр. снижать дальность обзора ночью или во время песчаной бури.
* Вы думаете “банить” XVM?
- Мы знаем, что мод XVM влечет за собой негодование в игре, помимо фокуса по XVM. Но мы не можем просто вывести XVM из игры. XVM также дает много других функций, помимо отображения статистики. Мы тесно работаем вместе с разработчиками XVM. Некоторые игроки используют XVM планируя стратегию на бой (напр. ездить за союзными фиолетовыми игроками, или фокусировать огонь на вражеских – к сожалению).
2 года назад мы собрали статистику по XVM и поняли, что более 50% человек используют XVM без функции статистики. Поэтому мы трудимся над внедрением эти функций в клиент игры, таким образом делая XVM ненужным. Недавно мы ввели собственную рейтинговую систему, т.к. мы думаем, что можем сделать более точную систему измерения. Это даст игрокам более точную систему оценки и сравнения.
В то же время компания проводила исследование по возможности запрета посторонним сервисам на получение данных с API Wargaming. Это ведет к проблемам с анализом данных для многих важных сервисов. Мы работаем над этим.
* Можно ли скрыть игроков в бою?
- К сожалению, мы не думаем, что это хорошая идея. Некоторые могут посчитать, что играют против ботов. Это также затрудняет социальные отношения в игре. Нельзя узнать, находится ли в клане игрок, и кланам было бы трудно искать новых игроков.
* Как дела с «Генеральным сражением»?
- Генеральное сражение - успешно и игрокам нравится, и карта хорошо сбалансирована с точки зрения статистики. Но на Азии и Америки за счет отсутствия большого количества игроков на 10 лвл и параллельного запуска ранговых боев собирается очень маленькое количество ГС. Мы это правим и настраиваем в данный момент.
* Артиллерия раздражает, Вы уберете или переделаете её ещё?
- Мы не будем убирать артиллерию. Этот класс для людей, которые любят предугадывать поведение других игроков. Есть доля людей, которым действительно нравится этот класс, и некоторые люди играют только на артиллерии. Теперь можно выживать под огнем больше, а не умирать от ваншота.

Глава 5. Игровой движок:

* Будет ли убрано текущее ограничение игрового движка в 127 FPS с вводом HD карт?
- Мы знаем о растущем использовании высококачественных мониторов (144 и 165 Гц). Ограничение в 127 ФПС не из-за самого клиента, а из-за старой серверной части BigWorld. Как мы уже раньше говорили, клиентская часть практически переписана заново. Подобным образом сейчас переписывается и серверная составляющая, и лимит FPS будет не нужен. Мы думаем убрать или заменить его, это тестируется, но возможно не будет добавлено в песочнице.
Вчера уже всё вышло без блока.

* Задирание орудия/странное поведение камеры (напр. когда переходишь из снайперского режима в обычный или наоборот если перед тобой есть какие-либо преграды) очень раздражает не только на HD картах, но и на общем сервере. Это будет исправлено?
- Мы знаем об этой проблеме. К сожалению, у нас нет явных решений на данный момент. Тем не менее, с момента ввода карты Промзона мы подправили логику поведения камеры. Это улучшило ситуацию, но не идеально. Поведение камеры в WoT намного сложней обычного шутера (в WoT необходимо учитывать многие факторы, например, скорость поворота башни и корпуса.) Нет простого решения этой проблемы, но с новыми технологиями мы надеемся разрешить эту проблему.

Глава 6. Разное:

Некоторые игроки предложили ввести цифровые параметры в настройки чувствительности. Это было принято к сведению и будет учтено позже. Но по данным статистики, очень немногие игроки меняют настройки управления.
- Судьба Chieftain Mk. 6 – к сожалению, он вряд ли будет введен в игру. Как бы нам не хотелось ввести его, мы бы не хотели, чтобы он был исследуем с Conqueror. Если мы найдем подходящих кандидатов на более низкие уровни с похожим геймплеем, мы обдумает ввод Chieftain в игру.
* WG думает над вводом румынской ветки?
- К сожалению, мы не думаем, что у Румынии достаточно танков, чтобы составить собственную ветку.

* Когда будут польские танки?
- Всё ещё работаем над польской веткой, но мы уже нашли все машины для нее. Поэтому мы постараемся ввести эти танки как можно быстрей. Но еще рано анонсировать конкретные даты!

* Где Серб (SerB)? Чем он занимается? Он работает над своим проектом лунной базы?)
- Серб работает у нас. Он НЕ работает над проектом лунной базы. Он сейчас трудится над другими проектами Варгейминг.

enCore - это программа, которая поможет проверить соответствует ли ваш ПК минимальным требованиям для использования HD-графики в World of Tanks.

World of Tanks Core

Весной 2018 года выходит World of Tanks 1.0 или World of Tanks Core. Это совершенно новая версия любимой игры с улучшенным графическим движком , которая позволит играть в World of Tanks на HD картах с реалистичной графикой. Установка WOT 1.0 потребует более мощный компьютер. Какой именно поможет узнать программа enCore.

Проверить подходит ли ваш компьютер для установки World of Tanks 1.0 с графическим движком Core можно уже сейчас при помощи программы enCore. Программа продемонстрирует возможности новой версии игры и измерит результаты её обработки на вашем ПК.

Скачайте и запустите файл WoTEnCore_internet_install.exe из архива, чтобы установить программу оценки производительности ПК от World of Tanks. После автоматической установки WOT enCore, выберите один из трех вариантов настроек графики для тестирования ПК на соответствие World of Tanks Core:

1. Минимальные;
2. Средние;
3. Ультра.

В зависимости от используемого "железа" программа порекомендует вам те или иные предустановленные настройки графики для запуска теста. Вы сможете самостоятельно выбрать удобные для вас установки графики в World of Tanks Core. Тест графики enCore лишь порекомендует оптимальный вариант именно для вашего ПК и подскажет почему в WOT низкий FPS . Вы можете самостоятельно указать программе, какие графические установки использовать для тестирования компьютера.

Перед запуском теста графики рекомендуем отключить фоновые процессы и закрыть используемые программы. Это повысит объективность результатов оценки производительности ПК с помощью enCore. После окончания теста "Энкор" выведет итоговый результат оценки вашего компьютера в баллах. Чем больше баллов набрал ваш компьютер в результате теста, тем лучше он подходит для

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

Тогда в разработке у нас находилось несколько игр. Одна из них носила рабочее название «Sniper». Основной геймплей-идеей была стрельба в снайперском режиме из стоящего в обороне танка, по другим танкам, которыми управлял AI и которые могли атаковать в ответ.

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

С этого все и началось!

Когда мы начинали разработку “Снайпера”, то рассматривали технологии, которые тогда были доступны для мобильных платформ. На тот момент Unity был еще на достаточно ранней стадии своего развития: по сути, необходимых нам технологий еще не было.

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

Также мы понимали, что на C# мы не сможем выжать максимум из устройств, под которые мы разрабатываем, и всегда будем ограничены.
Unreal Engine 3 тоже не подходил по ряду похожих причин.

В итоге, мы решили дорабатывать свой движок!

Он на тот момент уже использовался в наших предыдущих казуальных проектах. Движок имел достаточно хорошо написанный низкий уровень работы с платформами и поддерживал iOS, PC, Mac, плюс были начаты работы по Android. Было написано много функциональности для создания 2D-игр. То есть, был неплохой UI и много всего для работы с 2D. В нем были первые шаги по 3D-части, так как одна из наших игр была полностью трехмерной.

Что у нас было в 3D-части движка:

• Простейший граф сцены.
• Возможность рисования статических мешей.
• Возможность рисования анимированных мешей со скелетной анимацией.
• Экспорт объектов и анимаций из Collada-формата.

Начало работ

После нескольких дней работы мы получили вполне функциональный динамический ландшафт, который работал довольно сносно, требовал где-то 8MB памяти и давал 60fps на этих устройствах. После этого мы начали полноценную разработку игры.

Прошло около полугода, и маленький мини-проект превратился в то, чем сейчас является Blitz. Появились совершенно новые требования: MMO, AAA-качество и другие требования, которые движок в его изначальном виде на тот момент уже не мог обеспечить. Но работа кипела полным ходом. Игра работала и работала неплохо. Однако производительность была средней, объектов на картах было мало, и, собственно, было множество других ограничений.

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

Как все работало на тот момент

Основной концепции являлись два класса:

• Scene - контейнер сцены, внутри которого происходили все действия
• над сценой.
• SceneNode - базовый класс узла сцены, от которого наследовались все классы, которые находились в сцене:
• MeshInstanceNode - класс для отрисовки мешей.
• LodNode - класс для переключения лодов.
• SwitchNode - класс для переключения свитч объектов.
• еще около 15-ти классов наследников SceneNode.

• Update - функция которая вызывалась для каждого узла, для того чтобы сделать Update-сцены.
• Draw - функция, которая вызывалась для каждого узла, для того чтобы отрисовать этот узел.

Во-первых, производительность:

• Когда количество нодов в уровне достигло 5000, оказалось что просто пройти по всем пустым функциям Update, занимает около 3ms.
• Аналогичное время уходило на пустые ноды, которым не требовалось Draw.
• Огромное количество кэш-миссов, так как работа всегда велась с разнотипными данными.
• Невозможность распараллелить работу на несколько ядер.

• Изменение кода в базовых классах влияло на всю систему целиком, то есть каждое изменение SceneNode::Update могло сломать что угодно и где угодно. Зависимости становились все сложнее и сложнее, и каждое изменение внутри движка почти гарантированно требовало тестирования всей связанной функциональности.
• Невозможно было сделать локальное изменение, например, в трансформациях, чтобы не задеть остальные части сцены. Очень часто малейшие изменения в LodNode (узел для переключения лодов), ломали что-то в игре.

Первые шаги по улучшению ситуации

Собственно, сделали мы это, введя дополнительный флаг NEED_UPDATE в каждой ноде. Он определял, нужно ли такой ноде вызывать Update. Это действительно повысило производительность, но создало целый ворох проблем. Фактически код функции Update выглядел вот так:

Void SceneNode::Update(float timeElapsed) { if (!(flags & NEED_UPDATE))return; // the rest of the update function // process children }
Это вернуло нам часть производительности, однако началось много логических проблем там, где их не ждали.

LodNode, и SwitchNode - ноды, отвечающие, соответственно, за переключение лодов (по расстоянию) и переключение объектов (например, разрушенных и неразрушенных) - начали регулярно ломаться.

Периодически тот, кто пытался исправить поломки, делал следующее: отключал NEED_UPDATE в базовом классе (ведь это было простое решение), и совершенно незаметно FPS опять падал.

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

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

Цели

• Минимизация зависимости между независимыми подсистемами.
• Изменения в трансформациях не должны ломать систему лодов, и наоборот
• Возможность положить код на многоядерность.
• Чтобы не было функций Update или аналогичных, в которых выполнялся разнородный независимый код. Легкая расширяемость системы новой функциональностью без полного перетестирования старой. Изменения в одних подсистемах не влияет на другие. Максимальная независимость подсистем.
• Возможность расположить данные линейно в памяти для максимальной производительности.

Комбинирование компонентного и data-driven-подхода

Вообще понимание компонентного подхода у многих людей самое разное. То же - и с data-driven.

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

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

Что же такое data-driven . В моем понимании, это подход к проектированию программного обеспечения, когда за основу потока выполнения программы берутся данные, а не логика.

На нашем примере представим следующую иерархию классов:

Class SceneNode { // Данные отвечающие за иерархические трансформации Matrix4 localTransform; Matrix4 worldTransform; virtual void Update(); virtual void Draw(); Vector children; } class LodNode { // Данные cпецифичные для вычисления лодов LodDistance lods; virtual void Update(); // переопределен метод Update, для того чтобы в момент переключения лодов, включать или выключать какие-то из его чайлдов virtual void Draw(); // рисуем только текущий активный лод }; class MeshNode { RenderMesh * mesh; virtual void Draw(); // рисуем меш };
Код обхода этой иерархии иерархически выглядит так:

Main Loop: rootNode->Update(); rootNode->Draw();
В данной иерархии C++ наследования мы имеем три различных независимых потока данных:

• Трансформации

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

// Transform Data Loop: for (each localTransform in localTransformArray) { worldTransform = parent->worldTransform * localTransform; } // Lod Data Loop: for (each lod in lodArray) { // calculate lod distance and find nearest lod nearestRenderObject = GetNearestRenderObject(lod); renderObjectIndex = GetLodObjectRenderObjectIndex(lod); renderObjectArray = renderObject; } // Mesh Render Data Loop: for (each renderObject in renderObjectArray) { RenderMesh(renderObject); }
По сути, мы развернули циклы работы программы, сделав это таким образом, чтобы все отталкивалось от данных.

Данные в data-driven подходе являются ключевым элементом программы. Логика - лишь механизмы обработки данных.

Новая архитектура

Читая информацию по этой теме, я наткнулся на блог T-Machine .

Он мне дал множество ответов, на мои вопросы, однако основным ответом было следующее:

Entity не содержит никакой логики, это просто ID (или указатель).
Entity знает только ID компоненты, которые ей принадлежат (или указатель).
Компонент - это только данные, то есть. компонент не содержит никакой логики.
Система - это код, который умеет обрабатывать определенный набор данных и выдавать на выходе другой набор данных.

Если вы разрабатываете на Java, то очень рекомендую посмотреть на него. Очень простой и концептуально правильный Framework. На сегодняшний день он спортирован на кучу языков.

То, чем является Artemis, сегодня называют ECS (Entity Component System). Вариантов организации сцены на базе Entity, компонентов и data-driven достаточно много, однако мы по итогу пришли к архитектуре ECS. Сложно сказать, насколько это общепринятый термин, однако ECS значит, что есть следующие сущности: Entity, Component, System.

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

Этот пункт очень важен в “православном” компонентном подходе. Если нарушить первый принцип, появится очень много соблазнов. Один из первых - сделать наследование компонентов.

Несмотря на гибкость, заканчивается обычно макаронами.

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

ECS - более чистый подход, и решает больше проблем.

Чтобы посмотреть на примере, как это работает в Artemis, можете глянуть .

Я на примере покажу, как это работает у нас.

Главным классом контейнером является Entity. Это класс, который содержит массив компонентов.

Вторым классом является Component. В нашем случае, это просто данные.

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

Enum eType { TRANSFORM_COMPONENT = 0, RENDER_COMPONENT, LOD_COMPONENT, DEBUG_RENDER_COMPONENT, SWITCH_COMPONENT, CAMERA_COMPONENT, LIGHT_COMPONENT, PARTICLE_EFFECT_COMPONENT, BULLET_COMPONENT, UPDATABLE_COMPONENT, ANIMATION_COMPONENT, COLLISION_COMPONENT, // multiple instances PHYSICS_COMPONENT, ACTION_COMPONENT, // actions, something simplier than scripts that can influence logic, can be multiple SCRIPT_COMPONENT, // multiple instances, not now, it will happen much later. USER_COMPONENT, SOUND_COMPONENT, CUSTOM_PROPERTIES_COMPONENT, STATIC_OCCLUSION_COMPONENT, STATIC_OCCLUSION_DATA_COMPONENT, QUALITY_SETTINGS_COMPONENT, // type as fastname for detecting type of model SPEEDTREE_COMPONENT, WIND_COMPONENT, WAVE_COMPONENT, SKELETON_COMPONENT, //debug components - note that everything below won"t be serialized DEBUG_COMPONENTS, STATIC_OCCLUSION_DEBUG_DRAW_COMPONENT, COMPONENT_COUNT };
Третим классом является SceneSystem:

/** \brief This function is called when any entity registered to scene. It sorts out is entity has all necessary components and we need to call AddEntity. \param entity entity we"ve just added */ virtual void RegisterEntity(Entity * entity); /** \brief This function is called when any entity unregistered from scene. It sorts out is entity has all necessary components and we need to call RemoveEntity. \param entity entity we"ve just removed */ virtual void UnregisterEntity(Entity * entity);
Функции RegisterEntity, UnregisterEntity вызываются для всех систем в сцене тогда, когда мы добавляем или удаляем Entity из сцены.

/** \brief This function is called when any component is registered to scene. It sorts out is entity has all necessary components and we need to call AddEntity. \param entity entity we added component to. \param component component we"ve just added to entity. */ virtual void RegisterComponent(Entity * entity, Component * component); /** \brief This function is called when any component is unregistered from scene. It sorts out is entity has all necessary components and we need to call RemoveEntity. \param entity entity we removed component from. \param component component we"ve just removed from entity. */ virtual void UnregisterComponent(Entity * entity, Component * component);
Функции RegisterComponent, UnregisterComponent вызываются для всех систем в сцене, тогда, когда мы добавляем или удаляем Component в Entity в сцене.
Также для удобства есть еще две функции:

/** \brief This function is called only when entity has all required components. \param entity entity we want to add. */ virtual void AddEntity(Entity * entity); /** \brief This function is called only when entity had all required components, and don"t have them anymore. \param entity entity we want to remove. */ virtual void RemoveEntity(Entity * entity);
Эти функции вызываются, когда уже создан заказанный набор компонентов с помощью функции SetRequiredComponents.

Например, мы можем заказать получение только тех Entities, у которых есть ACTION_COMPONENT и SOUND_COMPONENT. Передаю это в SetRequiredComponents и - вуаля.

Чтобы понять, как это работает, распишу на примерах, какие у нас есть системы:

• TransformSystem - система которая отвечает за иерархию трансформаций.
• SwitchSystem - система которая отвечает за переключения объектов, которые могут быть в нескольких состояниях, как например разрушенное и неразрушенное.
• LodSystem - система которая отвечает за переключение лодов по расстоянию.
• ParticleEffectSystem - система которая обновляет эффекты частиц.
• RenderUpdateSystem - система которая обновляет рендер-объекты из графа сцены.
• LightUpdateSystem - система которая обновляет источники света из графа сцены.
• ActionUpdateSystem - система которая обновляет actions (действия).
• SoundUpdateSystem - система которая обновляет звуки, их позицию и ориентацию.
• UpdateSystem - система которая вызывает кастомные пользовательские апдейты.
• StaticOcclusionSystem - система применения статического окклюжена.
• StaticOcclusionBuildSystem - система построения статического окклюжена.
• SpeedTreeUpdateSystem - система апдейта деревьев Speed Tree.
• WindSystem - система расчета ветра.
• WaveSystem - система расчета колебаний от взырвов.
• FolliageSystem - система расчета растительности над ландшафтом.

В практически любой системе код выглядит следующим образом:

For (определенного набора объектов) { // получить необходимые компоненты // выполнить действия над этими объектам // записать данные в компоненты }
Системы можно классифицировать по тому как они обрабатывают объекты:

• Требуется обработка всех объектов, которые находятся в системе:
  • Физика
  • Коллизии
• Требуется обработка только помеченных объектов:
  • Система трансформаций
  • Система actions (действий)
  • Система обработки звуков
  • Система обработки частиц
• Работа со своей специально оптимизированной структурой данных:
  • Static Occlusion System

Итог

• Мы сильно повысили FPS, так как с компонентным подходом вещи стали более независимы и мы смогли их по отдельности развязать и оптимизировать.
• Архитектура стала более простой и понятной.
• Стало легко расширять движок, почти не ломая соседние системы.
• Стало меньше багов из серии «сделав что-то c лодами, сломали свитчи», и наоборот
• Появилась возможность это все распараллеливать на несколько ядер.
• На текущий момент, уже работаем над тем, чтобы все системы запускать на всех доступных ядрах.