Когда будет новый движок в танках. Протестируй новый движок. Что известно на данный момент

    World of Tanks enCore - демонстрационная программа графического движка Core, на который скоро перейдёт танковый онлайн-экшен World of Tanks. Запустив на своём компьютере World of Tanks enCore, можно получить представление о том, насколько производительной на нем будет World of Tanks с движком Core.

    Как и движок Core, World of Tanks enCore полностью разработана внутри Wargaming - командой World of Tanks PC.

    Core сильно улучшит внешний вид World of Tanks. После перевода игры на Core практически все содержимое карт - ландшафт, вода, растительность, освещение, тени, облака, здания и другие объекты - будет заменено на новое, разработанное с нуля.

    Программа предлагает на выбор три пресета качества: «Минимальное», «Среднее», «Ультра». Это графические пресеты World of Tanks на новом движке Core, поэтому их названия (и количество) отличаются от привычных игрокам по текущему клиенту World of Tanks «Минимум», «Низко», «Средне», «Высоко» и «Максимум». В некоторых случаях World of Tanks enCore может порекомендовать вам более низкий уровень графических настроек, чем тот, которым вы сейчас пользуетесь в World of Tanks. (Например, вы можете сейчас играть на уровне «Максимум» и получить в enCore «Среднее», а не «Ультра».)

    Пресеты качества - «Минимальное», «Среднее» и «Ультра» - различаются разрешением экрана и качеством текстур, освещения, теней, ландшафта, воды, частиц и пр. Во всех пресетах можно изменить разрешение, а пресеты «Средне» и «Ультра» можно кастомизировать по такому параметру, как сглаживание. Рядом со значениями параметров, которые были изменены, будет отображаться специальная иконка в виде шестерёнки. Сравнивая результат, показанный вашим компьютером в World of Tanks enCore, с чужими, следует учитывать пресет, а также установленные разрешение и сглаживание.

    Нет, ограничение по кастомизации пресетов касается только enCore. World of Tanks даёт максимально широкий выбор графических настроек сейчас и продолжит предлагать его в дальнейшем.

    Скорее всего, случилось падение либо нашего enCore, либо вашего видеодрайвера. Пожалуйста, обратитесь в службу поддержки (https://ru.wargaming.net/support/).

    В первую очередь, не паниковать. Сначала скачайте enCore и попробуйте все настройки. Мы уделяем большое внимание оптимизации Core - особенно для машин низкой и средней производительности.

    Вы можете ориентироваться на этот результат, но полного соответствия не будет.

    Так как программа World of Tanks enCore не является бенчмарком, она оценивает производительность компьютера в баллах. Баллы адекватно отражают мощность компьютера и дают возможность сравнивать свой результат с чужими. Если ваш компьютер набирает 10 000 баллов - это превосходный результат, означающий, что на выбранном пресете не будет «тормозов» и резких падений FPS. Результат от 8001 и выше («золото») является отличным, в 3001–8000 баллов («серебро») - хорошим, до 3000 баллов («бронза») - приемлемым.

    Если вы запускаете World of Tanks enCore на ноутбуке с дискретной и интегрированной видеокартами, программа будет автоматически запускаться на дискретной видеокарте. Если этого не произойдёт, укажите в настройках драйвера видеокарты, чтобы enCore запускалась с использованием дискретной видеокарты. Если вы используете решение с несколькими видеокартами (nVIDIA SLI, AMD CrossFire или аналог), программа может работать некорректно. World of Tanks enCore оптимизирована под использование одной видеокарты.

    World of Tanks enCore поддерживает Windows XP SP3/Vista/7/8/10.

    Такие же, как и у основного клиента World of Tanks. Вы можете посмотреть их на официальном сайте игры (https://worldoftanks.ru/ru/content/docs/download/).

    Некоторые антивирусы могут блокировать работу World of Tanks enCore.

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

    Об этом мы сообщим дополнительно. Само появление World of Tanks enCore - признак того, что перевод игры на Core произойдёт скоро.

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. После окончания теста "Энкор" выведет итоговый результат оценки вашего компьютера в баллах. Чем больше баллов набрал ваш компьютер в результате теста, тем лучше он подходит для

Со 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)? Чем он занимается? Он работает над своим проектом лунной базы?)
- Серб работает у нас. Он НЕ работает над проектом лунной базы. Он сейчас трудится над другими проектами Варгейминг.

