Новий інтерфейс world of tanks. Постреліз: проблеми зростання і шляхи їх рішень

Сьогодні ми проведемо екскурс в історію розвитку Graphical User Interface (GUI) в грі World of Tanks.

Гра пройшла довгий шлях до успіху, і її GUI змінювався і повністю перероблявся кілька разів в гонитві за зростаючими вимогами армії танкістів, яка неухильно росла.

Пропрацювавши в відділі GUI Programming два з половиною роки, я отримав уявлення про те, як розвивався сам інтерфейс в технологічному плані і як змінювалися підходи та процеси, це розвиток супроводжували.

Перші кроки: використання інструментів BigWorld

Починалося все з того, що в грудні 2008 народилася ідея проекту. Всі, хто грав в танки, думаю, знають, що початковою ідеєю було зробити гру про ельфів і орків, але, коли гарненько все продумали, вирішили зупинитися на танках (див. Заголовної фото).

Гру почали робити на движку BigWorld, який надавав власний набір інструментів для створення GUI. Ми пішли по шляху найменшого опору і робили перші інтерфейси саме на BigWorld GUI.

Як це працювало з точки зору технічної реалізації:

• декларативно в XML описувалася структура і візуальна частина GUI;
• загальний layout для великої вьюха - стилі самої вьюха і набір основних блоків, її складали, описаний в XML;
• кожен з блоків описаний в окремому XML із зазначенням використовуваних стилів і компонентів. Для компонентів задавалися їх налаштування (іменування, локалізаційні повідомлення, посилання на стилі);
• стилі описувалися в окремих XML-файлах, де задавалися розміри, позиції, які використовуються текстури, шрифти, кольори, z-order і бог знає що ще;
• при старті клієнта всі ці XML-файли завантажувалися в Python і Парс, після чого починався процес створення інтерфейсів, їх ініціалізації і підключення до ігрової логіки.

Ось приклад, видерті з надр SVN-проекту:

hangar.xml - опис блоків UI в ангарі:

account_info components / account fitting components / fitting ...
account.xml - опис блоку з інформацією про акаунт:

account_name ElideRight #tips: hangar / account_name account_exp #menu: hangar / account_info / experience #tips: hangar / account_exp ...
styles / common.xml - опис стилів для загальних компонентів:

styles / hangar.xml - опис стилів для компонентів в ангарі:

Начебто все дуже структуровано і зрозуміло. Але, як виявилося, у такого підходу було кілька мінусів:

• робота з багаторівневими XML складна в розумінні і приводила до великої кількості помилок, які важко локалізувати і виправити (наприклад, описки в іменуванні компонентів і шляхи до текстур, порушення структури XML-документа);
• відсутність візуальної середовища розробки. Єдина можливість отримання візуального результату - запуск клієнта гри і відтворення необхідного оточення для перегляду потрібного інтерфейсу. Уявити, як все це буде виглядати, подивившись на XML, було просто нереально;
• погана продуктивність при обробці користувальницького введення (особливо це було помітно в чаті);
• невеликий набір компонентів з коробки і складність додавання нових компонентів;
• висока залученість програмістів в процес створення і внесення змін (навіть мінімальних) в GUI;
• відсутність інструменту для створення анімації.

Всі ці мінуси приводили до створення інтерфейсів в стилі Programmer Art. За схематичного начерку програмісти робили layout в XML, і тільки потім художники створювали необхідні текстури і передавали все назад програмістам для фінальної налаштування і напілінга. Ось приклад такого інтерфейсу (на фото - робоче місце керівника проекту Олександра Шиляєва з запущеним танковим клієнтом на стадії закритого альфа-тесту):

Одна з перших версій бойового інтерфейсу:

І трохи пізніша його версія:

