1. На самом деле мы работаем полностью в рамках PhysX: плагин высчитывает какую силу и куда приложить к телу танка, в зависимости от текущего его состояния. Как раз именно просчётом перемещения занимается уже сам PhysX.
2. Анимационное дерево как таковое должно быть (именно оно управляет анимацией), но в теории можно свести к пустому дереву, создав кастомный класс-наследник AnimInstance и прописав всю логику в коде. Но мы такого не делали, вероятно могут возникнуть сложности :)
Речь идёт о кодировании объектов в RPC. Можно представить это как матрицу 32х32, первый инт — будет задавать к каким строкам применить состояние второго инта. Т.е. это некий аналог «индекс + состояние».
Нет, если у вас такое поведение unreliable функции, то это первый показатель что сеть у вас «забита». UFUNCTION(Client, Unreliable, NetMulticast) отлично доходят даже с большим числом параметров при нормальной загрузке сети (у нас немало вещей ходят на клиенты таким способом :) ).
Кодируется индекс + маска на 32 объекта, т.е. данный метод предполагает не репликацию массива, а отправку RPC. В случае если мир упорядочен разумно блоками в мире (например, персонаж въезжает в кучу объектов, которые лежат в одной маске или «рядом»), потребление сети и CPU минимально.
Пока ничего кроме голых утверждений ничего не вижу. Ссылочка на проект выше, продемонстрируйте навыки что ли? Мапхак — банальная задача, а что-нибудь более интересное дак вообще смотрелось бы весомым аргументом.
P.S. Про PUBG это даже не смешно. Первые версии и спидхаку были подвержены, ну и? Если вы его копали, вы прекрасно знаете какие вещи там архитектурно были косячны со старта, что для беты весьма ожидаемо.
Это актуально для любого массового движка, только не имеет никакого отношения к сетевому стеку.
Есть принципиально два разных направления хаков:
1. Хак клиента, который вы описали. Мапхаки, воллхаки, эймхаки и иже с ними. Борьба с этим — постоянное противоборство щита и меча. Чем популярнее технология клиента или сама игра — тем больше высококлассных спецов его «разбирают». Читаки пишутся далеко не «мамкиными хакерами» (это потом уже тулзы общего назначения они стараются приладить, но серьёзные читаки это весьма бизнес). Защита — определять по косвенным признакам и банить. Сложно, дорого, не надежно.
2. Хаки косяков сетевой архитектуры. Например, когда клиент решает откуда и куда он выстрелил, а сервер ему верит. Очевидно, это кривые ручки разработчика игры, давшего клиенту авторитарные права на такие вещи. Защита — бить по ушам разработчика. Архитектура, которая не верит клиенту ни в чем, кроме инпута, полностью устойчива к такому виду хаков.
Если ваша игра популярна, с хаками из первого пункта все равно бороться самим ;)
C++, все сетевые вещи строго переношу в код. На уровне прототипа БП нормально использовать для сети, но для продакшна такие вещи в них оставлять опасно.
Кстати, ещё одна ловушка в БП и плюсах:
Спасибо за дополнения! :) Еще из веселого — переопределенная в дочернем классе мультикаст функция в блюпринтах будет вызываться дважды, если дёрнуть Parent функцию. Описано здесь, если кому интересно.
Я ни в коем случае не хочу принизить вашу статью, и это здорово, что вы и на арч линуксе запустили движок и работаете с ним, но все-таки тех, кто спрашивает про «завести под вайном», я бы отправлял «на убунту», где весь этот шаманизм не нужен.
Сам я использую инструменты исходя из соображений их удобства для работы с конкретной технологией, оставляя личные предпочтения для «домашних нужд».
И вы знаете, это прекрасно работает. Быстро, понятно и удобно. При правильной архитектуре проекта ещё и собирается шустро. Не так там много правил, которым надо следовать. И никто не мешает вам использовать сипипи на полную :)
А CE хоть и более «путь сипипи самурая», но архитектурно печален. Это не двигло для игр, а скорее сипипи песочница :(
Потому что это не скриптинг, это — программирование. Для «скриптов» есть прекрасные Blueprints, где в ногу себе выстрелить даже при желании сложновато ;)
К половине прекрасных андроидовских устройств скоро будет применён лейбак «не поддерживается Гугл плеем», о чем вы? Если вы ставите работу над играми в Гугл плее равенство «работа под лоу энд», то это уже не так. Посмотрите хотя бы игры из начала статьи, прекрасные примеры как можно делать продукт, мега успешный на рынке, не оглядываясь на девайсы такого типа.
Да нельзя охватить весь рынок, никак. Вы всегда чём-то жертвуете, особенно на андроиде. И тут встаёт выбор — либо вы работаете под лоу энд девайсы, со всеми вытекающими, либо ставите адекватные рамки — для игровых устройств. Разные ниши, разные пользователи, разные деньги. Sdk 21 версии относительно скоро будет уже минимальным для стора, впереди 64 бит и прочие радости.
Для китайских собратьев есть даунскейл. Хуже, когда сам чип GPU беден как ни крути :(
забивая на момент, что это была реклама мобильной армы…
Как публикация доклада, прочитанного ровно год назад?.. :)
Железо для билдов «из коробки» — для анриала требуется в 2 раза сильней.…
… Возможно, Ваша кастомная версия для разработчика армы отлично оптимизирована, но многим компаниям дешевле просто юнити из коробки взять.
Ну… нет. В разработке используем обычную версию из лончера. Никаких сверхтребований к железу редактор не предъявляет ни разу. Даже маки без выделенных GPU используются на ура. CPU наше всё, но это очевидно когда работаешь с C++, а не скриптовыми языками.
А вот место на жестком диске да, анрил к нему всегда был требовательным. Но SSD в 240 Гб, доступный каждому уже несколько лет как, более чем достаточен для связки ОС + движок + проект.
Цена ассетов различается на порядок, количество — уже на 2 порядка. И все не в пользу анриала. Как минимум прототипирование из-за этого проще на юнити.
Наши художники только что узнали много нового… :) Цена ассетов и количество никак не зависят от движка при правильной организации пайплайна разработки. Это вообще нонсенс. PBR он и в Африке PBR, всё остальное — вторично.
Глобально есть разница только «доступно по LTE» и «недоступно».
Нет сравнения портирования на платформы, а на юнити платформ больше, проще портирование и куча партнеров (CloudMoolah, FacebookGoogle, Intel, Microsoft, Oculus, OTOY, Samsung, Vuforia, Xiaomi)
Да и доклад вообще не про Unity vs UE4… Оо
У анриала тут свои вкусности, у юнити — свои. О «простоте портирования» можно ой многое рассказать) Поддержка платформенных вещей встроенная у анриала слабовата, но уже кучей весьма классных плагинов расширена.
На юнити громадное количество и мобильных и пк игр. Если бы анриал был выгодней, ситуация была бы обратной.
+у анриала % ставка с продаж, а у юнити просто оплачивай подписку на человекоместа.
Юнити для мобилок старше анриала на несколько лет. Всё успеется, подождите. Это ж самый первый пункт в статье выше :)
Про % вопрос с Эпиками решаем был всегда.
Анриал — хороший и самый мощный инструмент, но далеко не самый выгодный для мобильной разработки в данный момент.
2. Анимационное дерево как таковое должно быть (именно оно управляет анимацией), но в теории можно свести к пустому дереву, создав кастомный класс-наследник AnimInstance и прописав всю логику в коде. Но мы такого не делали, вероятно могут возникнуть сложности :)
P.S. Про PUBG это даже не смешно. Первые версии и спидхаку были подвержены, ну и? Если вы его копали, вы прекрасно знаете какие вещи там архитектурно были косячны со старта, что для беты весьма ожидаемо.
Есть принципиально два разных направления хаков:
1. Хак клиента, который вы описали. Мапхаки, воллхаки, эймхаки и иже с ними. Борьба с этим — постоянное противоборство щита и меча. Чем популярнее технология клиента или сама игра — тем больше высококлассных спецов его «разбирают». Читаки пишутся далеко не «мамкиными хакерами» (это потом уже тулзы общего назначения они стараются приладить, но серьёзные читаки это весьма бизнес). Защита — определять по косвенным признакам и банить. Сложно, дорого, не надежно.
2. Хаки косяков сетевой архитектуры. Например, когда клиент решает откуда и куда он выстрелил, а сервер ему верит. Очевидно, это кривые ручки разработчика игры, давшего клиенту авторитарные права на такие вещи. Защита — бить по ушам разработчика. Архитектура, которая не верит клиенту ни в чем, кроме инпута, полностью устойчива к такому виду хаков.
Если ваша игра популярна, с хаками из первого пункта все равно бороться самим ;)
Спасибо за дополнения! :) Еще из веселого — переопределенная в дочернем классе мультикаст функция в блюпринтах будет вызываться дважды, если дёрнуть Parent функцию. Описано здесь, если кому интересно.
Сам я использую инструменты исходя из соображений их удобства для работы с конкретной технологией, оставляя личные предпочтения для «домашних нужд».
А CE хоть и более «путь сипипи самурая», но архитектурно печален. Это не двигло для игр, а скорее сипипи песочница :(
Для китайских собратьев есть даунскейл. Хуже, когда сам чип GPU беден как ни крути :(
Как публикация доклада, прочитанного ровно год назад?.. :)
Ну… нет. В разработке используем обычную версию из лончера. Никаких сверхтребований к железу редактор не предъявляет ни разу. Даже маки без выделенных GPU используются на ура. CPU наше всё, но это очевидно когда работаешь с C++, а не скриптовыми языками.
А вот место на жестком диске да, анрил к нему всегда был требовательным. Но SSD в 240 Гб, доступный каждому уже несколько лет как, более чем достаточен для связки ОС + движок + проект.
Наши художники только что узнали много нового… :) Цена ассетов и количество никак не зависят от движка при правильной организации пайплайна разработки. Это вообще нонсенс. PBR он и в Африке PBR, всё остальное — вторично.
Глобально есть разница только «доступно по LTE» и «недоступно».
Да и доклад вообще не про Unity vs UE4… Оо
У анриала тут свои вкусности, у юнити — свои. О «простоте портирования» можно ой многое рассказать) Поддержка платформенных вещей встроенная у анриала слабовата, но уже кучей весьма классных плагинов расширена.
Юнити для мобилок старше анриала на несколько лет. Всё успеется, подождите. Это ж самый первый пункт в статье выше :)
Про % вопрос с Эпиками решаем был всегда.
Ключевой вопрос — смотря для чего.