Верно, поэтому у меня рейкастам посвящена половина статьи. Способ хороший, не спорю, но это потенциально десятки и десятки коллайдеров и рейкастов в каждой сцене. Плюс есть такие вещи, как запеченный свет и environment lightning. Там нельзя оценить свет одним рейкастом, требуется отдельная отладка.
Интересно. Я думал об этом способе, но не смог найти вменяемых реализаций. Надо будет перепроверить информацию и, если вы правы, дополнить статью.
Спасибо!
Если кратко — пишем машину состояний, где каждое действие машины хранится в виде отдельного ScriptableObject'a. И каждый переход между состояниями.
А потом создаем EnemyStateController, который управляет своими состояниями. Он подаёт информацию о себе в ScriptableObject'ы, они занимаются логикой и возвращают изменения обратно контроллеру.
Таким образом, можно комбинировать различные действия для получения различных состояний, править действия состояний отдельно друг от друга, создавать разные экземпляры действий для разных типов врагов…
Основные преимущества — модульность и удобство. Можно с написанной логикой работать прямо в инспекторе, создавая состояния и раскидывая по ним действия.
Но и тут есть свои проблемы и особенности реализации.
Моя неприязнь говорит о том что я видел более лучшие архитектурные решения.
Не поделитесь знаниями?
с каких вообще пор класть ВСЁ состояние приложения в статическую переменную стало хорошо
К сожалению, я не смог найти ничего более красивого для хранения и сохранения информации о сценах (когда на них десятки предметов и объектов, состояния которых надо помнить). Если в юнити существуют встроенные решения — мне о них неизвестно.
Ничего «элегантного» в вычислении характеристик персонажа я не вижу. Один класс яростно юзает во все дыры публичные поля структуры, лежащей в публичном поле, лежащей в публичном поле, лежащей в статической переменной. Оооочень элегантно.
Если какую-либо информацию использует только один скрипт — не спорю, лучше прописывать её в этом скрипте и не заморачиваться. Но если таких скриптов МНОГО — то приходится либо пилить систему сообщений, либо настраивать паутину ссылок, либо юзать публичные поля публичных полей публичных полей.
К слову, не поясните, в чем природа вашего отторжения сиглтонов и статических переменных?
Спасибо!
Лучше. Но как я понимаю, система ивентов несколько хромает в плане перформанса. Поэтому я использовал собственное решение.
unity3d.com/learn/tutorials/topics/navigation/finite-state-ai-delegate-pattern
Если кратко — пишем машину состояний, где каждое действие машины хранится в виде отдельного ScriptableObject'a. И каждый переход между состояниями.
А потом создаем EnemyStateController, который управляет своими состояниями. Он подаёт информацию о себе в ScriptableObject'ы, они занимаются логикой и возвращают изменения обратно контроллеру.
Таким образом, можно комбинировать различные действия для получения различных состояний, править действия состояний отдельно друг от друга, создавать разные экземпляры действий для разных типов врагов…
Основные преимущества — модульность и удобство. Можно с написанной логикой работать прямо в инспекторе, создавая состояния и раскидывая по ним действия.
Но и тут есть свои проблемы и особенности реализации.
Не поделитесь знаниями?
К сожалению, я не смог найти ничего более красивого для хранения и сохранения информации о сценах (когда на них десятки предметов и объектов, состояния которых надо помнить). Если в юнити существуют встроенные решения — мне о них неизвестно.
Если какую-либо информацию использует только один скрипт — не спорю, лучше прописывать её в этом скрипте и не заморачиваться. Но если таких скриптов МНОГО — то приходится либо пилить систему сообщений, либо настраивать паутину ссылок, либо юзать публичные поля публичных полей публичных полей.
К слову, не поясните, в чем природа вашего отторжения сиглтонов и статических переменных?