Дуже швидко стало зрозуміло, що такий підхід - тупиковий. Був проведений аналіз ринку middleware-рішень. Як виявилося, мейнстрімом в розробці GUI на той момент було рішення від Scaleform: практично всі AAA-проекти використовували його в розробці, і результати виглядали дуже привабливо.

Предрелізний період: перехід на Scaleform

Scaleform пропонував використовувати Flash для розробки GUI. По суті, рішення складалося з трьох частин:

• кастомной реалізації Flash Player, яку можна було вбудувати в ігровий клієнт;
• набору інструментів для експорту SWF в спеціалізований формат;
• бібліотеки компонентів CLIK - набору стандартних UI-компонентів і класів, які давали можливість прискорити розробку.

Восени 2009 року була куплена ліцензія, і почався новий етап розвитку GUI в проекті. На перших порах все виглядало багатообіцяюче: процес розробки Flash був відпрацьований роками, а розробників, які знали і любили цей процес, було дуже багато. Однак виявилося, що ситуація на ринку праці в Білорусі на той момент складалася так, що більшість Flash-розробників вже сиділо на цікавих і «жирних» проектах, і швидко знайти і залучити якісні кадри з боку було складно.

З цієї причини в терміновому порядку вчити Flash почав весь відділ GUI (до цього вони робили php, Java і займалися веб-розробкою). Вчилися і починали роботу на ActionScript 2, так як Scaleform на той момент ще не підтримував ActionScript 3. Ось що виходило на перших порах:

За півроку весь інтерфейс ангара був перероблений на Flash. Як я вже писав, pipeline розробки на Flash - відпрацьований і логічний процес. Дизайнери створюють ескізи, і програмісти втілюють їх в грі.

Реалізація:

У лютому 2010 року почалося закрите бета-тестування проекту з уже оновленим ангаром. А ось бойовий інтерфейс все ще був на Python:

Навесні 2010-го прийшов і його черга переходити на Scaleform. Коли це сталося, ігрове співтовариство розділилося на два табори. Одним все подобалося (або вони просто не помітили великої різниці) - і вони мовчки продовжували бадьоро рубатися в танки. Решта ж почали відкладати гори цегли на адресу «кривавої картоплі», кажучи про те, що нові приціли і елементи інтерфейсу не відповідають сеттінгу, що не вистачає рваного металу, болтів і заклепок, що приціли повинні бути історичності, а не схожими на елементи управління космічним кораблем.

Один з робітників ескізів нового бойового інтерфейсу:

Реалізація бойового інтерфейсу на Scaleform:

Але з часом невдоволення пройшло, так як нові інтерфейси привнесли багато нового в геймплей. Гра стала динамічніше, інтуїтивно зрозуміліше і інформативніше.

Крім цього, використання Scaleform відкрило можливості по кастомізації інтерфейсів. Будь-який школяр, який уміє мінімально працювати з Flash, міг декомпілювати SWF з дистрибутива гри і на свій розсуд змінювати все - від використовуваних зображень і шрифтів, до логіки роботи коду. З'явилися моди, що замінювали приціли на історичність, «ляльку» танка на більш агресивну або, навпаки, минималистичную. Можна було знайти моди для будь-якої частини інтерфейсу в бою. Були моди і для ангара: годинник, калькулятори, багаторівнева карусель і т. Д.

Керівництво Wargaming кілька разів змінювало своє ставлення до модам. Спочатку, оскільки це були поодинокі випадки, їх просто ігнорували. Згодом і збільшенням їх числа і популярності - почали придивлятися і зрозуміли, що деякі з модів можуть дати ігрову перевагу використовує їх гравцеві. Розробку стали вести за принципом «клієнт в руках ворога». Це, звичайно, не означає, що гравці - наші вороги. Нашим завданням стало максимально убезпечити гравців від чужих спроб отримати ігрову перевагу.

