Comments 17
Режим зануды
Серьезно? Статья о том, как зажечь/погасить иконку? О взаимодействии потоков корутин?
А как же MVP, например? Читать данные из модели и реагировать на события об ее изменении? И таких проблем бы не было… У вас вьюшка содержит игровую логику?
В текущей реализации сразу напрашивается CheckStatuses()
сделать корутиной, пробегая по статусам определять минимальный период когда будет смена какого-то из статусов ака minStatusTime и засыпать на это время.
А почему не реализовать каждый «статус» как компонент и не делать например так:
Тогда и не нужны корутины — каждый «статус» в своём Start() начинает отсчёт времени, добавляет иконку если ее еще нет, в Update(), изменяет поведение персонажа в зависимости от своей логики и времени действия, а в OnDestroy() заканчивает своё действие.
_character.AddComponent<Curse>()Тогда и не нужны корутины — каждый «статус» в своём Start() начинает отсчёт времени, добавляет иконку если ее еще нет, в Update(), изменяет поведение персонажа в зависимости от своей логики и времени действия, а в OnDestroy() заканчивает своё действие.
То есть перед добавлением статуса проверять, есть ли уже такой компонент на персонаже и если есть, то добавлять время. А если нет, то добавлять компонент. И компонент сам будет управлять, сколько ему осталось жить.
Очень любопытно, спасибо за идею. Подумаю над этим.
Очень любопытно, спасибо за идею. Подумаю над этим.
Не производительный подход.
OnDestroy вообще лучше в процессе игры не использовать, особенно на мобильных устройствах, лучше выключать компонент/объект, ибо OnDestroy требовательный + лишняя загрузка GC. Лучше инициировать в начале сцены, и затем использовать OnEnable/OnDisable — но не уверен что вызовы вызываются если только компонент выключается/включается, не было необходимости проверять это.
Манипулировать уже инициализированными переменными намного проще и быстрее, чем создавать новые компоненты в процессе игры.
OnDestroy вообще лучше в процессе игры не использовать, особенно на мобильных устройствах, лучше выключать компонент/объект, ибо OnDestroy требовательный + лишняя загрузка GC. Лучше инициировать в начале сцены, и затем использовать OnEnable/OnDisable — но не уверен что вызовы вызываются если только компонент выключается/включается, не было необходимости проверять это.
Манипулировать уже инициализированными переменными намного проще и быстрее, чем создавать новые компоненты в процессе игры.
Можно заранее добавить все компоненты на персонажа. Включать компонент enabled = true. И сделать метод на компоненте, который запускает отсчет времени и эффект. Когда время выходит: отключать эффект, enabled = false.
Мне кажется это способ аналогичен вашему, так как каждый компонент будет иметь локальную переменную, отвечающую за время, с ограничением на то, что только необходимые компоненты будут включаться.
Мне кажется это способ аналогичен вашему, так как каждый компонент будет иметь локальную переменную, отвечающую за время, с ограничением на то, что только необходимые компоненты будут включаться.
Если вы все равно проверяете это в Update, то почему нельзя завести переменную которая будет отвечать за время эффекта? Т.е. заводите float SlowTime. Пока она равна 0, то скорость обычная, как только накладывается эффект, то к ней прибавляется 5 (секунд), которые в Update уменьшаются по deltaTime. Как только ставиться 0, возвращаем скорость. Попадает на дополнительный эффект, просто прибавляем к SlowTime еще Х секунд.
Это будет намного производительнее и проще.
Это будет намного производительнее и проще.
У меня была такая мысль. В этом случае в Update будут проверяться переменные статусов, которые могут ни разу не наступить за все время сцены. Это меня и пугает, что за время, проведенное на этой сцене, 8 из 13 эффектов могут не сработать, но в Update на 4х персонажах эти переменные все равно будут проверяться на ноль каждый фрейм.
Создай Event и подписывай нужный Update только тогда, когда на игрока применился эффект… как только эффект спал, отписывайся от обновления и все. В итоге проверка будет работать только в случае если на игроке какой либо эффект.
Например у меня в игре, в моем коде, ровно один Update, FixedUpdate и LateUpdate которые запускают каждый свой Event, и в других скриптах где надо я подписываюсь на обновления, а где надо, отписываюсь. Update сами по себе вызываются медленно, и чем меньше их в проекте тем лучше.
13 * 4 = 52 проверки переменной на ноль за кадр это не просто быстро, это фактически бесплатно на данный момент. Я даже не уверен, что поддержка мэпа не обойдется дороже, если там будут постоянно добавляться/удаляться элементы, не знаю, как быстро в шарпе память для элементов мэпа аллоцируется. Пока там не будет хотя бы сотни эффектов на пару десятков персонажей, влияние на производительность даже из статистической погрешности не выберется. Т.е. как способ уменьшения лапши в коде продуманная система баффов/дебаффов это хорошо и удобно, но с т.з. перфоманса скорее всего лучше будет сконцентрировать силы на чем-то еще
Советую автору в качестве моделей присмотреться к ESC (https://habr.com/company/pixonic/blog/413729/).
Sign up to leave a comment.
Работа со статусами персонажа. Эксперименты в Unity