Pixonic

Привет! У нас была вот такая статья: https://habr.com/ru/company/pixonic/blog/343306/

Возможно, она поможет)

Спасибо!

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

К сожалению, такими сравнительными цифрами мы не обладаем, поскольку такого a/b-теста не проводили. Вместе с этим в реальных сценариях мы наблюдали более высокую утилизацию текстурного кэша — с 50% выросло до 87%. Можно предположить, что при частой смене текстур (texture binding) кэш почти наверняка инвалидируется. Минимальное количество перепривязок , как происходит в случае с текстурными массивами, позитивно сказывается на переиспользовании данных в кэше.

Да, с ним уже действительно мало кто работает. На OpenGL ES 2.0 мы только начинали разрабатывать War Robots больше семи лет назад — сейчас на смену ему пришли уже OpenGL ES 3.0 и Vulkan.

Да, все верно. Текстуры от билда могут занимать от 80%, поэтому за их весом следить действительно критично.

Не оправдания, а устранение недопонимания! Конструктивные диалоги — это круто

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

...или реальность? :)

Не изобретали, конечно, зато практикуем :) Kanban, например — систему постановки задач, при которой все этапы проекта для наглядности визуализируются на специальной доске. Что позволяет проще отслеживать статус задач и контролировать нагрузку сотрудников.

Облачное решениеТехнически — и это тоже, мы есть, например, на MY.GAMES Cloud

обслуживает 400тыс активных пользователейВ день :)

Почти угадали!

GaaS-проект 7+ лет в оперировании с 400k-450k DAU и вышедшим год назад масштабным ремастером :)

Три из двенадцати, но да, спасибо, что заметили

Данные по Steam, как часто разработчики выпускают игры на том или ином движке, можно посмотреть на диаграммах выше. Ссылка на данные, на которые мы опирались, в статье есть, сами мы статистику не собирали.
О неудобствах разработки на Unity в статье, кстати, тоже есть :)

Other — движки, которые не стали выделять в отдельную категорию, Unknown — которые не удалось идентифицировать.

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

Упоминаем. В третьем абзаце есть ссылка на анализ, сделанный Ларсом Дусе при участии xPaw.

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

Мы пробовали выкладывать все в билд на iOS, оказалось, что когда размер билда больше 1ГБ, у пользователя резко пропадает желание такую игру скачивать. Особенно, если это новые игроки, которые это делают просто ради интереса, нажав ссылку на рекламе.

Если Google Play Store не доступен, на этот случай есть специальные коды ошибки, на которые можно особым образом отреагировать: например, показать сообщение «Скачайте игру из официального источника» с кнопкой-ссылкой. Но пока мы всех отправляем на CDN и собираем статистику, сколько таких людей и как дорого они нам обходятся.

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

Статью можно почитать как здесь, так и на Хабре, все верно.

Сейчас в релизе у нас гибридная система под названием DeliverySystem. Она использует как CDN, так и возможности дистрибьюции, доступные платформам — такие как Play Delivery Assets на Android и On-Demand Resource на iOS.

Да, дело в именно сроках: мы не успевали закончить фичу к основному релизу, поэтому пришлось идти на меры, описанные в этой статье.

Vanilla исторически называют оригинальные версии, т. е. в нашем случае это игра до ремастера :)

Тут есть несколько факторов.

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

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

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

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

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

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

Redmi принадлежит Xiaomi, все верно. Но флагманы Xiaomi тянут Vulkan, а именно линейка Redmi — нет.

Vulkan пока отключили совсем, так как движок не позволяет сделать переключение между графическими API прозрачным. Это можно сделать через Java, но довольно сложно поддерживать.

По второму вопросу — stay tuned. Delivery System решает эту проблему. При чем отчасти не совсем стандартным для большинства на рынке методом. По крайней мере аналогов на рынке мы видели очень мало.