Как нарисовать world of tanks blitz

Обновлено: 05.07.2024

Мы давно знаем, что среди вас немало представителей самых разнообразных профессий от офисных работников до сотрудников МЧС и прочих служб. Кто-то преподает редкие языки, кто-то соприкасается с тяжелой бронетехникой не только на полях виртуальных сражений, но и в реальной жизни, кто-то - занимается творчеством и каждый день поднимает настроение как себе, так и окружающим. Так или иначе, в сообществе WoT Blitz огромное количество невероятно талантливых людей и чем бы вы ни занимались, важно просто любить свое дело, стараться делать мир лучше и вдохновлять других. Наш новый конкурс посвящен мастерам одного из самых творческих ремесел - художникам. Кто, как не они способен менять мир с помощью собственной фантазии?
Да-да, мы хотим предоставить художникам, дизайнерам и иллюстаторам, интересующимся WoT Blitz, возможность заявить о себе на профессиональном уровне, выиграть полезный девайс, а также побороться за секретный приз, о котором главный победитель узнает позже.

Ваша задача — нарисовать комикс с законченным сюжетом, который рассказывает об игровой вселенной World of Tanks Blitz. Из комикса читатель должен узнать ответы на такие вопросы, как:

Почему в одной команде собраны танки разных наций?
Из-за чего они сошлись в одном бою?
Почему в игре встречаются как машины разных эпох, так и выдуманная техника вроде Panzer IV Anko Special или Франкенштанк?
Что лежит в основе вселенной World of Tanks Blitz? Может быть, это способ решения конфликтов в далёком будущем, виртуальная игра инопланетной расы, нашедшей древние следы человечества, или это вообще реальный мир, где танки играют в людей?

Необязательно охватывать все вопросы. Можно сосредоточиться на одном, который наиболее интересен.

1. Общие положения:

1.1. Правила регламентируют порядок проведения конкурса комиксов “Blitz Comics”.
1.2. Организатором конкурса является администрация проекта.
1.3. Конкурс проводится на официальном форуме игры WoT Blitz в подразделе “Официальные конкурсы”, а также официальной группе игры Вконтакте.
1.4. Жюри конкурса оставляет за собой право не рассматривать работы, которые не соответствуют требованиям и правилам конкурса, не вступать в переписку и не объяснять причин отказа определенным участникам.
1.5. Организатор оставляет за собой право принимать решения по всем вопросам, касающимся конкурса, в том числе изменять правила и разрешать спорные ситуации по своему усмотрению.

2. Условия и правила участия в конкурсе:

3 . Требования к оформлению работы:

3.1. Несмотря на то, что в конкурсе может принять участие любой игрок WoT Blitz, он ориентирован, в первую очередь, на профессиональных художников.
3.2. Для создания работы вы можете пользоваться любым профессиональным графическим редактором - ограничений нет.
3.3. Рекомендуемое разрешение облегченного варианта конкурсной работы — не менее 800х600 и не более 1024х768 точек, размер — не более 700 КБ , формат — JPEG, PNG.
3.4. Количество кадров комикса остается на усмотрении автора - ограничений нет .
3.5. Работа должна быть размещена в конкурсной теме. О том, как это сделать, читайте в специальной инструкции. Обязательно использование хостинга из приведенного списка, т.к. с других хостингов работы не будут отображаться на форуме.
3.6. Обязательно необходимо предоставить дополнительные материалы процесса создания вашего комикса, подтверждающие, что именно вы являетесь автором работы (в виде фото, скриншотов или видео, размещенных под спойлером ).
3.7. Обязательно предоставить ваш комикс в оригинальном (максимальном) разрешении (под спойлером или в виде ссылки для скачивания ).

4. Призовой фонд:

Каждый победитель получит памятную медаль «За творческий вклад» — по-настоящему редкое и почётное достижение. Эта медаль встречается реже, чем «Колобанов» и даже «Расейняй» — носите её с гордостью!

Но при всей её крутости медаль — не главный приз. Победителей ждут и другие внушительные награды:

