Pull to refresh
53
0
Иван Кийко @barrettdesign

Product Owner

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

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

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

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

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

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

Проджектайлы
image

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

У нас есть настройки типа low/normal. Они срабатывают автоматом, когда определяется мощность девайса. Также есть настройка частоты кадров.

К сожалению, нагрузка от режима это не только рендер. На большой карте могут играть 100 игроков, а на маленькой 30. Сотня пользователей — это сетевые сообщения, которые нужно обрабатывать, к тому же на большую карту нужно в 4 раза больше лута, чтобы не тратить много времени на его поиски.
Проблему с отсутствием etc2 решили кастомным шейдером и препроцессингом текстур.

Девайсов без gles3 10,5% процентов глобально, у нас таких пользователей — 12%. У нас они генерируют в районе 3% прибыли, но еще главнее — они генерируют онлайн, который критически важен для сетевых шутеров. Отказаться от этих игроков ради роста производительности на пару процентов в дополнительном игровом режиме — звучит как не очень заманчивый бизнес-план :)
Игрок должен видеть всю карту, потому что:

  • он пролетает над ней на самолете и выбирает точку высадки;
  • на ней есть лендмарки и точки интереса для ориентации в пространстве (например, горы или высокие постройки);
  • игрок может на эти горы и постройки залезть и увидеть всю карту целиком.

Террейн — не самая большая проблема, которую нужно было решить. Больше проблем доставляли десятки тысяч объектов, расставленных на карте. Даже если их не было видно, Unity все равно рассчитывал для них лоды, и они занимали место в памяти. А те, которые было видно, отсылали сотни запросов на отрисовку. Это все решили мешбейкером, пулом объектов и оклюжен кулингом.
Не пробовали печь текстуру на старте уровня? Это должно сильно уменьшить размер билда, правда сожрет больше видеопамяти.
Мы поддерживаем очень много старых смартфонов и планшетов. В случае запекания в рантайме нам бы пришлось аллоцировать память под изначальные текстуры и меши, финальный атлас и финальные меши, и к этому еще добавилась бы нагрузка от алгоритма упаковки. Многие бы просто на этом месте закрашились по памяти, а остальные получили заметно выросшее время загрузки.

По поводу лодов — был ли вообще смысл в них, если туманом все рубилось по фиксированной дистанции? FarPlane просто бы кулил ненужное и все — сэкономили бы по памяти на мешах.
Лоды точно нужны. Если их выключить, то fps заметно просядет. А так как в нашем проекте кубическая графика, экономия на отсутствии мешей для лодов будет несущественной.

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

Статья годная, давно тут такого не было...
Спасибо! :)

P.S. Насчет запекания света. Год назад я зашел еще дальше и запек 3D-карту теней в 2D-текстуру.

Не пробовали. Думаю, получится много ошибок компиляции и нерабочий билд, если не потратить месяцы на адаптацию под веб :)
Разработка проекта началась в 2012 году, когда UE4 даже не вышел. Да что там Unreal, даже Unity тогда еще не был лидирующим движком в мобильных играх, и команда училась с ним работать на ходу.

Если бы выбирали сейчас, то все равно остановились бы на Unity, просто потому что есть большой опыт работы с движком. Еще важно понимать, что мобильная игра это не только код, но и куча сторонних SDK, которые нужно подключать и поддерживать: AppsFlyer для маркетинговой аналитики, IronSource или AppLovin для рекламной монетизации, плагины для обфускации, для сокетных соединений и другие. И так как проектов на UE4 пока что не очень много, то большинство плагинов и SDK поддерживается хуже по сравнению с Unity.

Что касается мифов о том, что UE4 более оптимизированный, чем Unity, то тут дело скорее в разработчиках, чем в движке. Как пример, проекты компании Madfinger Games, выдающие графику консольного уровня на средних мобильных девайсах, или нашумевший недавно Genshin Impact со сказочной картинкой и оптимизацией.

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

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

Точность конечно немного меньше чем точность вашего алгоритма — но у него есть свои плюсы. Процессинг выполняется очень быстро. И доступен предпросмотр в рантайме.
Вот так выглядит результат работы алгоритма:
А чем не понравился вариант скалярного произведения векторов?

Information

Rating
Does not participate
Location
Россия
Registered
Activity