За этот год мы проделали серьёзную работу по настройке балансировщика и боевой техники, особенно САУ. Конечно, останавливаться на достигнутом не планируем, поэтому основная задача в 2018-м — сделать максимально реалистичными графику и звук, а саму игру — ещё более разнообразной благодаря новой технике, боевым возможностям и, конечно, увлекательным игровым событиям.

Что касается переработки графического «движка» игры, скажем лишь, что таких танков вы ещё не видели.

Новый игровой движок

Одной из самых важных новостей на WG Fest в этом году стал анонс версии 1.0, до выхода которой осталось меньше трёх месяцев! Релиз нового графического движка и более 25 ультрареалистичных карт на основных серверах запланирован на март.

Над этим впечатляющим изменением мы работали больше четырёх лет. Всё началось с желания перевести графику на новый уровень в соответствии с современными стандартами. Вооружившись вашими отзывами и новыми технологиями, мы смогли сделать графику современнее — но при этом мы также оптимизировали производительность, чтобы вы смогли продолжить играть в World of Tanks на любых компьютерах.

Простые изменения оригинального движка не позволили бы нам этого добиться: технологии развиваются слишком быстро, и движок BigWorld за ними просто не поспевает. Нам требовалось решение, которое, с одной стороны, поддерживало бы современные технологии и, с другой, обеспечивало бы достаточно пространства для развития графики. Кроме того, эта технология также должна была идеально подходить для World of Tanks .

Поняв, что какой бы то ни было графический движок не удовлетворит всем трём этим требованиям, мы решили перенести разработку игры внутрь компании — чтобы создать решение, которое идеально бы подходило для World of Tanks . Технологии, которая получилась в итоге, мы дали название Core (англ. — ядро), поскольку она в прямом смысле — ядро всего, что вы видите в игре.

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

Более 25 переработанных карт

Текстуры ландшафта, система отображения воды, небо, система освещения, тени — мы переработали каждый элемент карты, изменили его, чтобы поля сражений стали ещё реалистичнее и красивее. У каждой карты теперь будет своя уникальная атмосфера, а впечатления от боёв станут ещё ярче — благодаря множеству новых и улучшенных технологий и эффектов.


  • Необъятные просторы: километр за километром мы создавали пространство за пределами карты, чтобы оно выглядело как в реальном мире.
  • Реалистичный ландшафт: новый графический движок позволяет смешивать 16 текстур, чтобы ландшафт выглядел по-настоящему объёмным и невероятно детализированным до малейшей травинки.
  • Намокание и вода: техника и любые другие объекты окружающего мира могут намокать, как и в реальном мире. Когда машина переезжает реку, она толкает перед собой воду, а выстрелы будут создавать волны на поверхности воды.
  • Разнообразная флора: растительность будет соответствовать времени года, а деревья более не будут выглядеть плоскими. Мы добавили им объёмности, а ещё создали около сотни уникальных деревьев и несколько вариантов для каждого экотипа, чтобы повысить разнообразие.
  • Фотореалистичное небо: мы добавили движущиеся облака и создали фотореалистичное небо для каждой карты, чтобы ещё больше подчеркнуть уникальную атмосферу на каждой из них.
  • Новая система освещения: система освещения включает реалистичные модели затенения/освещения, окружающую среду, улучшенные динамические тени и технологию глобального освещения, которая точно следует законам физики света, внося гармонию в картинку.
  • Разрушаемые объекты : переработанные карты получат долгожданную технологию Havok ® Destruction . Теперь в бою вы сможете красиво крушить всё, что окажется у вас на пути.
  • Пост-эффекты: свечение, «God Rays », хроматические аберрации и эффекты отражения улучшают качество изображения и чёткость деталей.

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