I место

II место

14 дней премиум аккаунта

СУ-100Y.

III место

7 дней премиум аккаунта
Pz.Kpfw. S35 739 (f)

Внимание — секретный приз!

Самый талантливый, умелый и креативный конкурсант получит особую награду. Какую? Одержите победу в конкурсе — тогда и узнаете. Но знайте — эта награда стоит усилий!

Важно:

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

5. Сроки проведения:

Начало приема работ - 10 марта 2016 г., 15:00 МСК.
Окончание приема работ - 17 апреля 2016 г., 23:59 МСК.

6. Критерии оценки:

Оригинальность истории / сюжета.
Мастерство реализации художественного замысла.
Соответствие работы регламенту и тематике конкурса.

Игровое имя участника.
Облегченный вариант вашего комикса с разрешением не более 1024х768 — именно эта фотография будет оцениваться членами жюри.
Комикс в оригинальном (максимальном) разрешении (под спойлером) или в виде ссылки для скачивания.
Снимок/скриншот экрана с процессом создания работы загруженный на фотохостинг из «Белого списка» (не более 2 изображений, спрятанных под спойлер или предоставленных в виде ссылок на фотохостинг из «Белого списка»).

Обсуждаем конкурс в этой теме.

Получение участниками конкурса призов обусловлено соблюдением ими любых и всех соответствующих законов, норм и положений, а также настоящих правил. Участники, а также их родители или опекуны (в случае если участник является несовершеннолетним), самостоятельно и за свой счет несут ответственность за все страховые, налоговые и иные издержки или расходы, не обозначенные в описании призов. Любые налоговые последствия получения приза являются исключительно последствиями участника, получающего такой приз. Настоящим участник уведомлен, что организатор конкурса, при необходимости, сообщает в налоговую инспекцию по месту проживания участника, получившего приз, данные об участнике и о полученной им материальной выгоде в порядке и сроки, установленные законодательством.

В: Что и как нужно сделать вообще?
О: Нужно НАРИСОВАТЬ комикс о вселенной WoT Blitz. Комикс - это не картинка-мем и не шаблон с репликами. Это графическая история в духе супер-героев, расказанная вами. Для ее создания подойдет, к примеру, графический планшет. Если вы не умеете рисовать на компьютере, то в крайнем случае можно создать работу от руки.

В: Конкурс только для профессионалов?! Это дискриминация!
О: Номинально в конкурсе может принять участие любой игрок, однако, профессиональные художники, дизайнеры и иллюстраторы будут иметь куда больший шанс на победу.

В: Что за серкетный главный приз будет разыгрывать жюри и от чего зависит его розыгрыш?
О: А вот и не скажем
Розыгрыш секретного приза будет зависеть от общего уровня и качества работ. С каждым автором, чью работу жюри сочтет интересной и оригинальной, мы свяжемся в индивидуальном порядке.

В: Почему девайс указан через "или"? Будет разыгрываться два девайса?
О: Разыгрывается один девайс среди участников обеих площадок (форум и ВК). Таким образом, мы выберем одного главного победителя и он получит право выбрать устройство Ipad Air 2 или Ipad Pro по своему усмотрению.

В: Медаль "За творческий вклад" вручается только победителям, занявшим призовые места, а простые участники, что? Останутся без медали?!
О: Мы постараемся наградить медалью, как можно больше конкурсантов, приславших действительно интересные и достойные работы.

B: Можно выложить одну и ту же работу на форуме и в ВК?
О: В ы можете выложить две разные работы: одну - на форум и одну - в группу игры. Однако дублировать одну и ту же работу на одной площадке нельзя. В этом случае, работа, выложенная позже, будет удалена.

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

В: Можно ли использовать 3d редакторы?
О: Если в конце-концов, у вас получится достойная работа с качественной пост-обработкой - почему нет?

В: Можно ли нарисовать комикс от руки?
О: Можно, но предпочтительнее воспользоваться графическим редактором. Если вы рисуете от руки, пожалуйста, отсканируйте свою работу, чтобы могли увидеть ее в высоком качестве. И учтите, пожалуйста, что, рисуя от руки, крайне желательно владеть и графическим редактором.

