Канал двс world of tanks blitz
Канал двс world of tanks blitz
Вот Блиц Двс
Вот блиц двс
Блогер на тематику игры World of Tanks Blitz — D_W_S (двигатель внутреннего сгорания), в миру Стас. И часто его хейтят. Но заслуженно ли?
И была великое противостояние…
Во-первых, была у них, у вододелов, своя личная история. Например, с Serviak. Была история с No Mercy. Кто-то что-то там сказал, кто-то что-то там сделал. Одно зацепилось за другое и пошло поехало. Кому интересно — в интернете можно найти про это подробнее. Как по мне — это чисто личные взаимоотношения.
В это личное подключались фанаты и пошло поехало. Сверху подъехали те, кто захотел похайпить на этом. В общем, все как обычно.
Хотя, если совсем честно говорить — у многих топовых блогеров по Блицу есть свои грешки. Но это уже другая тема.
D_W_S на тяжелом танке на горе
Это мем. Стасу приписывают «склонность» стоять на тяжелом танке на возвышенностях. Так это или преувеличение — также отдельная тема.
Плохо ли стоять на тяжелом танке на горе? Казалось бы ответ очевиден — да, плохо. Но на это можно посмотреть под другим углом:
Цель в игре — приносить пользу для команды. Чем больше пользы ты приносишь, тем больше вероятность победить. И тяжелые танки должны либо продавливать направления, либо держать раш противника.
Но можешь ли ты принести пользу, заехав на тяжелом танке на горку? Вполне. Если, например, с это точки можешь сделать хороший выстрел.
Сложность в том, что такое действие требует четкого понимания — зачем ты забираешься на эту горку. Какую пользу ты можешь принести команде. Что делать в следующий момент.
Большинство «не очень опытных» игроков в лучшем случае знают, как на горку заехать. А зачем и что делать позже — понятия не имеют.
Да, D_W_S иногда делает то, что считается «не принятым». То есть не совсем стандартным. Но если кто смотрит стримы топовых игроков, то там также полно «нестандартных» тактик.
Подписывайтесь на наш канал
Рекомендуем следующие статьи:
Навигация по каналу — карта статей
Поделись статьей в соц сетях и мнением в
Вот блиц двс
На YouTube множество каналов, посвященных мобильным танкам. В этой подборке будут авторы, которые лучше всего умеют играть в танки и показывать результат.
В подборку не попали многие, в том числе самые крупные стримеры. По моему мнению, эти ребята хорошо умеют развлекать, но не обучать. В этом топе главное – скилл.
5-е место. BepTyLLIka, 29k подписчиков
Андрей знает свое дело – 3000 среднего урона на десятках. Вертушка нагибает размеренно и спокойно, а еще он в доску свой парень.
4-е место. 4ekavo_81, 6k подписчиков
Вадим – обладатель голоса инструктора по спецподготовке морского десанта. Своим басом он может ломать кирпичи, которые откладывают его противники на поле боя. Вот уж кого можно звать батей без тени сомнения.
3-е место. Perfect_M1nd, 30k подписчиков
Чемпион мира 2016. Пожалуй, самый эксцентричный персонаж рейтинга. 3500 среднего урона на топах. Если вы не видели, что Алексей творит на Leopard 1, то вам срочно надо это посмотреть. И вишенка на торте – на его канале бывают стримы турниров с внутренними переговорами команды. Там есть, чему поучиться даже турнирным игрокам.
2-е место. _I_S_H_O_D_, 3k подписчиков
Алан – чемпион мира 2016. Все просто: безукоризненная стрельба, правильные тактические решения и непоколебимое спокойствие. У этого парня точно есть, что подсмотреть. Я бы поставил Алана на первое место, но он стримит с ПК (хотя отлично играет на сенсорном управлении).
1-е место. _n0_skill_just_luck_, 4k подписчиков
Как сам Артур говорит о своем творчестве: «Это дзен-нагиб». Топ-1 в рейтинговых боях и единственный, кому покорилась планка в 9000 рейтинга – этим все сказано. Железное правило Артика – не бомбить. У него можно научиться не только игре, но и тому, как сберечь свои нервные клетки.
Пишите свой топ вВозможно, я кого-то забыл или пропустил.
Вот блиц двс
И снова всем здравствуйте.
Я все никак не решусь на покупку СТ-1 и поэтому пока выкачал и обкатал ИС-3. Ну и пока не жалею об этом. После прокачки экипажа и вывода танка в топ, он стал явным лидером среди любимых мною танков на данный момент.
Ну и конечно бока и задняя часть башни тоже стали крепче — по 110 мм. со всех сторон. Что дает безумное количество рикошетов и непробитий даже в ближнем бою. Нет не так, ОСОБЕННО в ближнем бою.
Так как корпус танка увы не особенно защищен для 8 уровня, то подставлять его категорически не следует. Можно конечно отыгрывать ромбом от укрытия подставляя бок под острым углом, но тут важно не переборщить при выезде для выстрела, так как открывается тот самый щучий нос ИСа, который должен защищать его вроде, а на деле это срабатывает крайне редко.
Вот например скрин как его видит в прицел Tiger II:
Заметьте что НЛД ИСа под таким углом тоже становится красным, а вот ВЛД как я не крутился так и не покраснел.
Но посмотрите на башню. Она вся непробиваема, остаются лишь небольшие серые участки сверху в которые противник сможет пробить вас только если повезет, ну или если вы будете стоять как вкопанный.
Скорость у машины также отменная, топовый двигатель выдает 31 км/ч. средней скорости, с тяговооруженностью 16.7 лошадей на тонну веса. Динамика у танка не плохая, но накатав боев 30 я понял, что мне ее немного не хватает, особенно когда начало кидать к 9 уровням и нужны были более быстрые маневры. И в снаряжении я пожертвовал ремкомплектом, и установил вместо него форсаж.
Ну а после прокачки ствола 9 уровня, я переключился на орудийный досылатель, что бы ускорить перезарядку.
Обратите внимание: Обзор ветки Т57 heavy через т49 в WOT blitz (часть 2).
Вот тот же Tiger II в прицеле ИС-3:
Он блин весь красный. И приходится заряжать голду. На этом советую не экономить, многих ТТ 8 уровня сложно пробить в лоб.
Урон остается таким же высоким — 400 едениц в среднем. А сведение довольно долгое — 6.3 секунды с амуницией. Но сводиться приходится почти полностью даже при игре на средних дистанциях, так как разброс у ствола высокий — 0.362 на 100 метров.
Ну а в целом танк понравился своей подвижностью и высоким разовым уроном. Иногда можно поехать с СТ и помочь им (скорость позволяет), а затем заехать в тыл к противнику. Но чаще, вначале идет перестрелка с ТТ, которая переходит в крайне ближний бой. И вот тут при аккуратной игре вас могут взять только количеством. А с поддержкой вы легко возьмете фланг. Но повторюсь, с танками уровнем выше все становится гораздо сложнее, и играть в лоб уже нельзя. Лучше использовать динамику танка и совершать маневры заходя с боков или объезжая сзади.
Напоследок мой выбор оборудования:
На этом прощаюсь. Пишите ваши комменты на статью, ставьте лайки если был полезен. Всем пока.
Ну и результативных блайндов вам.
Больше интересных статей здесь: История.
Источник статьи: WoT blitz. Дедушка «ИС-3». Что он может и как на нем играть? Давайте разбираться!.
Вот блиц двс
WoT Blitz — это мобильный танковый шутер, в котором игроки сражаются в формате 7 на 7.
Матчмейкер, или балансировщик это механизм, который на основе очереди игроков, желающих попасть в бой, формирует состав команд.
У танков есть следующие важные для матчмейкинга параметры:
Самая простая реализация матчмейкера — закидывание игроков в команды случайным образом. Но в данном случае у игроков на низких уровнях не будет никаких шансов нанести хоть какой-то урон, и играть станет неинтересно.
Требования
Список требований к балансировщику был сформирован на основе фидбека от игрового сообщества и периодически обновляется по сей день.
На момент написания статьи для обычных боёв список состоял из следующих пунктов:
Список требований к балансировщику
Разработать матчмейкер, особенно с учётом такого количества ограничений, — очень интересная задача. И подходов к её решению может быть довольно много.
Балансировщик формирующий пары игроков
Изначально в мобильных танках использовался балансировщик, доставшийся ему от большого брата — танков десктопных. В целом он работал довольно хорошо, но у него было несколько проблем: во-первых, он не давал чётких гарантий по удовлетворению поставленных требований; во-вторых, добавить новые требования было довольно сложно.
Поэтому был написан другой балансировщик, который работал по следующему алгоритму:
Получившийся балансировщик работал быстрее прошлой версии в 5-10 раз и изначально собирал команды, которые соответствовали всем имеющимся на тот момент требованиям. Новые правила добавлялись путём написания дополнительных проходов перебалансировки.
В начале всё работало хорошо. Но со временем, чем больше правил добавлялось, тем сложнее было написать перебалансировку. Новые перебалансировки должны были в результате своей работы не поломать работу предыдущих. Стало понятно, что это путь в никуда.
Баг в матчмейкере — собралась команда 9 на 9
Балансировщик на основе имитации отжига
В конечном варианте мы остановились на балансировщике, который работает по следующему алгоритму. Все игроки, которые нажимают кнопку «В бой», попадают в общую очередь. Балансировщик в бесконечном цикле делает следующее:
Для формирования команд из списка подходящих игроков используется метод имитации отжига. Подробнее про сам метод можно почитать тут.
Поиск глобального максимума методом имитации отжига
В контексте применения к формированию команд алгоритм следующий:
Основное преимущество данного подхода: для добавления новых требований достаточно модифицировать оценочную функцию. Нет необходимости писать код, который будет описывать, как именно получить то, что мы хотим. Достаточно добавить правило, которое смотрит на сформированную команду и говорит, хорошо ли она сбалансирована или нет.
Хороший пример добавления таких правил — рейтинговые бои. В рейтинговых боях в матчмейкере появилось сразу несколько новых правил:
Пример профиля игрока из бриллиантовой лиги
Первое правило реализовано путём модификации оценочной функции: был добавлен штраф за превышение максимально допустимой разницы в рейтинге. Второе правило реализовано путём изменения функции, которая вытаскивает подходящих игроков из очереди.
Недостаток данного подхода — медленная скорость работы. По сравнению с предыдущим вариантом, текущий стал работать приблизительно в 10 раз медленней, даже несмотря на ряд оптимизаций. Кстати, про оптимизации. Большая часть сервера (кроме сети и физики) для игры написана на Python. Балансировщик был переписан на C++ и распараллелен на много потоков. Из Python в плюсовый код прилетает запрос на формирования команды. Далее каждый из потоков независимо стартует метод отжига. Как только какой-то поток находит решение, остальные потоки останавливают процесс поиска, и найденное решение возвращается в Python.
Время ожидания и размер очереди на RU сервере (5 секунд в обычных боях и 10 в рейтинговых)
По мере роста онлайна росла и нагрузка на балансировщик. Этой осенью, когда балансировщик перестал справляться. В качестве временной меры мы отключили часть правил, это позволило уменьшить нагрузку. Чтобы избежать подобных проблем в будущем мы сделали матчмейкер распределённым.
Рейтинговая система
Лучшие игроки в бриллиантовой лиге, 21 апреля 2019
Во многих ММО играх, кроме случайных боёв, существуют также и рейтинговые / ранговые / etc. Основная идея данного режима: противники ищутся не случайные, а подходящие по скилу. Если ты скиловый игрок, ты будешь играть с такими-же скиловыми игроками, и наоборот, если ты не умеешь играть, ты будешь попадаться против таких же новичков.
В начале сезона игрок проходит серию калибровочных боёв по результатам которых определяется его стартовая позиция. Затем, в зависимости от дальнейшей успешности игры, игрок либо поднимается, либо опускается в рейтинге. Рейтинговая система в Блице создавалась, в первую очередь, для правильной балансировки. Она заточена на скилл игроков и практически не зависит от количества сыгранных игр.
Для реализации рейтинговых боёв понадобилось решить сразу две задачи. Во-первых, нужно было выбрать рейтинговую систему (по какому принципу начислять игрокам рейтинг). Во-вторых, нужно было доработать балансировщик, чтобы он собирал бои с учётом ограничений по рейтингу.
Основное требование к рейтинговой системе — возможность максимально точно определить уровень игрока. Чтобы оценить, насколько точно работает та или иная рейтинговая система, был создан симулятор, на вход которому подавали историю боёв и выбранную рейтинговую систему, а на выходе получали точность работы системы.
Точность считалась следующим образом:
Наиболее популярные системы расчёта рейтинга: winrate, Elo, Glicko, TrueSkill. Winrate — обычный процент побед. Elo — система подсчёта рейтинга, изначально созданная для игр с участием двух человек (шахматы, etc). В этой системе игроку за победу / поражение даётся / отнимается некоторое количество очков в зависимости от рейтинга противника. Glicko в целом похожа на Elo, но кроме этого учитывает, сколько времени игрок был не активен. TrueSkill — запатентованная рейтинговая система от Microsoft, в которой у каждого игрока есть два параметра: рейтинг и уверенность системы в этом рейтинге.
Во время разработки первой версии рейтинговых боёв мы рассматривали winrate и Elo (несколько вариантов, адаптированных к командной игре), а также простую систему Score (в которой игрокам всегда давалось фиксированное количество очков рейтинга за победу и отнималось за поражение).
Наилучшие результаты показала система Elo, в которой Ra — рейтинг игрока, а Rb — разница между суммарным рейтингом команды противника и суммарным рейтингом команды игрока за исключением самого игрока.
Основные трудности, с которыми мы столкнулись после запуска:
Первую проблему полностью решить не удалось из-за того, что скиловых игроков слишком мало, им приходится долго ждать, пока начнётся бой, и очень часто видеть в своих командах игроков послабее. Для смягчения эффекта мы сделали доступными рейтинговые бои только в прайм-тайм (то есть в то время, когда на серверах играет максимальное количество людей).
Вторую проблему мы решили, введя замедляющий коэффициент (то есть чем дальше игрок от среднего рейтинга, тем сложнее ему подниматься или опускаться ниже).
Также мы пробовали различными способами улучшить качество рейтинговой системы. В первых версиях для изменения рейтинга мы использовали только информацию о победе / поражении. Но у нас командная игра, и не всегда хорошие действия одного конкретного игрока приводят к победе всю команду. То есть даже в случае, если игрок хорошо играл, а команда проиграла, этот игрок получал такой же минус к рейтингу, как и все остальные игроки. Чтобы это предотвратить, мы стали пробовать учитывать индивидуальные действия игрока в бою.
Для этих целей мы пробовали применить машинное обучение: собрали различные факторы и пытались обучить модель предсказывать победу / поражение команды по действиям игрока в бою, чтобы потом использовать эту модель для определения коэффициента бонуса к рейтингу (то есть если команда проиграла, но поведение игрока было похоже на поведение игроков-победителей, давать таким игрокам дополнительный бонус).
Игрок из победившей команды который сыграл хорошо получил +40 к рейтингу. А который плохо всего +10
Мы смогли построить хорошую модель, которая показывала результаты существенно лучше текущей, но возникла одна сложность (которая довольно часто всё портит в задачах машинного обучения). Модель была хорошая, но у неё иногда бывали ошибки, которые хорошо заметны людям. Периодически возникали ситуации, когда игрок, который с точки зрения человека показал хорошие результаты — с точки зрения модели получал низкий бонус, и наоборот.
Заключение
Мы продолжаем развивать и улучшать балансировщик. Мы практически победили негативные впечатления от несбалансированности по классам. Основные проблемы, на которые обращают внимание наши игроки, — это несбалансированность по скилу, турбосливы и афк игроки. Это серьёзный вызов, мы продолжаем работу над балансировщиком в этих направлениях.
Если у вас есть какие-то вопросы / предложения по балансировщику в WoT Blitz, отписывайтесь вили на нашем форуме).
5 самых скилловых стримеров WoT Blitz
На YouTube множество каналов, посвященных мобильным танкам. В этой подборке будут авторы, которые лучше всего умеют играть в танки и показывать результат.
В подборку не попали многие, в том числе самые крупные стримеры. По моему мнению, эти ребята хорошо умеют развлекать, но не обучать. В этом топе главное – скилл.
5-е место. BepTyLLIka, 29k подписчиков
Андрей знает свое дело – 3000 среднего урона на десятках. Вертушка нагибает размеренно и спокойно, а еще он в доску свой парень.
4-е место. 4ekavo_81, 6k подписчиков
Вадим – обладатель голоса инструктора по спецподготовке морского десанта. Своим басом он может ломать кирпичи, которые откладывают его противники на поле боя. Вот уж кого можно звать батей без тени сомнения.
3-е место. Perfect_M1nd, 30k подписчиков
Чемпион мира 2016. Пожалуй, самый эксцентричный персонаж рейтинга. 3500 среднего урона на топах. Если вы не видели, что Алексей творит на Leopard 1, то вам срочно надо это посмотреть. И вишенка на торте – на его канале бывают стримы турниров с внутренними переговорами команды. Там есть, чему поучиться даже турнирным игрокам.
2-е место. _I_S_H_O_D_, 3k подписчиков
Алан – чемпион мира 2016. Все просто: безукоризненная стрельба, правильные тактические решения и непоколебимое спокойствие. У этого парня точно есть, что подсмотреть. Я бы поставил Алана на первое место, но он стримит с ПК (хотя отлично играет на сенсорном управлении).
1-е место. _n0_skill_just_luck_, 4k подписчиков
Как сам Артур говорит о своем творчестве: «Это дзен-нагиб». Топ-1 в рейтинговых боях и единственный, кому покорилась планка в 9000 рейтинга – этим все сказано. Железное правило Артика – не бомбить. У него можно научиться не только игре, но и тому, как сберечь свои нервные клетки.
Пишите свой топ в комментариях. Возможно, я кого-то забыл или пропустил.
Канал двс world of tanks blitz
Ответы разработчиков на актуальные вопросы игроков #5
1. Будут ли добавлены в игру тепловизионные прицелы?
Тепловидение планировалось в игре давно, но разработка все еще не началась, так как у этой функции есть некоторые конфликтующие механики. Поэтому тепловидение было отложено на неопределенный срок.
2. Будет ли у игроков возможность модифицировать танк как в WoT ПК?
Мы работаем над 3D-моделями (кусты, мешки, 3D-звезды и т.д.), которые игроки смогут устанавливать и вешать на свои танки.
3. Можно ли реализовать в игре режим высокой частоты кадров, например, 90 fps или 120 fps?
Есть ли в игре ограничение на частоту кадров? Если в игре есть ограничение на 60 и 120 кадров в секунду, планируем ли мы добавить что-то среднее, например, 90 кадров в секунду?
Текущий верхний предел частоты кадров составляет 60 кадров в секунду, игроки могут выбрать это в настройках.
Мы пытались настроить 90 кадров в секунду или выше, но это может быть очень тяжело для устройства.
Чтобы защитить ваше устройство, мы не будем делать настройку частоты кадров выше 60 кадров в секунду, пока оптимизация под большинство смартфонов не будет завершена.
4. Будет ли открытый бета тест для США или всей Северной Америки до даты релиза?
Мы надеемся, что в будущем будет запущен тест для Северной Америки, и мы узнаем мнение игроков из этого региона.
5. Будет ли игра доступна в Google Play Store для Юго-Восточной Азии?
В настоящее время у нас нет планов проводить открытый бета тест в Юго-Восточной Азии, данный регион будет включен в официальный список запуска во время официального релиза игры.
6. Смогут ли пользователи iOS получить какие-либо награды с первого открытого бета теста? (Поскольку они не могли принимать участие в нем)
Мы приносим свои искренние извинения за то, что пользователи iOS не смогли принять участие в предыдущем открытом бета тесте, однако мы можем выдать награды только тем, кто участвовал в нем.
Создание World of Tanks Blitz на базе собственного движка DAVA
Пролог
Эта история началась более трех лет назад. Наша небольшая компания 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-части движка:
Начало работ
Началось все с доказательства возможности отрисовать ландшафт на мобильных устройствах: тогда это были iPhone 4 и iPad 1.
После нескольких дней работы мы получили вполне функциональный динамический ландшафт, который работал довольно сносно, требовал где-то 8MB памяти и давал 60fps на этих устройствах. После этого мы начали полноценную разработку игры.
Прошло около полугода, и маленький мини-проект превратился в то, чем сейчас является Blitz. Появились совершенно новые требования: MMO, AAA-качество и другие требования, которые движок в его изначальном виде на тот момент уже не мог обеспечить. Но работа кипела полным ходом. Игра работала и работала неплохо. Однако производительность была средней, объектов на картах было мало, и, собственно, было множество других ограничений.
На этом этапе мы начали понимать, что фундамент, который мы заложили в движок, не выдержит пресса реального проекта.
Как все работало на тот момент
Вся отрисовка сцен была основана на простой концепции Scene Graph.
Основной концепции являлись два класса:
Первые шаги по улучшению ситуации
Для начала мы решили полечить проблемы с производительностью и сделать это быстро.
Собственно, сделали мы это, введя дополнительный флаг NEED_UPDATE в каждой ноде. Он определял, нужно ли такой ноде вызывать Update. Это действительно повысило производительность, но создало целый ворох проблем. Фактически код функции Update выглядел вот так:
Это вернуло нам часть производительности, однако началось много логических проблем там, где их не ждали.
LodNode, и SwitchNode — ноды, отвечающие, соответственно, за переключение лодов (по расстоянию) и переключение объектов (например, разрушенных и неразрушенных) — начали регулярно ломаться.
Периодически тот, кто пытался исправить поломки, делал следующее: отключал NEED_UPDATE в базовом классе (ведь это было простое решение), и совершенно незаметно FPS опять падал.
Когда код, проверяющий флаг NEED_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 и — вуаля.
Чтобы понять, как это работает, распишу на примерах, какие у нас есть системы:
В практически любой системе код выглядит следующим образом:
Системы можно классифицировать по тому как они обрабатывают объекты:
Соответственно, если есть желание можете заходить и смотреть на нашу имплементацию в деталях.
Учитывайте тот факт, что все писалось в реальном проекте, и, конечно, это не академическая реализация.