Одновременно мы воспользовались возможностью и исправили известные проблемы на картах «Рыбацкая бухта», «Руинберг», «Промзона», «Эрленберг», «Степи» и «Харьков». Например, «Рыбацкая бухта» получила более сбалансированную линию противостояния. Это даёт каждой из команд равные шансы на занятие ключевых позиций. Центральная зона на карте «Эрленберг» значительно изменилась: она стала более понятной, с заметной низиной, более густыми лесами и меньшим количеством ландшафтных зон, которые имеют малое тактическое значение.

Переработанные звуки

На графике улучшения игры не заканчиваются. Вместе с более чем 40 композиторами и музыкантами со всего мира мы записали более 15 терабайт звуковых данных, чтобы усилить ваши впечатления от виртуальных сражений в World of Tanks .

Начиная с обновления 1.0, музыка будет соответствовать сеттингу карты, создавая уникальную атмосферу на каждой из них. Традиционные казахские музыкальные инструменты будут звучать, когда вы будете двигаться по карте «Затерянный город». Арабские мотивы будут слышны на картах «Песчаная река», «Аэродром» и «Эль-Халлуф». На карте «Перевал» вы узнаете грузинские мелодии.

Вы прочувствуете характерную атмосферу карты ещё до начала уникальной темы загрузочного экрана. А затем звуковое сопровождение будет изменяться в зависимости от успеха вашей команды в бою.

Оптимизация

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

  • Так, чтобы сделать пейзажи реалистичнее без дополнительной нагрузки на производительность, мы добавили специальную процедурную виртуальную текстуру.
  • Мы использовали технологию Adaptive Shadow Maps , которая рассчитывает тени от статических объектов и сохраняет их в специальной многократно используемой текстуре теней, снижая нагрузку на видеокарту и процессор.
  • Чтобы снизить общий объём памяти для графики, мы переработали графические подсистемы с использованием потоковой технологии.
  • Ресурсоёмкий процесс генерирования отражений мы заменили алгоритмом Screen Space Reflection , который значительно снижает нагрузку на видеокарту.
  • Мы создали частицы различного разрешения, чтобы сгладить просадки частоты кадров при одновременном отображении в кадре многочисленных частиц (например, взрывов и дыма).

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

Однако всё это в прошлом. После нескольких этапов оптимизации, нескольких внутренних тестов и тестирования в «Песочнице» (ещё раз спасибо вам!), мы приближаемся к финишной прямой. 25 карт уже переработаны и почти готовы к запуску! Несколько внутренних и открытых тестирований — и вы увидите их в игре.

World of Tanks enCore

Наша цель — настроить карты и звуковую систему — не должна мешать вам изучать изменённую игру. Мы хотим, чтобы вы лично всё оценили и поделились мнением об изменениях. Поэтому мы создали специальную демо-программу World of Tanks encore , благодаря которой вы получите ранний доступ к улучшенной графике и звукам. Программа позволит вам запускать предварительно записанные бои, чтобы просматривать переработанные карты. А пока будете любоваться красотами, World of Tanks enCore протестирует ваш компьютер и после проинформирует о производительности переработанной игры на нём.

Заходите сюда, чтобы проверить, готова ли ваша система к переработанной игре World of Tanks :

Предварительное информирование о настройках

Если вы играете на средних настройках, вам, возможно, придётся переключиться на низкие или минимальные на новом графическом движке. Это не повлияет на частоту кадров или качество картинки: они останутся такими же или даже улучшатся.

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

Изменения дерева исследований СССР

Внимание! Ориентируясь на ваши отзывы и предложения, полученные после анонса новой ветки, мы изменили стартовый танк для прокачки ветки Объекта 705А. По нашим предварительным планам переход на ветку будет происходить с ИС, а не с КВ-13. Это станет более логичным и удобным решением для всех, и на общий тест обновления ветка пойдёт именно в таком формате.

Вас ждёт новая ветка тяжёлых танков СССР, а также ребаланс ПТ-САУ и СТ этой нации.

Мы прислушались к вашим отзывам с супертеста и переделаем ветку «Объекта 263» под штурмовые ПТ-САУ. Подвижные и рикошетные, эти машины будут предназначены для боя на средних и коротких дистанциях. Это позволит им играть от бронирования, использовать свою мобильность для быстрых атак и уничтожения противника благодаря орудиям с высоким разовым уроном.