Ситуація на ринку модів стала ретельно моніториться. Тепер у разі виявлення небезпечних або змінюють ігровий баланс модів ми оперативно реагуємо і закриваємо можливість їх використання, змінюючи логіку роботи клієнта. Останнім кілька років виготовлення чесних модов підтримується. По суті, це user generated content - гравці роблять ці моди для себе та інших гравців, що підвищує цінність нашого продукту.

Але повернемося до історії. Робота зі Scaleform дуже освіжила GUI і дала поштовх до його розвитку в проекті. Функціонал розростався і ускладнювався за час проходження закритою і відкритої бети і виходу проекту в реліз в серпні 2010. Чи додавалися нові фічі, допрацьовувалися і наверталися вже існуючі. Змінювався дизайн, пробувалися різні підходи до подання інформації в грі і організації взаємодії з гравцем.

Варіанти реалізації фільтра техніки:

Зміни мінікарти:

Постреліз: проблеми зростання і шляхи їх рішень

З ростом кількості коду і Ассет стали виповзати різні косяки.

Маркетинг Scaleform обганяв реальну розробку продукту і, як виявилося, багато із заявлених фич або працювали не так, як хотілося, або сильно били по продуктивності, або взагалі були в зародковому стані. Була виконана величезна робота по поліпшенню продуктивності Scaleform-плеєра, причому як з нашого боку, так і з боку розробників технології.

Що збільшився обсяг коду приводив до цікавого спецефекту. Кожна вьюха (або вікно) лежала в своїй FLA, містила свої Ассет і код і компілювати в окремий SWF-файл. Таких SWF було дуже багато, і на Рантайм вони довантажувати в клієнт для показу потрібного віконця або елемента управління, і, що характерно, порядок завантаження міг змінюватися в залежності від того, що робив користувач в грі.

Проблема полягала в тому, що якщо змінювався код, який використовувався в декількох SWF, і після змін не всі ці SWF збирати заново, то на Рантайм могло статися таке. Першою завантажувалася SWF із застарілим кодом, і в кращому випадку все працювало по старому, а в гіршому - відбувалося падіння клієнта. Зрозуміти, що саме призводить до таких результатів, було важко. Нам доводилося вигадувати інструменти і методики, що дозволяли відстежувати, що саме потрібно пересобрать після змін.

Також існувала проблема з якістю і консистентним коду і використанням різних патернів і стилів програмування. Так вийшло тому, що розробку на Flash в проекті починали люди, які не були професійними Flash-розробниками. Вони вчили Flash «в бою», і у кожного був свій бекграунд (C ++, php, Java). Виходило так, що при роботі в різних частинах проекту потрібно було переключатися з одного підходу на інший.

Ще однією болем була взаємодія Flash з Python. Передавати дані в будь-яку сторону можна було тільки у вигляді примітивних типів, що, звичайно ж, не задовольняло нашим запитам. Шляхів вирішення було два: використовувати JSON або ж розкладати всі складні типи в довгі масиви на одному кінці і збирати з цих масивів об'єкти на іншому.

Перший підхід добре працював, коли об'єкти були маленькими. Але при зростанні розміру об'єктів обсяги результуючих рядків росли, і це позначалося на швидкості виконання коду - вона падала. Другий підхід швидко працював, але був складний для розуміння під час читання коду і вимагав титанічних зусиль при реалізації змін в структурі даних.

До того моменту, коли всі ці проблеми стали сильно гальмувати розробку, Scaleform вже довів підтримку ActionScript 3 до прийнятного рівня. У нас визрівав план перевести інтерфейси ангара на нову версію мови і паралельно провести реструктуризацію проекту і створити свій framework, що дозволяє швидко і по певними правилами додавати нову функціональність в проект.

Роботи з підготовки переходу на ActionScript 3 почалися в кінці 2012 року. Як ми вирішували стоять перед нами проблеми, і які завдання ставили.

проблема: проблеми з різними версіями коду в різних SWF.
Рішення: весь код програми вкомпілівается в один SWF-файл, який завантажується при старті програми.

