Unity developer ни в чем не виноват, дубль два.
Решил развить идею и показать на личном примере: оптимизация - это не только про код.
Но и от темы отходить не собираюсь. Теперь - подробно и с примерами (правда, с личного проекта, потому что DNA и все дела).
Мне с проектом помог Дмитрий, за что ему огромное спасибо. Код (сетевую часть) он предоставил -ассет со своими доработками.
Добавил свои модели, немного контента -и игра показала скромные 30 FPS при 10 игроках в аниматорах. Ещё раз: код хорош, тормозит далеко не он. Футажа тут не будет, простите — стыдно выкладывать игру с принтером вместо экрана. И тут началась магия.
Шаг первый 1. Замена шейдеров 2. Запекание света 3. Переработка ассетов
Получили нечто уже играбельное на Redmi Note 11 Pro (без записи в среднем +5–10 FPS). [Видео-пример]
Пошли тестировать на Exynos + Mali-G72 MP3 (Galaxy А51) -и принтер вернулся. 20–30 FPS при 20 противниках. Пошёл обратно договариваться с движком.
Шаг второй 1. Смена пайплайна 2.Пересборка физики под 2D 3. Постэффекты - опционально 4. Работа с аниматорами (в перспективе для большинства объектов планирую отказаться от них совсем) 5. Работа с апскейлом (снизил разрешение и дешёвым бинарным способом вернул его обратно)
И тут игра заиграла по-другому. Тест на Redmi Note 11 Pro — уже приятно. [Видео-пример]
А вот данные по Exynos + Mali-G72 MP3 (Galaxy А51) для разных количеств противников: FPS:Min-Max (Average) 20:48-60 (55) 40:23-58 (44) 60:9-45 (28) 80:5-25 (9)
Как видим, практически не меняя код (при смене физики пришлось немного потрогать), мы довольно сильно увеличили производительность проекта.
Итоги
Unity-разработчик по-прежнему ни в чём не виноват. Необходим системный взгляд на проект: шейдеры, ассеты, пайплайн, физика, аниматоры, настройки билда —-всё это живёт своей жизнью, и если не следить за ними, никакой даже самый идеальный код не спасёт от падения до 9 FPS на среднем железе.
Оптимизация -это командная дисциплина.
Всем супер-графики и минимум 60 FPS.