Управление активностью скриптов для оптимизации

[MaxBorn]

Доброго времени суток. У меня мелочь) В моём проекте, на каждом подбираемом предмете висит скрипт для взаимодействия с ним в инвентаре. Скрипт большой, много условий. Чтобы каждый объект этот скрипт все время не обрабатывал я его отключаю (галочка в редакторе, через скрипт- .enabled = false;), когда предмет не у игрока. Так и в документации советовали делать. Но вот недавно я выяснил, что оказывается так скрипт не отключается полностью. Выключаются лишь сообщения OnDestroy, OnAwake, OnApplicationQuit и что то там связанное с рендером еще. Вот меня теперь интересует есть ли смысл в дальнейшем отключать скрипты, или это только лишняя трата времени. И не взорвется ли ком, если на локации будут лежать десятки объектов со скриптом в котором обрабатываются десятки условий. И на сколько вообще условия, проверки много жрут ресурсов?
Так же хочу спросить. Для оптимизации лучше делать больше классов, но меньше в них писанины, или весь код собирать в одном классе по возможности, или разницы нет?

[1max1]

enable отключает еще и Update. Если так важна оптимизация смотри в сторону ecs, она как раз рассчитана на множество объектов.

[Jarico]

ecs, она как раз рассчитана на множество объектов.

ECS - сколько читал про вводимый в Unity ECS, так и не понял как ей вообще пользоваться... Усложнение кода не больше...

[1max1]

Усложнение кода не больше...

На вкус и цвет, как говориться. Лично от себя могу сказать, что она реально хорошо работает, и если объектов много и на каждом из них скрипт с апдейтом, то это очень даже полезная штука.
Вкратце пользоваться так:
Есть компонент, допустим, враг (дальше из него будет создана сущность).
Всё что делает враг, это идет за целью, значит у него будет 2 поля с двумя трансформами (его и цели).

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

class Enemy : EcsComponent
{
    public Transform transform;
    public Transform target;
}

Дальше мы должны создать сущность, обычно это выглядит как-то так:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

var enemy = EcsWorld.CreateEntity<Enemy>();
// тут из префаба с моделькой, создается объект и присваивается полю сущности
enemy.transform = Instantiate(_enemy).transform;
// устанавливаем цель
enemy.target = player.transform;
 

Дальше нужно двигать нашего врага, для этого нужна система, которая реализует интерфейс IEcsUpdate:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

[EcsInject] // благодаря атрибуту, EcsFilter будет автоматически заполнен (рефлексия)
class EnemySystem : IEcsUpdate
{
    EcsFilter<Enemy> fEnemy; // Здесь хранятся все сущности типа Enemy

    void IEcsUpdate.Update() // Реализуем интерфейс
    {
        for (int i = 0; i < fEnemy.count; ++i)
        {
            fEnemy[i].transform.position = Vector3.Lerp(fEnemy[i].transform.position, fEnemy[i].target.position, Time.deltaTime);
        }
    }
}

Осталось только добавить систему в список систем:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

EcsSystems.Add(new EnemySystem());
EcsSystems.Initialize();

Это очень обобщенное описание и из-за кучи разных ECS реализация разная.
p.s. Вот еще статейка про апдейты https://blogs.unity3d.com/ru/2015/12/23 ... ate-calls/

[MaxBorn]

Да, точно. Update не работает, я перепроверил. Но, допустим методы OnMouse.. работают. Так же есть доступ к переменным скрипта, их можно даже изменять. Это улучшает ситуацию, ради Update думаю стоит управлять активностью.
ECS интересная очень тема, буду изучать, спасибо. Как я понял это особенно полезная вещь для проектов, в которых большое количество объектов, особенно если они еще и часто спавнятся и удаляются.
А все таки на сколько условия, которые обрабатываются каждый кадр влияют на оптимизацию. Допустим простейшее if. Или метод OnTriggerStay. Хочется может на каждый объект кидать по скрипту с проверкой на столкновения. Но боюсь за оптимизацию, коллизия все таки.

[IDoNotExist]

А все таки на сколько условия, которые обрабатываются каждый кадр влияют на оптимизацию. Допустим простейшее if. Или метод OnTriggerStay. Хочется может на каждый объект кидать по скрипту с проверкой на столкновения. Но боюсь за оптимизацию, коллизия все таки.

Создаёшь 50000 объектов на сцене, заходишь в Profiler и смотришь, удаляешь условие, повторяешь всё заново, разница во времени и будет являться влиянием на производительность.

[MaxBorn]

Создаёшь 50000 объектов на сцене, заходишь в Profiler и смотришь, удаляешь условие, повторяешь всё заново, разница во времени и будет являться влиянием на производительность.

О, благодарю) О профайлере даже не знал.

[dzikar]

Не знаю, в тему или нет, но если много условий и часть из них постоянно работает, можно силами самого си шарпа слегка упростить себе жизнь. Использовать условные операторы && и || https://docs.microsoft.com/ru-ru/dotnet ... d-operator . У меня в коде много различных проверок и немного ресурсов экономится.

[MaxBorn]

Не знаю, в тему или нет, но если много условий и часть из них постоянно работает, можно силами самого си шарпа слегка упростить себе жизнь. Использовать условные операторы && и || https://docs.microsoft.com/ru-ru/dotnet ... d-operator . У меня в коде много различных проверок и немного ресурсов экономится.

Да, это само собой) Без них я бы наверное не смог бы написать свои коды)
Вот кстати интересный вопрос. Когда программа читает код и ей встречается допустим "if (a > b && c < b)". И если первое условие "a > b" неверное, продолжается ли чтение кода, или проверка if на этом заканчивается и чтение пропускает её. Это интересный вопрос, потому что у меня допустим достаточно много бывает таких к примеру проверок " if (ammo == true && inventoryItem.weapMouseCol != null && ammoObj.nameAmmo == inventoryItem.weapMouseCol.GetComponent<Weapon>().nameAmmo) " Достаточно ресурсоёмкая проверочка)

[1max1]

& - проверка продолжается, && - обрывается если фолс, тоже самое и с оператором или.

[MaxBorn]

& - проверка продолжается, && - обрывается если фолс, тоже самое и с оператором или.

А я то думал чем отличается двойной знак.. Теперь понятно, спасибо) Но не понятно для чего вообще продолжать проверку, если условие уже неверно?

[Tolking]

Для битовых операций, например.