проблема: комунікація Flash<-> Python.
Рішення: перехід на використання Direct Access API. Цей механізм дозволяє передавати складні об'єкти даних за допомогою автоматичної сериализации / десеріалізациі їх на рівні C ++. Також використання цього підходу збільшує продуктивність за рахунок того, що посилання на Flash-об'єкти можна передавати в Python і проводити маніпуляції над ними в Python безпосередньо, замість пошуку потрібного об'єкту у Flash за повним шляху до нього при кожній необхідності передачі даних.

проблема: стандартизація та уніфікація коду.
Рішення:ми реалізували сервісну інфраструктуру і визначили набори інтерфейсів і базових класів, реалізуючи які нова функціональність додається в проект.

проблема: автоматизація збірки і додавання нового функціоналу в проект.
Рішення: для збірки ми використовуємо Maven. Проект було реструктуровано і розбитий на більш логічні підпроекти і підсистеми. Для автоматизації додавання нового функціоналу ми використовували YAML в якості мови для опису інтерфейсів взаємодії Flash і Python. На базі YAML автоматично при складанні генерується код і створюються необхідні суті - як у Flash, так і в Python. Все, що залишається зробити, це написати код і визначити точку входу для запуску нової функціональності.

Так, в вересня 2013 з виходом версії 8.8 лобі гри було повністю перероблено на ActionScript 3.

Ось і все на сьогодні. Деталі про структуру проекту і плани на майбутнє читайте в наступній статті.

Це, мабуть, одна з найбільших категорій модов для WOT. Якщо ви скачаєте цей мод, то зможете повністю поміняти інтерфейс гри, а також додати величезну кількість корисних функцій. Нижче наведемо основні модифікації, що входять в цю категорію.
- Древо розвитку. Є можливість повністю поміняти стандартне горизонтальне древо на нове - вертикальне, яке в рази компактніше.
- Моди, які змінюють різні об'єкти в вашому ангарі. Кольорові повідомлення, кілька варіантів колірного оформлення інтерфейсу, два ряди бронемашин замість одного, а також абсолютно нове відображення танкової каруселі.
- Маркери атаки. Відзначимо, що стандартний маркер атаки є, але він непомітний, а використавши моди зможете підвищити його помітність в рази.
- Найрізноманітніші моди, які додають збільшений зум. Такий мод допоможе вам оглянути всю карту або ж побачити, куди противник, який стоїть за будівлею, повернув власне знаряддя.
- До того ж, крім згаданих модів, в запропонованій категорії вам вдасться знайти безліч інших модів. Додавайте в інтерфейс World of Tanks корисний функціонал.

Оновлене для патча World of tanks 1.0.1 WOT.

Всім кому набрид стандартний інтерфейс і дуже хочеться його поміняти, слід скористатися модифікацією стильний синій інтерфейс гри для World of Tanks. Після її установки гру ви більше не дізнаєтеся.

Запустивши гру, перед вами з'явиться абсолютно нове завантажувальний вікно. Воно володіє іншим оформленням і колірним рішенням. Особливо багатьом сподобається срібний череп посередині монітора. Але ще більше вас здивує ангар. Поєднання синіх і чорних тонів змінили ангар до невпізнання.

Класичні елементи червоного кольору тепер придбали синій відтінок.

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

Шрифт вкладок має фіолетовим підсвічуванням, яка відмінно поєднується з помаранчевими буквами, що робить їх помітніше.

Ще одне диво вас чекає після появи результатів бою. Всі класи техніки розташовують своїм відтінком:

• ТТ - червоні,
• ЛТ - зелені,
• ПТ - сині,
• СТ - жовті.

Танкісти, які були знищені в бою, відзначаються картинкою череп на кістках.

Якщо вам дійсно приїлася гра і хочеться нових вражень, обов'язково встановіть цю модифікацію. Ваш подарує вам масу позитивних емоцій.