Хотя работа ещё не завершена, сообщаем: вам стоит ожидать «грандиозных возвращений» и серьёзных перестановок на IX-X уровнях:

Новые режимы

Мы продолжим увеличивать число доступных игровых режимов. Переработанные ранговые бои и режим «Линия фронта» станут доступны в следующем году. Пока рано детально говорить о «Линии фронта», однако мы уже кое-что можем рассказать о следующем сезоне ранговых боёв.

Чтобы обеспечить здоровую конкуренцию в стартовом сезоне, мы изменим некоторые ключевые механики режима:

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

Новые игровые нации

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

Новые способы получать и тратить боны

Мы помним о своём обещании добавлять новые способы зарабатывать и тратить боны. Сейчас вы можете получать их за эпические медали и достижения категории «Герой битвы», заработанные на технике IV -X уровней в случайных боях, а также на машинах X уровня в генеральном сражении. Участвуя в событиях на Глобальной карте, вы также будете получать боны и сможете обменять их на танк. И на этом мы не планируем останавливаться: мы рассматриваем возможность изменения внешнего вида и покупки техники за боны, а также собираемся добавить больше способов получения этой игровой валюты в 2018 году.

Работа с кастомизацией

Обновление 9.21 заложило фундамент для более сложной системы изменения внешнего вида, и её развитие — один из наших приоритетов в 2018 году. Мы сосредоточимся на трёх моментах: добавлении стилей, доступности новых механик на VI -IX уровнях и разработке 3D -элементов внешнего вида.

Игровые события

Сейчас мы работаем над множеством активностей, которые разнообразят танковые бои в следующем году: от атмосферных событий, подобных «Вторжению Левиафана», до ивентов с более широким списком наград, в том числе бон, элементов внешнего вида и техники. Кроме того, следующим летом мы вернём футбольный режим. Так что начинайте шнуровать бутсы уже сейчас!

Спасибо за то, что с нами!

Эта история началась более трех лет назад. Наша небольшая компания DAVA стала частью Wargaming, и мы начали обдумывать, какие проекты делать дальше. Чтобы напомнить, каким был мобайл три года назад, скажу, что тогда не было ни Clash Of Clans, ни Puzzle & Dragons, ни многих очень известных сегодня проектов. Mid-core тогда только-только начинался. Рынок был в разы меньше сегодняшнего.

Изначально всем казалось, что очень хорошей идеей будет сделать несколько мелких игр, которые бы привлекали новых пользователей в большие «танки». После ряда экспериментов оказалось, что это не работает. Несмотря на отличные конверсии в мобильных приложениях, переход от мобильного телефона к 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.
Класс 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 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 подходе являются ключевым элементом программы. Логика - лишь механизмы обработки данных.

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

В какой-то момент стало понятно, что надо идти в сторону 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 = 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 - система расчета растительности над ландшафтом.
Самый главный результат, которого мы добились, - высокая декомпозиция кода, отвечающего за разнородные вещи. Сейчас в функции TransformSystem::Process четко локализирован весь код, который касается трансформаций. Он очень прост. Его легко разложить на несколько ядер. И самое главное, сложно сломать что-то в другой системе, сделав логическое изменение в системе трансформаций.

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

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

  • Требуется обработка всех объектов, которые находятся в системе:
    • Физика
    • Коллизии
  • Требуется обработка только помеченных объектов:
    • Система трансформаций
    • Система actions (действий)
    • Система обработки звуков
    • Система обработки частиц
  • Работа со своей специально оптимизированной структурой данных:
    • Static Occlusion System
При таком подходе кроме того, что очень легко обрабатывать объекты в несколько ядер, очень легко можно делать то, что в обычной полиморфизм-парадигме делать достаточно сложно. Например, вы можете легко взять и обрабатывать не все lod-переключения за кадр. Если лод-объектов ОЧЕНЬ много в большом открытом мире, вы можете сделать так, чтобы каждый кадр обрабатывалась например треть объектов. При этом это не влияет на другие системы.

Итог

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

Читайте также