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.