В: Сколько кадров должно быть в комиксе?
О: Ограничений нет. Ровно столько, чтобы вы смогли рассказать красочную и интересную историю.

В: Порядок чтения комикса слева-направо или справа-налево?
О: Порядок чтения слева-направо.

В: О чем, вообще, должен быть комикс? О танках что ли?
О: Мы предлагаем вам пофантазировать на тему игровой вселенной WoT Blitz. Ваш комикс должен объяснять, почему она устроена именно таким образом. К примеру, вы можете рассказать о машине времени, собравшей танки разных эпох и мастей на одном поле брани. Одновременно с этим, вы можете рассказать историю из собственной альтернативной танковой вселенной - фантастической или не очень
Все, что нам нужно - это качественная прорисовка и оригинальный ход ваших мыслей.

В: Хорошо. А танки обязательно из игры должны быть или можно любые?
О: Да, танки желательно использовать те, которые есть в игре.

В: Комикс должен быть обязательно цветным? Манга-стайл приветствуется?
О: Желательно делать изображения цветными и яркими. Стиль может быть любым.

В: А танки могут быть одушевленными?
О: Могут.

В: Членов экипажа можно показать в работе?
О: Можно.

В: Сейчас часто линейную графическую часть комикса (обводку) рисуют на бумаге тушью, после этого обрабатывают и накладывают цвет в графических редакторах.
Может ли работа, выполненная таким образом, участвовать в конкурсе?
О: Да, может.

В: Как доказать подлинность рисунков? Фотографироваться в процессе работы или можно когда рисунок готов? Рисую от руки.
О: Лучше запечатлеть процесс создания работы в паре фото.

В: А вообще, обязательно ли прикладывать файлы, доказывающее мое авторство?
О: Да, обязательно. Это могут быть как фото, так и видео.

В: А можно создать комикс вдвоём?
О: Нет, в противном случае и главный приз - айпад будет распилен на две равные половинки.

Что дальше

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

Подвеска

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

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

Так что мы решили реализовать модификацию геометрии гусениц программно.

Вот как все работает.

По боковой проекции оригинальной гусеницы мы строим контур — замкнутый многоугольник.

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

3. Из нижней части оригинальной гусеницы берем и программно вырезаем кусок геометрии — он будет использоваться для заполнения звеньев полученной цепи.

4. Сгенерированная гусеница рендерится за один вызов отрисовки. В этом вызове вырезанная геометрия повторяется множество раз благодаря инстансингу. Трансформация для каждого инстанса вычисляется в вершинном шейдере на основе позиций точек переданной туда цепи.

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

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

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

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

Такой подход позволяет нам настраивать динамическую подвеску на одном танке силами одного художника примерно за 20 минут. К обновлению 8.0, о котором идет речь, мы настроили 456 танков.

Как это работает в больших Танках

У старшего брата за динамическую подвеску и красивый изгиб ~~гитары~~ гусеницы отвечает технология Soft skinning. Она отличная, но куда более требовательная к железу. Если бы мы использовали ее на мобилках, играть в Blitz было бы сложно. Зато тепло.

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

Поэтому правки постоянно вносили и в генерацию самих гусениц, и в симуляцию физики этих гусениц.

Вступить в беседу

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

От Funduck773
Создано 1 августа

От XVIICentury
Создано 26 августа

От Leonel Shinto
Создано 20 августа

От DaNiEL
Создано 22 декабря, 2020

От Leonel Shinto
Создано 15 августа

Статистика форума

Обнаружен AdBlock!

Наш сайт и форум не может работать без рекламы, так как нам будет сложно

оплатить работу хостинга и домена.

Пожалуйста, отключите AdBlock прежде чем пользоваться нашим форумом.

PBR — physically based rendering

Кроме подвески, в игре появился новый физически достоверный рендеринг материалов и освещения техники. Он использует принципы распространения света в реальном мире.

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

