Стоит ли соло-разработчику лезть в DOTS/ECS или это оверинжиниринг

[cpp_veteran]

Делаю одну тауэр-дефенс соло. Везде кричат про ECS и DOTS, мол перформанс космос. Но синтаксис выглядит как будто я подписался на боль. Реально оно нужно для проекта где макс 2000 юнитов на экране?

[yaroslav_hex13]

2000 юнитов спокойно тянет обычный MonoBehaviour если не делать GetComponent в Update и не аллоцировать мусор каждый кадр. DOTS начинает реально окупаться от десятков тысяч сущностей. Тебе рано.

[savva_io]

Не соглашусь полностью. Дело не только в количестве, а в плотности симуляции. Если у тебя 2000 юнитов каждый ищет путь, проверяет соседей и стреляет — классический ОО подход тебя задушит кэш-промахами задолго до 10к.

[elena_net]

@perf_freak пути и поиск соседей выноси в Jobs + Burst без полного перехода на ECS. Получишь 80% профита за 20% боли. Гибридный подход недооценён.

[lev2082]

@gamedev_petr вот с этим согласен на 100%. Jobs+Burst+NativeArray для горячих циклов, а вся игровая логика остаётся на нормальных MonoBehaviour. Чистый ECS соло — это путь не дойти до релиза.

[alina_tech]

О, то есть можно точечно ускорить тяжёлые места джобами а не переписывать всю архитектуру? Это звучит человечнее. А Burst сложно подключить?

[denis9127]

@jun_dev_2026 Burst это просто атрибут [BurstCompile] над структом джобы по сути. Главное чтобы внутри был только blittable-код без managed-объектов. Профилируй сначала — может у тебя вообще боттлнек в физике или GC, а не в логике.

[tanya_ml]

Главная правда: большинство соло-проектов умирают не от低 fps, а от того что разработчик полгода полировал архитектуру вместо игры. Сделай чтоб работало, профилируй, оптимизируй узкое место. ECS как самоцель убил больше игр чем спас.

[ksenia_data]

Окей, принял. Делаю на обычных компонентах, узкие места в Jobs+Burst, ECS не трогаю. Спасибо всем, сэкономили мне месяц страданий.