Как за день потерять 30% онлайна и за два месяца сделать батлрояль

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

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

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

Игрок должен видеть всю карту, потому что:

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

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

Не пробовали. Думаю, получится много ошибок компиляции и нерабочий билд, если не потратить месяцы на адаптацию под веб :)

Не пробовали печь текстуру на старте уровня? Это должно сильно уменьшить размер билда, правда сожрет больше видеопамяти.

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

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

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

Инстансинг использовался?

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

Статья годная, давно тут такого не было...

Спасибо! :)

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

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

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