Кроме этого, к танкам применяется глобальная схема освещения, уникальная для каждой карты.

Он же отвечает за внешние изменения танка в зависимости от того, по чему он едет — можно заметно испачкаться на ряде карт, затем заехать в воду: грязь смоется, и ваша боевая машина какое-то время будет чистой и блестящей, пока не высохнет.

Все эти графические настройки можно менять. Конечно, не так гибко, как в больших Танках, но достаточно для того, чтобы комфортно поиграть в Blitz и на бюджетном смартфоне. У разных настроек разный «вес» — например, описанный выше PBR не так уж и сильно влияет на производительность. А вот высокое качество теней — это уже весомо.

iBlitz Forum

Внимание! Данный дизайн форума iBlitz находится в тестовом режиме и может содержать ошибки.

как создавать шкурки (скины ) на танки после обновления 6.5

Создание World of Tanks Blitz на базе собственного движка DAVA

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

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

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

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

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

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

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

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

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

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

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

Начало работ

Началось все с доказательства возможности отрисовать ландшафт на мобильных устройствах: тогда это были iPhone 4 и iPad 1.

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

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

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

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

Вся отрисовка сцен была основана на простой концепции Scene Graph.

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

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

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

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

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

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

Для начала мы решили полечить проблемы с производительностью и сделать это быстро.

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

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

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

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

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

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

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

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

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

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

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

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

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

Код обхода этой иерархии иерархически выглядит так:

В данной иерархии C++ наследования мы имеем три различных независимых потока данных:

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

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

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

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

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

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

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

Когда я понял это, в процессе дальнейшего изучения различной информации наткнулся на Artemis Framework и увидел хорошую реализацию этого подхода.
Исходники тут, если предыдущий линк не работает: Artemis Original Java Source Code

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

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

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

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

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

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

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

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

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

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

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

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

Третим классом является SceneSystem:

Функции RegisterEntity, UnregisterEntity вызываются для всех систем в сцене тогда, когда мы добавляем или удаляем Entity из сцены.

Функции RegisterComponent, UnregisterComponent вызываются для всех систем в сцене, тогда, когда мы добавляем или удаляем Component в 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 — система расчета растительности над ландшафтом.

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

Системы можно классифицировать по тому как они обрабатывают объекты:

Требуется обработка всех объектов, которые находятся в системе:
- Физика
- Коллизии
- Система трансформаций
- Система actions (действий)
- Система обработки звуков
- Система обработки частиц
- Static Occlusion System
- Мы сильно повысили FPS, так как с компонентным подходом вещи стали более независимы и мы смогли их по отдельности развязать и оптимизировать.
- Архитектура стала более простой и понятной.
- Стало легко расширять движок, почти не ломая соседние системы.
- Стало меньше багов из серии «сделав что-то c лодами, сломали свитчи», и наоборот
- Появилась возможность это все распараллеливать на несколько ядер.
- На текущий момент, уже работаем над тем, чтобы все системы запускать на всех доступных ядрах.
Соответственно, если есть желание можете заходить и смотреть на нашу имплементацию в деталях.

Учитывайте тот факт, что все писалось в реальном проекте, и, конечно, это не академическая реализация.

World of Tanks Blitz — как мы сделали для танков динамическую подвеску

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

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

В этом посте рендер-разработчики студии мобильной разработки Wargaming MS-1 Рамиль Кудашев и Александр Бабей расскажут о том, что нового (и красивого) появилось в летнем релизе World of Tanks Blitz.

Осторожно, внутри тяжелые гифки.

Мы хорошо помним, как живо было встречено введение реалистичной физики в большом WoT. Помните, до этого момента танки ездили будто по рельсам, без отрыва от земли. А при попытке разбежаться и прыгнуть со скалы танк мгновенно останавливался на краю. Это был не инстинкт самосохранения поседевшего экипажа — просто тогда не было физики. Зато сейчас она есть, и при желании куда-то заехать с разгону или откуда-то (и на кого-то) прыгнуть — можно.

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

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