На якому движку зроблений world of tanks. Протестуй новий движок. Новий ігровий движок
Пора купувати нові відеокарти або анонс нового движка WOT.
На WG Fest оголосили про вихід абсолютно нових танків. По суті це вже зовсім інша гра, так як новий движок, звуки, HD карти. Незважаючи на візуальні поліпшення, розробники обіцяють, що продуктивність не впаде. Якщо зараз граєте з 30 FPS, то і на новому движку буде стільки ж.
Поки доступний лише один трейлер:
Що відомо на даний момент?
- Оновлення вийде в березні 2018 року.
- Новий движок під назвою Core. (Поточний движок WOT) не поспішаючи йде в минуле.
- З існуючий движків жоден з них не зміг задовольнити розробників, тому було прийнято рішення все зробити з нуля самим.
- На розробку пішло 4 роки: 3 роки на сам движок і ще рік на створення контенту (карт).
- Для оцінки продуктивності можна вже зараз скачати спеціальний софт enCore, який проведе тест, за результатами якого можна оцінити наскільки Ваш ПК придатний до нової гри.
- enCore можна запустити в трьох режимах графіки: мінімальні, середні і ультра.
- Тест йде три хвилини, показується реплєї постановочного бою з демонстрацією нових графічних можливостей і ефектів.
Результат тесту enCore World of Tanks.
- HD карти - все локації перероблені під високу чіткість. І це стосується всіх аспектів: ландшафт, текстури, освітлення, звуки, ефекти, оточення та інше.
Повний список перероблених в HD карт.
- Повністю переписаний саундтрек. У кожної карти тепер буде своя музика, що передає унікальну атмосферу локації.
- Обіцяють, що робота над оптимізацією пророблена хороша і сильної втрати FPS бути не повинно.
BigWorld Engine - це самий передовий 3D движок для створення MMO-ігор. На ньому зроблені такі ігри як "World of Tanks", "Pealm of the Titans" від Wargaming.net і інші ігри інших світових компаній-розробників ігор. На цьому движку зроблено більше 15 MMO-ігор. Розробляється він компанією BigWorld Technology.
Оптимізована движка дозволяє створювати нізкотребовательние гри з приголомшливою графікою. Движок дозволяє перенести гри на iOS. Написаний на мові програмування C ++, реалізація ж ігровий логіки в ньому виробляється на зручному скриптовій ЯП Python. Є потужні інструменти і движок клієнт-сервер. Для звуку підтримується бібліотека FMOD, а також підключаються будь-які інші бібліотеки за допомогою плагін-системи. Працює з XML і MySQL базами. У складі інструментарію є потужні World Editor, Model Editor і Particle Editor.
Він дуже доступний в ціні. Збірка BigWorld: Indie Edition коштує всього $ 299; BigWorld: Indie Source Edition - $ 2,999; BigWorld: Commercial Edition - обговорюється індивідуально.
Цей передовий движок не поступається за можливостями інших світових движкам свого типу. Движок доступний російською, корейською, американському та японською мовами. Є документація, може працювати на браузерах. Вообщем, можете приступати до роботи, якщо є знання і старанність.
Уже недоступний для стороннього ліцензування, тому що Wargaming вирішила відмовитися від поширення свого движка.
Офіційний сайт: http://www.bigworldtech.com
The BigWorld Technology tool chain provides a complete, end-to-end MMOG content creation system that will enhance the quality and timeliness of your game. All tools are designed for cooperative production of game assets in a large team environment, ensuring effective use of resources and a smooth content pipeline.
З 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)? Чим він займається? Він працює над своїм проектом місячної бази?)
- Серб працює у нас. Він НЕ працює над проектом місячної бази. Він зараз працює над іншими проектами Варгеймінг.
Спочатку всім здавалося, що дуже хорошою ідеєю буде зробити кілька дрібних ігор, які б залучали нових користувачів в великі «танки». Після ряду експериментів виявилося, що це не працює. Незважаючи на відмінні конверсії в мобільних додатках, перехід від мобільного телефону до PC опинявся прірвою для користувачів.
Тоді в розробці у нас перебувало кілька ігор. Одна з них носила робочу назву «Sniper». Основний геймплей-ідеєю була стрілянина в снайперський режимі з стоїть в обороні танка, по іншим танкам, якими керував AI і які могли атакувати у відповідь.
В якийсь момент нам здалося, що стоїть танк - це дуже нудно, і за тиждень ми зробили прототип мультиплеєра, де танки вже могли їздити і атакувати один одного.
З цього все і почалося!
Коли ми починали розробку "Снайпера", то розглядали технології, які тоді були доступні для мобільних платформ. На той момент Unity був ще на досить ранній стадії свого розвитку: по суті, необхідних нам технологій ще не було.
Основний річчю, якої нам не вистачало, був рендеринг ландшафту c динамічної деталізацією, що є життєво необхідним для створення гри з відкритими просторами. Було кілька сторонніх бібліотек для Unity, проте їх якість залишала бажати кращого.
Також ми розуміли, що на C # ми не зможемо вичавити максимум з пристроїв, під які ми розробляємо, і завжди будемо обмежені.
Unreal Engine 3 теж не підходив по ряду схожих причин.
У підсумку, ми вирішили доопрацьовувати свій движок!
Він на той момент вже використовувався в наших попередніх казуальних проектах. Движок мав досить добре написаний низький рівень роботи з платформами і підтримував iOS, PC, Mac, плюс були розпочаті роботи по Android. Було написано багато функціональності для створення 2D-ігор. Тобто, був непоганий UI і багато всього для роботи з 2D. У ньому були перші кроки по 3D-частини, так як одна з наших ігор була повністю тривимірною.
Що у нас було в 3D-частини движка:
- Найпростіший граф сцени.
- Можливість малювання статичних мешів.
- Можливість малювання анімованих мешів зі скелетної анімацією.
- Експорт об'єктів і анімацій з Collada-формату.
Початок робіт
Почалося все з докази можливості отрисовать ландшафт на мобільних пристроях: Тоді це були iPhone 4 і iPad 1.Після кількох днів роботи ми отримали цілком функціональний динамічний ландшафт, який працював досить непогано, вимагав десь 8MB пам'яті і давав 60fps на цих пристроях. Після цього ми почали повноцінну розробку гри.
Минуло близько півроку, і маленький міні-проект перетворився в те, чим зараз є Blitz. З'явилися абсолютно нові вимоги: MMO, AAA-якість і інші вимоги, які движок в його первісному вигляді на той момент вже не міг забезпечити. Але робота кипіла повним ходом. Гра працювала і працювала непогано. Однак продуктивність була середньої, об'єктів на картах було мало, і, власне, було безліч інших обмежень.
На цьому етапі ми почали розуміти, що фундамент, який ми заклали в движок, не витримає преса реального проекту.
Як все працювало на той момент
Вся отрисовка сцен була заснована на простій концепції Scene Graph.Основний концепції були два класи:
- 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-підходу
Вирішенням цієї проблеми став компонентний підхід, комбінований c data-driven підходом. Далі по тексту я буду вживати data-driven-підхід, тому що не знайшов вдалого перекладу.Взагалі розуміння компонентного підходу у багатьох людей саме різне. Те ж - і з data-driven.
В моєму розумінні, компонентний підхід - це коли якась необхідна функціональність будується на основі незалежних компонентів. Найпростіший приклад - це електроніка. Є чіпи, у кожного чіпа є входи і виходи. Якщо чіпи підходять один до одного, їх можна з'єднати. На базі такого підходу побудована вся індустрія електроніки. є тисячі різних компонентів: Поєднуючи їх один з одним, можна отримувати абсолютно різні речі.
Основні плюси цього підходу в тому, що кожен компонент ізольований, і з більшої незалежний. Я не беру до уваги той факт, що на компонент можна подати неправильні дані, і плата згорить. Плюси цього підходу очевидні. Сьогодні можна взяти величезну кількість готових чіпів і зібрати новий пристрій.
Що ж таке data-driven. У моєму розумінні, це підхід до проектування програмного забезпечення, Коли за основу потоку виконання програми беруться дані, а не логіка.
На нашому прикладі уявимо таку ієрархію класів:
Class SceneNode (// Дані відповідають за ієрархічні трансформації Matrix4 localTransform; Matrix4 worldTransform; virtual void Update (); virtual void Draw (); Vector
Код обходу цієї ієрархії ієрархічно виглядає так:
Main Loop: rootNode-\u003e Update (); rootNode-\u003e Draw ();
У цій ієрархії C ++ успадкування ми маємо три різних незалежних потоку даних:
- трансформації
Давайте уявимо, як це має виглядати в data-driven підході. Напишу на псевдокоді, щоб була зрозуміла ідея:
// Transform Data Loop: for (each localTransform in localTransformArray) (worldTransform \u003d parent-\u003e worldTransform * localTransform;) // Lod Data Loop: for (each lod in lodArray) (// calculate lod distance and find nearest lod nearestRenderObject \u003d GetNearestRenderObject (lod); renderObjectIndex \u003d GetLodObjectRenderObjectIndex (lod); renderObjectArray \u003d renderObject;) // Mesh Render Data Loop: for (each renderObject in renderObjectArray) (RenderMesh (renderObject);)
По суті, ми розгорнули цикли роботи програми, зробивши це таким чином, щоб всі відштовхувалася від даних.
Дані в data-driven підході є ключовим елементом програми. Логіка - лише механізми обробки даних.
Нова архітектура
У якийсь момент стало зрозуміло, що треба йти в сторону Entity-based підходу до організації сцени, де Entity була сутністю, що складається з багатьох незалежних компонентів. Хотілося, щоб компоненти були повністю довільними і легко комбінували між собою.Читаючи інформацію по цій темі, я натрапив на блог 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 \u003d 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 \u200b\u200bTree.
- WindSystem - система розрахунку вітру.
- WaveSystem - система розрахунку коливань від взирвов.
- FolliageSystem - система розрахунку рослинності над ландшафтом.
У практично будь-якій системі код виглядає наступним чином:
For (певного набору об'єктів) (// отримати необхідні компоненти // виконати дії над цими об'єктами // записати дані в компоненти)
Системи можна класифікувати по тому як вони обробляють об'єкти:
- Потрібно обробка всіх об'єктів, які знаходяться в системі:
- фізика
- колізії
- Потрібно обробка тільки позначених об'єктів:
- система трансформацій
- Система actions (дій)
- Система обробки звуків
- Система обробки частинок
- Робота зі своєю спеціально оптимізована структурою даних:
- Static Occlusion System
підсумок
- Ми сильно підвищили FPS, так як з компонентним підходом речі стали більш незалежні і ми змогли їх окремо розв'язати і оптимізувати.
- Архітектура стала більш простою і зрозумілою.
- Стало легко розширювати движок, майже не ламаючи сусідні системи.
- Стало менше багів з серії «зробивши щось c лодамі, зламали свитчи», і навпаки
- З'явилася можливість це все распараллеливать на кілька ядер.
- На поточний момент, вже працюємо над тим, щоб всі системи запускати на всіх доступних ядрах.