Як ми робимо World of Warships: автоматизація експорту та верифікація контенту. BigWorld Engine - Ігрові движки - Файли для ігроробів - Створення ігор Ігровий движок біг ворлд
У цій публікації ми продовжуємо ставити питання розробникам ігор. На цей раз, інтерв'ю дає Михайло Живець, технічний директор проекту Wargaming.net.
«СВІТ NVIDIA»: Який графічний движок використовується у вашому проекті? Які мінімальні та рекомендовані системні вимоги? Чи зумовлені вони певними фічами, чи ви орієнтувалися на певний рівень поширеності 3D-карток? Ви використовуєте спеціальні можливості останніх поколінь графічних карт або орієнтуєтеся на стандарт?
Проект World of Tanks використовує графічний двигун BigWorld з власними доробками, які потрібно було внести в силу специфіки проекту. Особливістю движка є орієнтованість на відкриті світи з частинами карти, що динамічно підвантажуються, як, наприклад, зроблено в World of Warcraft. Ми намагаємося використовувати технології, що дозволяють створити на екрані монітора картинку, близьку до ескізів наших художників та адаптуємо їх до системних вимог.
«СВІТ NVIDIA»: Чи значно відрізняються, з погляду програмування, відеокарти від NVIDIA та ATI? Чи можна просто писати через DirectX або OpenGL і отримувати ефективний код для обох вендорів або для кожного виробника, потрібно робити свої версії функцій? Який підхід ви використовували?
М. Ж.:Відеокарти від різних виробників мають свої специфічні особливості. Це може бути підтримка спеціальних форматів текстур або доступ до текстур із вертекстного шейдера. Разом з тим, при використанні загального функціоналу, що надається API DirectX або OpenGL, відмінності між GPU двох вендорів мінімальні і, наслідком різниці між відеокартами від ATI та NVIDIA, є швидше додаткові можливості, ніж якісь обмеження. Що ж до «особливого відношення» з боку двигуна, BigWorld не забезпечує вирішальної переваги для жодного з вендорів.
«СВІТ NVIDIA»: З чим пов'язані відмінності у швидкості роботи ігор на картах NVIDIA та ATI? Чи це властивістю алгоритмів ігрового движка чи більше залежить від ігрових сцен? Тобто, наприклад, в одній грі більш високополігональні сцени, а в іншій великий показник overdraw або багато напівпрозорих текстур зі складним антиаліасингом, і тому відеокарти, які мають більший fillrate, справляються краще? («Чи любила» ваша програма якусь архітектуру?).
М. Ж.:Відмінності в основному зводяться до апаратних особливостей (відмінності в ширині шин пам'яті, кількості блоків растеризації, шейдерних блоків і т. д.), а також реалізації драйверів. Чим більш збалансованою є навантаження на CPU та GPU і чим краще організована сцена, тим менш особливості відеокарти повинні позначатися на загальній продуктивності. Сюди можна віднести ощадливе ставлення до кількості і роздільної здатності текстур, низький overdraw від частинок і прозорих об'єктів, використання LOD-ів, групування об'єктів в batches і так далі - все це однаково лягає на плечі розробників двигуна і дизайнерів гри.
«СВІТ NVIDIA»: При тестуванні відеокарт зазвичай використовуються приблизно однакові набори ігор. Наскільки доречним є подібне узагальнення при виведенні результатів тестів для таких різних жанрів, як 3D-шутери, RPG від третьої особи та стратегії. Чи показовими є популярні тести для продуктивності вашої гри?
М. Ж.:Я не ділив би додатки по жанрах. Все знаходиться виключно в руках розробників, використовуваних алгоритмами. У будь-якому випадку, розробники намагаються якомога більш збалансовано навантажити систему користувача та досягти при цьому максимальної привабливості продукту.
Дивлячись на показники FPS в іграх, на кшталт Crysis або останньої Need for Speed, можна приблизно уявити собі продуктивність у ряді інших сучасних ігор, тому тут ми з усією впевненістю можемо говорити, що ці тести досить показові. Ігри такого рівня можна використовувати як бенчмарки для відеокарт, оскільки на високих установках якості вони по-максимуму навантажують графічну підсистему.
«СВІТ NVIDIA»: З чим пов'язане зростання навантаження на CPU зі збільшенням дозволу? Чи вірно, що збільшення деталізації моделей для мінімізації їх «незграбності» вимагає більших потужностей CPU для анімації, відсікання невидимих примітивів, побудови тіньових обсягів тощо? Чи був у вашій грі такий ефект?
М. Ж.:Збільшення дозволу не повинно безпосередньо впливати на завантаження CPU, якщо, звичайно, в движку не передбачено автоматичне збільшення полігональності моделей, додаткова тесселяція та більша кількість кадрів анімації моделей. Якщо зі збільшенням дозволу навантаження на CPU зростає без причини, проблема криється або в ігровому коді, або драйвер відеокарти.
«СВІТ NVIDIA»: Чи може навантаження на CPU збільшитись при включенні анізотропної фільтрації? Те саме стосується Full Scene Antialiasing. Якщо для цього потрібно всю сцену промалювати у вдвічі більшій роздільній здатності, то теоретично збільшитися може і кількість трикутників.
М. Ж.:Відповідь на обидва питання – ні. У разі включення анізотропної фільтрації зросте навантаження на блоки текстурування. При включеному FSAA більше роботи дістанеться піксельному конвеєру. Що стосується більшого дозволу, то при подвоєнні кількості пікселів вдвічі збільшиться кількість операцій у піксельному шейдері, блоках растеризації та TMU.
«СВІТ NVIDIA»: Вже дуже довго триває процес перенесення розрахунків на шейдери GPU, спочатку це було T&L, відсікання. Чи вважається зараз анімація моделей на GPU? Що, перш за все, залишається в плані 3D-движка для розрахунків на CPU? (Що ви рахували на GPU, крім T&L?).
М. Ж.:Двигун, який використовується в нашому проекті, не виконує жодних розрахунків на GPU. Теоретично, якби нам, скажімо, доводилося вважати фізику безлічі об'єктів у реальному часі, ми могли б взяти той же PhysX, який чудово виконує обчислення на GPU NVIDIA, але через специфіку проекту, нам вистачає можливостей CPU.
«СВІТ NVIDIA»: В останні роки, відеоприскорювачі стали «інтелектуальними», самі використовують методи відсікання невидимих примітивів, як-от: ієрархічний z-буфер. Наскільки вони ефективні? Чи можна зараз просто запхати всі трикутники у прискорювач відео, щоб він намалював все сам? За часів перших 3D-ігор (серії Quake і Unreal) використовувалися витончені методи зменшення трикутників, що промальовуються, BSP-дерева тощо. Наскільки це тепер актуально?
М. Ж.:Звичайно ж, не варто розраховувати на те, що відеоприскорювач самостійно визначить, які об'єкти варто відмалювати, а які не буде видно. Доводиться застосовувати методику раннього відсікання непотрібного, оскільки передача надмірної інформації на GPU призводить до падіння швидкодії. Тож проблема досі актуальна, хоч і значно меншою мірою. Особливо у тих випадках, коли доводиться промальовувати велике числорізноманітних об'єктів. Справа в тому, що сучасні картки зайняті не лише відсіканням непотрібного, їх навантажили ще й розрахунками складніших типів освітлення тощо. Відповідно, якщо є можливість та ресурси допомогти відеокарті – це треба зробити.
Наприклад, у движку BigWorld, для відсікання невидимих об'єктів до етапу промальовування, використовується бібліотека Umbra. Сцена являє собою BSP-дерево, яке також дозволяє швидко та ефективно відкинути фрагменти сцени, які явно не потрапляють в область видимості.
«СВІТ NVIDIA»: У свій час була така ситуація, приблизно під час кризи P4, що вузьким місцем системи був процесор, який не міг «завантажити» відеоприскорювач і для збільшення FPS в іграх, перш за все була потрібна топова модель CPU. Чи простежується зараз подібна залежність між CPU і GPU, або процесори переступили якийсь критичний рівень продуктивності і можна взяти недорогий процесор і потужну відеокарту? Маються на увазі ігри з акцентом на графіку, за стилем типу Quake та Doom.
М. Ж.:Слабкий процесор при потужній відеокарті - вузьке місце системи, оскільки безліч операцій як низького (формування драйвером потоку команд, що управляють), так і високого рівня (прикладна логіка - ігровий цикл, оновлення частинок, анімація персонажів, фізика, звук і т. д.) безпосередньо залежать від продуктивності CPU. Велику роль відіграє і обсяг кеш-пам'яті процесора, який на дешевих моделях є досить малим.
Для максимально ефективної роботи відеокарти також необхідні системні ресурси, швидкісна системна шина, достатній обсяг оперативної пам'яті гарної швидкодії. Найчастіше відеопідсистема не в змозі показати, на що вона здатна просто тому, що CPU не встигає передати їй необхідні дані. Отже, якщо мова зайде про економію на ресурсах, достатньо придбати середній процесор, материнську плату трохи вище за середній рівень, але не скупитися на відеокарту і оперативну пам'ять.
«СВІТ NVIDIA»: DirectX від версії до версії стає все більше схожим на графічний двигун. Чи правда, що зараз 3D-програма складається практично з викликів Direct3D API і основна частина обчислень здійснюється в ньому? Як ви оцінюєте останню версію DirectX? Чи стала вона майже повноцінним двигуном і скільки ще знадобиться версій для цього?
М. Ж.: Direct3D не можна розглядати як окремий графічний двигун і навряд чи, в найближчому майбутньому, Microsoft піде на такий крок, як створення власного ігрового движка. Це недоцільно в силу низки причин, у тому числі через безліч відмінностей у вимогах до двигуна для різних ігрових проектів. Наприклад, автосимулятор, стратегія в реальному часі та 3D-шутер мають відмінні особливості, що не дозволяють один і той же двигун використовувати однаково ефективно у всіх трьох випадках.
У десятій версії Direct3D з'явилися нові рівні абстракції при роботі з ресурсами і додаткові можливості розробки шейдерів, стали доступні такі трюки, як Stream Output. Разом з тим, D3D залишилася тим же, чим і була - низькорівневим API, використовуючи який розробник може спроектувати ігровий двигун для конкретного завдання.
«СВІТ NVIDIA»: Взагалі, Останнім часомвідбувається «глобалізація» ігрових та 3D-движків. Існує декілька найпопулярніших платформ, на яких виготовляється безліч ігор. Чи це об'єктивний процес? Чи має сенс сьогодні фірмі-розробнику писати свій двигун, коли можна ліцензувати готовий повнофункціональний. Наприклад, нещодавно вийшла чергова версія Unreal Engine, яка вже була завантажена десятки тисяч разів. Чи довго залишилося до моменту, коли всі ігри використовуватимуть один-два 3D-движки?
М. Ж.:Ми використовуємо BigWorld і поки що задоволені ним. Що стосується «глобалізації», навряд чи станеться диво і компанії CryTek, Epic та низка інших вирішать віддати один одному шматок ринку ігрових двигунів. Не варто забувати, що, як правило, ігри, створені на тому самому движку, дуже схожі, а це не завжди добре. Швидше за все, кількість двигунів буде тільки зростати, з доглядом у все більш тонку спеціалізацію. У будь-якому випадку, унікальні двигуни будуть завжди.
«СВІТ NVIDIA»: Чи правда, що останні відеокарти стали дуже потужним по raw power і, не відрізняючись від колишніх моделей у плані ефектів, можуть розкрити свій потенціал, в першу чергу, на системах з великими моніторами (від 1920×1200) у режимах з антиаліасингом та повною анізотропною фільтрацією? Чи має сенс людині з монітором, наприклад, 1280x1024, не будучи фанатом фільтрації та AA, купувати нову відеокарту, таку як GTX285 та Radeon на новому техпроцесі?
М. Ж.:Згоден, це так. Але, все ж таки, не варто забувати і про пристойні монітори, з достатньою якістю кольору, високою роздільною здатністю, контрастністю. Отримуватимете від гри набагато більше задоволення. Але навіть якщо ви вирішили не змінювати свій улюблений монітор, карту замінювати варто, тому що це однозначно призведе до збільшення продуктивності вашої системи, адже частина старих алгоритмів розрахунку на нових картках реалізована вже апаратно.
«СВІТ NVIDIA»: Раніше розробники ігор були консервативні у використанні можливостей та ефектів найновіших відеокарт, оскільки орієнтувалися на найбільш поширені на даний момент карти. Тобто виходить, наприклад, умовний DirectX n, а ігри все ще пишуться під DirectX n-2. Чи змінилася ситуація останнім часом? Чи легко в грі використовувати можливості за новими ефектами для відеоприскорювачів, що недавно вийшли?
М. Ж.:Якби Windows 7 вийшла на пару років раніше або Microsoft відмовилася від ідеї прив'язати DirectX 10 до Windows Vista, розробники ігор вже давно перейшли б як мінімум на десяту версію API. Однак зараз маємо те, що маємо: всі хіти останніх років використовують DX9, а підтримка DX10 — найчастіше маркетинговий хід.
«СВІТ NVIDIA»: Наскільки інтенсивно зазвичай ігри використовують потужності найновіших, на момент виходу відеоприскорювачів? Наприклад, чи використовуються зараз усі можливості архітектури GT200? Чи типова ситуація, коли на момент виходу новий GPU просто трохи краще виконує існуючі ігри, але з часом з оптимізацією ігор для нової архітектури та застосування нових фіч його цінність ніби зростає? Наскільки ваша гра використовує нові фічі?
М. Ж.:У випадку з новою архітектурою та її уніфікованою шейдерною моделлю виграли практично всі. Завантаженість вершинного та піксельного конвеєрів GPU вирівнялася там, де були великі перекоси у той чи інший бік. Що стосується нових можливостей, то чим більше відсоток відеокарт з підтримкою тієї чи іншої фічі, тим охочіше розробники ігор використовуватимуть їх у своїх проектах. Використовуваний нами BigWorld орієнтується на можливості DirectX 9 та SM 3.0.
«СВІТ NVIDIA»: Зараз більшої популярності набули онлайн-ігри. Чи це наклало відбиток на індустрію відеоприскорювачів? Оскільки движки подібних ігор орієнтовані на базовий набір фіч, що є у великої кількості користувачів, а показники FPS все одно лімітовані інтернет-з'єднанням, для онлайн-ігор виглядає безглуздим купувати топовий відеоприскорювач. Чи це не є гальмом розвитку ігрової графіки? Збільшили популярність браузерні ігри в повному 2D, для яких прискорювач не потрібен.
М. Ж.:Якщо подивитися на кількість передплатників World of Warcraft і порівняти його, скажімо, з Aion або Age of Conan, відповідь очевидна: для онлайн-ігор, насамперед важливі геймплей, опрацювання ігрового світу, захоплююча PvP-складова та інші моменти, що не відносяться безпосередньо до графіки. Гальмом для розвитку графіки це не є, адже не MMORPG єдиним живуть гравці. Нові шутери, автосимулятори та RPG неминуче будуть і надалі піднімати планку якості 3D-графіки в іграх. MMO-ігри повільно, але вірно йдуть тим самим шляхом, прагнучи залучити більшу ігрову аудиторію. До речі, та ж Blizzard зараз, за чутками, працює над новою MMOG і навряд чи вони будуть використовувати двигун 8-річної витримки у своєму новому проекті.
«СВІТ NVIDIA»: Наскільки технології SLI та Crossfire вимагають підтримки від розробника гри? Із чим пов'язана різна ефективність цих технологій для різних ігор? З особливостями ігрового движка чи з ігровими сценами? Наскільки ваша гра виграє від використання SLI та Crossfire?
М. Ж.:Оптимізувати двигун під дві відеокарти - дуже складний процес. Необхідно акуратно організувати компактну передачу даних на GPU і збалансувати двигун навантаження між GPU і CPU. Якщо програма, при роботі на одній карті, вже впирається в CPU або передачу даних по шині, про SLI або Crossfire доведеться забути. Цим, власне, і відрізняються ті чи інші ігри під час роботи на спарених прискорювачах. Наша гра поки що дає приріст продуктивності близько 10% на SLI, але зараз ми оптимізуємо ряд модулів з метою покращення роботи в подібних режимах.
«СВІТ NVIDIA»: Вже давно багато говориться про кризу ринку для PC і поступового переходу ігор на приставки. Але цього поки що не сталося. Чи можна очікувати цього у майбутньому? Чи правда, що через стандартне «залізо», програмувати графіку для приставок набагато легше? Чи одвічне відставання приставок за рівнем «заліза» нівелює уніфікованість?
М. Ж.:Ігрові консолі мають ряд переваг для розробника (одна платформа, один набір можливостей і, як наслідок, однакова продуктивність у всіх гравців), але ринок PC-ігор і, зокрема, онлайн-ігор постійно зростає, так що очікувати на повальний переход на консолі не стоїть. Не варто забувати і про те, що вихід ігрових приставок з потужнішим залізом стримують самі виробники консолей, прагнучи відшкодувати витрати на випуск префіксів попереднього покоління за рахунок продажів поточних ігор. Тому, перш ніж випускати Playstation 4 або Xbox 720, пройде чимало часу і вийде безліч проектів, орієнтованих на поточне покоління приставок. В окремих випадках, таких як Nintendo Wii, передове «залізо» виявляється зовсім непотрібним, для досягнення відмінного результату.
«СВІТ NVIDIA»: Чи правда, що зараз в іграх майже повально використовується поєднання проекційного методу для побудови тіней від моделей і методу тіньових обсягів з динамічно або статично прорахованими обсягами для тіней на об'єкти, що рухаються, моделі і зброю, і від рухомих частин моделей на самих себе?
М. Ж.:Замість тіньових обсягів часто використовується та сама проекційна техніка, з модифікаціями (каскадні карти тіней, окрема тіньова карта для самозатінення та ін.). Тіньові обсяги дають чітку межу тіні, але страждають через високий показник fillrate, додаткові розрахунки на CPU і складну реалізацію м'яких країв тіней.
«СВІТ NVIDIA»: Чи є у існуючих методів побудови тіней перспектива з погляду побудови динамічного освітлення всієї сцени? Тобто з поступовим зростанням потужності відеоприскорювачів їх можна буде використовувати для розрахунку всього освітлення в динаміці? Чи знадобиться застосування якихось нових методів?
М. Ж.:Проективні тіні пройшли досить довгий шлях у сучасних іграх і ті чи інші їх модифікації будуть використовуватися ще довгий час, поєднуючись із додатковими ефектами, на кшталт SSAO. Звичайно, якщо буде безкоштовний рейтрейсинг на GPU, то ні проективні, ні волюметричні тіні не мають жодних шансів.
«СВІТ NVIDIA»: Як ви оцінюєте технологію Precomputed Radiance Transfer з точки зору застосування в іграх? Чи збираєтеся її використовувати в майбутньому?
М. Ж.: PRT вимагає тривалих розрахунків, не поєднується з анімованими моделями і в принципі не дає великих переваг у візуальному плані, порівняно з тим самим Ambient Occlusion. Як приклад можна взяти Halo 3, яка використовує PRT, але не виділяється якістю освітлення на тлі тих же Gears of War або Crysis.
«СВІТ NVIDIA»: DirectX 11 та архітектура Fermi, чи варто чекати DirectX 11 прискорювачів та ігор, чи це прохідна версія API? Чи може молодша модель Direct X 11 прискорювача, поступаючись за абсолютною потужністю, fill rate, бути кращою за стару, але більш потужну модель з підтримкою DirectX 10? Чи можна очікувати, з виходом архітектури Fermi, якогось якісного стрибка в ігровій графіці, чи це буде екстенсивне зростання, більше трикутників, більша швидкість у високих дозволах тощо? Якби в момент розробки вашої гри була доступна Fermi, наскільки інший гра була б з погляду графіки?
М. Ж.:Одинадцята версія DirectX пропонує більше можливостей для обчислень на GPU, при цьому, якщо порівнювати з DX10, жодних докорінних поліпшень для 3D-графіки не несе. Що стосується Fermi, найцікавішою особливістю, на мій погляд, є керована тесселяція для 3D-моделей.
Михайло Живець, технічний директор проекту World of Tanks, компанія Wargaming.net
Після прем'єрних закритих показів World of Warships на gamescom та «ІгроСвіті» офіційний запуск гри дедалі ближче. Зараз у розпалі закрите альфа-тестування, і нам, розробникам Lesta Studio, пітерського підрозділу Wargaming, ще доведеться вирішити цілу купу питань. При цьому чимало перешкод таки вдалося залишити позаду. Нижче – розповідь про те, як ми адаптували експортер нашого двигуна під потреби «Кораблів» та вибудовували процес верифікації контенту.
Стандартне постачання двигуна
Будь-який двигун включає в комплект постачання інструментарій для експортера 3D-моделей із 3D-редакторів у свій власний формат даних. Наш BigWorld, на основі якого зроблено World of Tanks, не є винятком. Він підтримує експорт з 3D Max та Maya. Майже будь-який ігровий проект вимагає адаптації стандартних експортерів під специфіку проекту. У проекті специфікою є моделі кораблів.Перша версія адаптованого експортера з Maya просто «донавчила» його розпізнавати складнішу структуру сцени кораблів. До існуючого C++ коду додалося трохи керуючого коду на Python, а також плагін для Maya з UI на wxWidget. Виглядало це приблизно так:
UI адаптованого експортера
Інструмент, що вийшов, мав масу недоліків.
Експорт можна було здійснювати лише за участю користувача, який мав «сказати» експортеру, що містить сцену. Про використання даного інструменту автоматизації різних процесів, наприклад, автоматичної верифікації контенту на етапі складання дистрибутива, не могло бути й мови.
Експортер вимагав від користувача знань про далеко не очевидні параметри, повільно працював, практично не підтримував верифікацію сцени, а також вимагав величезну кількість ресурсів на підтримку.
Архітектура була основною проблемою для розширення функціональності у майбутньому. Експорт був фактично атомарною операцією (набір спагетті-функцій), яка транслювала дані з однієї структури (завантаженої сцени Maya) до іншої структури (BigWorld) безпосередньо у фізичні файли. Коли серіалізатори та бізнес-логіка реалізовані «в моноліті», а модель даних просто відсутня, неможливо додавати обробку даних (pre/post-processing), а також повторно використовувати (code reuse) серіалізатори та модель даних в інших інструментах, що реалізують власний бізнес -логіку. Будувати складніші процеси виробництва контенту було неможливо.
Згодом нарощувати нову функціональність у існуючому коді стало практично неможливо. Вирішили переписати експортер «з нуля», заклавши в нього нову архітектуру.
Суворі будні
Рівень нашого проекту підвищив вимоги до якості, складності та обсягу контенту. За останні кілька років наша студія сильно зросла. У нас з'явилася можливість виділяти достатньо ресурсів на завдання, пов'язані з виробництвом контенту. До нас прийшли професіонали, які мають великий бекграунд у розробці архітектури, технології на C++/C#. Для розробників експортера це був перший досвід використання Python і Maya API. Це внесло додаткові ризики, які потрібно враховувати.Рефакторинг експортера ми оцінили у два-три людино-місяці. Без оптимізму в геймдеві аж ніяк не можна.
До ризиків ми віднесли:
відсутність формальних вимог;
рівень володіння Python;
складність Maya API;
рефакторинг алгоритмів обробки примітивів
Багато фактичного часу пішло на збір вимог з неформалізованих джерел, таких як розробники, які стали менеджерами, «старожили», торсіонні поля та код експортера, що існував. Ці крихти знань були формалізовані та записані у вигляді вимог, специфікацій та UML-діаграм у Confluence.
Перші прототипи показали необхідність використання концепції namespaces та модулів Python (__init__.py). Також було опрацьовано механізм, що дозволяє «прозоро» використовувати функціональність із C++ бібліотек (.pyd).
Про складність та заплутаність Maya API можна написати окрему книгу. Будь-яка функціональність вимагала прототипування, консультацій з 3D-художниками та з розробниками двигуна (rendering).
У стандартному експортері була власна реалізація великої кількості алгоритмів, наприклад, тріангуляція полігонів, розрахунок матриць трансформацій вкладених вузлів тощо. Ми відмовилися від них на користь використання Maya API, що значно підвищило продуктивність експортера.
До законів Мерфі давно настав час дописати правило, що будь-який задумений вами проект обов'язково буде реалізований за час не більше ніж «x3» від запланованого, якщо ви його не кинете.
Результат коштував докладених нами зусиль. Зрештою, навіть наш головний художник, який відповідає за експорт моделей, після кількох місяців експлуатації знайшов наш експортер «майже ідеальним».
Заглянемо під капот
У нашій студії активно використовуються скрипти на Python. Ми намагалися реалізувати на ньому весь експортер. Природно, Python не підходить для обробки великих бінарних даних - таких як контейнери вершин (vertex buffer), контейнери індексів вершин (index buffer) і т. д. Модель даних і серіалізатори подібних контейнерів були реалізовані на C++ у вигляді бібліотеки (. , яка природно "вписалися" в модель даних на Python. Уся бізнес-логіка була реалізована на Python.Фреймворк експортера планувалося застосовувати як для завдання «ручного» експорту з Maya, але й будь-яких завдань, де його функціональність можна було б повторно використовувати, наприклад, для автоматизації верифікації контенту. Від будь-якого інструментарію, що розробляється, ми вимагаємо наявність інтерфейсів (API) для Python, командного рядка (command line) та UI інструментів.
Архітектура
Архітектура фреймворку експортера модульна, пошарова. Існують фізичний та логічний шари, а також шар предметної області. Кожен шар містить окремі модулі: модель даних, бізнес-логіка, серіалізатори, а також конвертори, які вміють перетворювати модель даних одного шару модель даних іншого шару. Фізичний та логічний шари фактично реалізують аналог ORM-архітектури.Архітектура шару предметної області спроектована для зручного оброблення моделі даних бізнес-логікою. Вона повністю ізольована і не містить жодних припущень про те, як вона буде серіалізована у фізичне сховище.
Пошарова архітектура експортера
Процес експорту
Пошарова архітектура вносить певні особливості процесу експорту. Фактично ми десеріалізуємо дві (або більше) моделей із різних джерел (Maya та BigWorld Engine). Після цього відбувається об'єднання цих моделей в одну нову. Далі нова модель серіалізується у BigWorld-Engine-формат.
Процес експорту
Гнучкість процесу виробництва контенту
Реалізована архітектура дозволяє досить легко вибудовувати складні процеси виробництва контенту. Наприклад, первинна модель корабля у нас технологічно складається із трьох окремих сцен Maya, кожну з яких одночасно розробляють різні відділи:Перша сцена містить візуальну модель (visual model) та модель колізій (collision model).
Друга сцена містить балістичну модель (ballistic model).
Третя містить порти ефектів (effects ports).
Також інструментарій двигуна (редактори) додає (редагує) власні дані в похідній моделі формату двигуна (четверта сцена).
Експортер легко вирішує нетривіальне завдання об'єднання всіх чотирьох сцен в одну результуючу модель корабля.
Верифікація контенту
Система верифікації контенту дозволяє нам шукати помилки контенту як у кожному шарі (джерелі) окремо, так і в результуючому контенті. Число верифікаторів зараз сягає кількох десятків. Автоматична верифікація контенту вбудована у процес складання дистрибутива (build), що дозволяє максимально виключити людський фактор та гарантувати цілісність та технічну чистоту контенту.
Приклад верифікації моделі корабля в Maya
Бюджети контенту та качка у ванній
Важливою складовою процесу верифікації контенту є перевірка бюджетів, наприклад верифікація полігонажних бюджетів. На малюнку нижче відображена інформація про кількість трикутників для візуальної моделі по кожному човну:
UI-плагіна Maya
Яскравою ілюстрацією необхідності такої верифікації є байка, розказана мені колегами про один із попередніх проектів. На карті була ділянка, забудована будинками, що не руйнуються. Як тільки камера звертала свій погляд на цю ділянку, FPS відразу ж дико падав. Після вивчення проблеми з'ясувалося, що всередині одного з будиночків стояла ванна, в якій плавала маленька "пластикова" качечка. Все це виглядало б забавною витівкою художників, якби не та обставина, що модель качки містила близько мільйона полігонів.
На практиці дуже важко дотримуватися бюджетного значення. Багато моделей об'єктивно є винятками. Завдання бюджетного значення як діапазону також вирішує проблему, оскільки з часом полігонаж моделей просто починає прагнути до верхнього значення діапазону. У нашому випадку ми плануємо змінювати персональні бюджети тих моделей, які не відповідають стандартному бюджету даного типу моделей.
Обробка контенту
На кожному етапі експорту потрібно проводити обробку (pre/post-processing). Наприклад, перед конвертацією логічної моделі даних шару Maya модель даних предметної області для гармат ППО потрібно попереднє обертання скелета гармати на 45 градусів по осі Y і видалення скелета. Наша архітектура дозволила прозоро вбудовувати різноманітні обробки на будь-якому етапі експорту.
Приклад моделі до та після pre-processing
Підтримка x64
Досить недавно наші художники в масовому порядку перейшли з 32-бітної Maya 2012 на 64-бітну Maya 2014. Так як експортер майже повністю написаний на Python, у нас практично не виникло проблем із підтримкою x64. Лише бібліотека (.pyd), реалізована на C++, вимагає невеликого «шаманства».Зараз експортер можна легко використовувати як у x32, так і в x64 процесах, оскільки він сам визначає та підвантажує необхідне збирання C++ бібліотеки (.pyd).
Верифікація карт
Розробляючи архітектуру експортера, ми не могли припустити заздалегідь, у яких інструментах і автоматизаціях вдасться його повторно використовувати. Автоматизація верифікації карток є прикладом того, як «правильна» архітектура експортера знайшла своє застосування в іншому інструменті.Верифікація карт будує та верифікує граф залежностей картки від інших об'єктів, розташованих на ній. Зокрема, на карті використовуються візуальні моделі ландшафту (камені, айсберги), будівель (будиночки, ангари, пристані), техніки (літаки, човни) тощо.
Особливість верифікатора карт полягає в тому, що він може верифікувати не просто наявність файлів цих візуальних моделей, а й самі моделі, використовуючи фреймворк експортера. Це дозволило виключити людський чинник, коли відділу розробки карток (LA) доводиться «вірити на слово» відділу розробки 3D-моделей (3D Art), що використовуються технічно коректні моделі.
Складання дистрибутива
Фреймворк експортера знайшов своє застосування у процесі підготовки пакета контенту (content pack) для дистрибутива. У дистрибутив не повинні потрапити моделі, які:Вже не використовуються;
знаходяться ще на стадії розробки;
призначені для наступних версій продукту.
За базовим списком ігрових об'єктів (root game objects) потрібно побудувати граф залежностей, за яким буде сформовано повний списокнеобхідного контенту. Немає нічого простішого, ніж десеріалізувати модель за допомогою фреймворку експортера і «дізнатися», які моделі ще потрібні (content references).
Підсумки
Історія розробки нашого експортера показала, як із простого вузькоспеціалізованого інструменту він еволюціонував у потужну систему, яка вирішувала свої безпосередні завдання, а також знайшла застосування в інших процесах виробництва контенту. Основою його успішного розвитку та повторного використання є модульна архітектура, що дозволяє використовувати його окремі «кубики» для побудови інших систем.У найближчому майбутньому експортер має ще одне випробування, пов'язане зі зміною формату файлів BigWorld Engine. Ми впевнені, що закладена архітектура не зазнає жодних труднощів та зможе підтримувати роботу як з існуючим, так і з новим форматом файлів.
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 виконує повністю, end-to-end MMOG content creation system, що буде поліпшення якості і timeliness з вашої гри. Всі інструменти будуть розроблені для координаційного виробництва гри акцій в великому обсязі, сприяння ефективному використанню ресурсів і глибокого вмісту pipeline.
У вас виникли проблеми із пошуком певного відеоролика? Тоді ця сторінка допоможе вам знайти такий потрібний вам ролик. Ми легко опрацюємо ваші запити і видамо вам усі результати. Неважливо чим ви цікавитеся і що ви шукаєте, ми запросто знайдемо необхідний ролик, якої б спрямованості він не був би.
Якщо ж у вас цікавить сучасні новини, то ми готові запропонувати вам найактуальніші новинні новини в усіх напрямках. Результати футбольних матчів, політичні події чи світові, глобальні проблеми. Ви завжди будете в курсі всіх подій, якщо користуватиметеся нашим чудовим пошуком. Інформованість відеороликів, що надаються нами, і їх якість залежить не від нас, а від тих, хто їх залив в інтернет простори. Ми лише постачаємо вас тим, що ви шукаєте і вимагаєте. У будь-якому випадку, користуючись нашим пошуком, ви знатимете всі новини у світі.
Втім, світова економіка це теж досить цікава тема, яка хвилює багатьох. Від економічного стану різних країн залежить чимало. Наприклад, імпорт та експорт, будь-яких продуктів харчування або техніки. Той самий рівень життя безпосередньо залежить від стану країни, як і зарплати та інше. Чим може бути корисна така інформація? Вона допоможе вам не тільки адаптуватися до наслідків, але й може застерегти від поїздки до тієї чи іншої країни. Якщо ви запеклий мандрівник, то обов'язково скористайтесь нашим пошуком.
Нині дуже складно розібратися в політичних інтригах і для розуміння ситуації потрібно знайти та порівняти дуже багато різної інформації. А тому ми запросто знайдемо для вас різноманітні виступи депутатів ДЕРЖДУМИ та їхні заяви за усі минулі роки. Ви зможете з легкістю розібратися у політиці та ситуації на політичній арені. Політика різних країн стане вам зрозумілою і ви запросто зможете підготувати себе до майбутніх змін або адаптуватися вже в наших реаліях.
Втім, ви можете знайти тут не тільки різні новини всього світу. Ви також запросто зможете підшукати собі кінострічку, яку буде приємно подивитися ввечері з пляшкою пива або попкорну. У нашій пошуковій базі існують фільми на будь-який смак та колір, ви без особливих проблем зможете знайти для себе цікаву картину. Ми запросто знайдемо для вас навіть найстаріші і найважчі твори, як і відому всім класику - наприклад Зоряні війни: Імперія завдає удару у відповідь.
Якщо ж ви просто хочете трохи відпочити і знаходитеся в пошуку смішних роликів, то ми можемо вгамувати і тут вашу спрагу. Ми знайдемо мільйон мільйонів розважальних відеороликів з усієї планети. Короткі приколи запросто піднімуть вам настрій і ще цілий день вас радуватимуть. Користуючись зручною системою пошуку, ви зможете знайти саме те, що вас розсмішить.
Як ви вже зрозуміли, ми працюємо не покладаючи рук, щоб ви завжди отримували саме те, що вам необхідно. Ми створили цей чудовий пошук спеціально для вас, щоб вам вдалося знайти необхідну інформацію у вигляді відеоролика і подивитися її на зручному плеєрі.