Провел небольшой эксперимент с html5 играми.
Обновил 2 игры из 4. Обновления включают:

- добавление процента загрузки на лоадер скрине;
- исправление бага в Chrome, когда игра загружается в отдельной фоновой закладке, иногда iframe может иметь размеры 0х0.

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

В общем вывод такой:
- делайте явным процесс загрузки. показывайте проценты на экране. Желательно еще и с анимацией, чтобы пользователь точно видел прогресс;
- убедитесь, что игра открывается и загружается в фоновой вкладке без проблем. В Defold это исправлено в 1.2.181, но если используете более раннюю версию, то обязательно посмотрите этот PR и примените эти изменения в ваш шаблон: https://github.com/defold/defold/pull/5641/files

Я не могу отделить одно от другого т.к. не знаю что именно дало результат. Поэтому рекомендую проверять оба пункта.

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

TLDR:
Если в приоритете оперативная память, то лучше использовать
ASTC 6x6 или 4x4 если качество нужно очень высокое (6х6 выглядит довольно хорошо, для большинства текстур)
——если не поддерживается——>
PVRTC 4bbp для iOS или ETC2 для андроид
——если не поддерживается——>
RGBA, а что поделать

Если в приоритете размер на диске или скорость скачки, а оперативная память уже не так важна (например для HTML5), то лучше использовать WebP lossy, подобрав допустимое качество (Но это компрессия, текстура в памяти будет стандартная RGBA)

——

Самым лучшим вариантом является ASTC - это просто боженька компрессий. Мэтры которые даже снят компрессию пророчат ему то, что он станет убийцей всех форматов если придет на PC (с Apple M1 это уже становится реальным и надеюсь остальные подхватят, но посмотрим).

У него соотношение качество/размер очень классное + есть возможность играться с качеством меняя размер блока. https://android-developers.googleblog.com/2015/01/efficient-game-textures-with-hardware.html

6x6 подойдет почти всем при этом в памяти занимает меньше даже чем PVRTC 4bbp.

Для RGBA текстуры размером 2048х2048 занимаемая память будет такой:

ASTC 6x6 - 1.8Mb
ASTC 4x4 - 4Mb
PVRTC 4bbp - 2Mb
ETC2 - 4Mb

Если качество нужно повыше, то есть ASTC 4x4 - там к качеству сложно придраться.

Но из-за того, что покрытие не 100% приходится рассматривать другие форматы. PVRTC 4bbp и ETC2.

Аппаратная поддержка ASTC появилась только с A7 (iPhone6) а iPhone5s хоть уже и на Metal, но все щее не поддерживает ASTC. Поэтому если вам нужна поддержка iPhone5 и его ровесников (iPad Air, iPad mini 2/3), то вам нужен PVRTC.

ETC2 для андроидов, что не поддерживают ASTC. Cтатистика тут https://developer.android.com/guide/app-bundle/asset-delivery/texture-compression
ETC2 поддерживается всеми устройствами с OpenGL ES 3, поэтому если у вас есть такое минимальное требование на проекте, то поздравляю, ETC2 ваш вариант. А вот если вы поддерживаете OpenGL ES 2 придется подумать и про другие варианты и ухищрения.

В Defold используется Basis Universal UASTC, чтобы решить вопрос компрессии как с точки зрения энкодера (кроссплатформенный PVRTC энкодер, это та еще головная боль) так и с вопросом транксодинга в рантайме.
Сейчас в Defold вот такие водопады для текстур.
Правки еще вносятся и форматы уточняются т.к. тема обширная. Но сам подход гарантирует, что будет использоваться оптимальный формат текстуры, поддерживаемый железом на каждом конкретном устройстве. Размер basis контейнера на диске тоже меньше за счет оптимизации для LZ компрессии.

Но на многих WEB проектах приоритеты могут отличаться и самым важным является размер ресурсов на диске(сколько качать пользователю). И, как оказалось, наилучший вариант по размеру/качеству выдает WEBP lossy.

Небольшое сравнение Basis и WebP с точки зрения размера файлов (оно не учитывает остальные характеристики).
Помимо WebP и UASTC в сравнение включен ETC1s (BasisU), который, как мне кажется, даже при максимальных настройках качества, не пригоден для игр.

У меня появилась возможность проверить насколько механизм докачки файлов при плохом соединениее влияет на метрики HTML5 игры.

Ситуация такая.

Defold в своем шаблоне HTML5 учитывает очень многие аспекты работы с вэб играми. Одним из таких аспектов является и повторная попытка докачать файлы в случает проблем соединения.

Но совсем недавно @aglitchman обнаружил, что в Defold версии 1.2.175 механизм, что делает попытку повторно загрузить файл в случае ошибки xhr, сломан. Это не самый очевидный механизм, поэтому такое случается, когда переписываются большие куски кода. Артем исправил это в версии 1.2.182.

Но вернемся к играм.

После последнего апдейта в одной из игр, где размер игры побольше, метрики стали медленно падать и я долго не мог понять почему.
Вчера я догадался проверить, если у меня в последнем апдейте баг с докачкой и обнаружил, что он есть во всех моих играх на poki (т.к. все они обновлялись версиями собранными на 1.2.175-1.2.182).

Я скачал архивы всех моих игр как есть и не пересобирая сами игры пофиксил только одну единсвенную строку в js файле отвечающим за загрузку игры. После этого выкатил обновления.

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

О результатах эксперемента расскажу через несколько дней, когда будут данные.

Подписывайтесь, чтобы не пропустить.