Для простых анимаций, типа ухода в прозрачность, скейл, поворот и перемещение отлично подходят tween-engines, типа DOTween PRO (не реклама). Отпадает нужда в Animator’e, ассетах анимации и стейт машине, твины вызываются одной строчкой кода и могут быть объединены в последовательности (sequences).
С твинами нужно быть аккуратнее. Тот же DotTween генерить кучу мусора. Ассинхронные процессы и множество колбеков приведет к очень запутанным багам и утечкам. Так что стейт машина более надежна. А твины только для внутренных мелких анимаций виджетов.
1) норм перцам что зафигачили пару сотен интерфейсов, тут ничего нового 2) новичкам тут мне кажется непонятно 90% информации, ибо это теория которая непонятна в отрыве от практики.
ЗЫ я долго думал над эффективным способом подачи материла для дтф. И мне кажется что это
1) немножко общей теории 2) пример на конкретном случае, пошаговый 3) отсылки к более углубленным материалам, где заинтересовавшиеся могут погрузиться (например подборка видеотуторов на тему).
Согласен. Без реального проекта это просто вода, ничего толком не понятно. Вот бы своими руками пощупать, посмотреть, как в редакторе настроено, как в коде прописано.
Описанная система запутанная. Тот костыль с прозрачным квадратом "пока анимация не закончится" говорит о том что машины состояний используются не правильно.
Такие практики подходят только простым интерфейсам без большого количества менающихся данных. В более сложных случаях необходимо отходить от якорей к использованию layout.
Также, непонятно, почему не стоит наследоваться от существующих компонентов, особенно базовых вещей типа selectable. Конечно, механика работы компонентов документирована не всегда хорошо - но слава б-гу, весь Unity UI открыт на bitbucket для каждой версии Unity, код легко читаем и понять, что именно происходит, не предоставляет труда.
Кроме этого, если у вас много интерфейсов, пожалуйста, не забывайте о юнит-тестах! Система, которая в Unity не совсем корректно называется integration testing (та, которая, в отличие от "unit testing", может работать со сценами и gameObject'ами) просто прекрасно подходит для тестирования всего-всего-всего интерфейса, чтобы ловить поломки на самом раннем этапе.
Ну и, наконец, код игры не должен отправлять UI никаких запросов! Используйте наконец нормальный MVC и просто подписывайтесь на изменениях данных, которые получите при инициализации - это и делает разные компоненты игры менее зависимыми друг от друга, и разнообразное тестирование (как автоматическое, так и ручное, для художников и дизайнеров) делает гораздо проще.
Но вообще мне кажется это разные подходы не мешающие друг другу, можно и на ивентах строить и иметь некий менеджер данных, который выдаёт или с которого забирают данные. Например есть scriptable object в котором хранятся общие данные по игроку, проще оттуда брать чем собирать ивентами )
Используем аналогичную систему на работе - для создания, закрытия и управлением окнами, слоями и анимациями интерфейса. Сто лет как хочу причесать её и адаптировать под uGUI (мы используем NGUI), но руки никак не доходят. И всё время удивляюсь, заходя на asset store, почему до сих пор никто не выложил ни одного подобного инструмента. Ведь это же реальный мастхев для каждого разработчика.
Если есть некий стейт менеджер, то проще к сожалению переключать объекты, ибо не всегда интерфейс разбит на подканвасы и канвасы. Хотя это конечно плохой способ.
Для простых анимаций, типа ухода в прозрачность, скейл, поворот и перемещение отлично подходят tween-engines, типа DOTween PRO (не реклама). Отпадает нужда в Animator’e, ассетах анимации и стейт машине, твины вызываются одной строчкой кода и могут быть объединены в последовательности (sequences).
С твинами нужно быть аккуратнее. Тот же DotTween генерить кучу мусора. Ассинхронные процессы и множество колбеков приведет к очень запутанным багам и утечкам. Так что стейт машина более надежна. А твины только для внутренных мелких анимаций виджетов.
Все такие статьи пустоваты имхо, ибо
1) норм перцам что зафигачили пару сотен интерфейсов, тут ничего нового
2) новичкам тут мне кажется непонятно 90% информации, ибо это теория которая непонятна в отрыве от практики.
ЗЫ я долго думал над эффективным способом подачи материла для дтф. И мне кажется что это
1) немножко общей теории
2) пример на конкретном случае, пошаговый
3) отсылки к более углубленным материалам, где заинтересовавшиеся могут погрузиться (например подборка видеотуторов на тему).
Согласен. Без реального проекта это просто вода, ничего толком не понятно. Вот бы своими руками пощупать, посмотреть, как в редакторе настроено, как в коде прописано.
Описанная система запутанная. Тот костыль с прозрачным квадратом "пока анимация не закончится" говорит о том что машины состояний используются не правильно.
Такие практики подходят только простым интерфейсам без большого количества менающихся данных. В более сложных случаях необходимо отходить от якорей к использованию layout.
Также, непонятно, почему не стоит наследоваться от существующих компонентов, особенно базовых вещей типа selectable. Конечно, механика работы компонентов документирована не всегда хорошо - но слава б-гу, весь Unity UI открыт на bitbucket для каждой версии Unity, код легко читаем и понять, что именно происходит, не предоставляет труда.
Кроме этого, если у вас много интерфейсов, пожалуйста, не забывайте о юнит-тестах! Система, которая в Unity не совсем корректно называется integration testing (та, которая, в отличие от "unit testing", может работать со сценами и gameObject'ами) просто прекрасно подходит для тестирования всего-всего-всего интерфейса, чтобы ловить поломки на самом раннем этапе.
Ну и, наконец, код игры не должен отправлять UI никаких запросов! Используйте наконец нормальный MVC и просто подписывайтесь на изменениях данных, которые получите при инициализации - это и делает разные компоненты игры менее зависимыми друг от друга, и разнообразное тестирование (как автоматическое, так и ручное, для художников и дизайнеров) делает гораздо проще.
Хорошо сказал )
Но вообще мне кажется это разные подходы не мешающие друг другу, можно и на ивентах строить и иметь некий менеджер данных, который выдаёт или с которого забирают данные. Например есть scriptable object в котором хранятся общие данные по игроку, проще оттуда брать чем собирать ивентами )
Используем аналогичную систему на работе - для создания, закрытия и управлением окнами, слоями и анимациями интерфейса. Сто лет как хочу причесать её и адаптировать под uGUI (мы используем NGUI), но руки никак не доходят. И всё время удивляюсь, заходя на asset store, почему до сих пор никто не выложил ни одного подобного инструмента. Ведь это же реальный мастхев для каждого разработчика.
Забыли упомянуть само переключение межу канвасами через Canvas.enable а не GameObject.SetActive()
Если есть некий стейт менеджер, то проще к сожалению переключать объекты, ибо не всегда интерфейс разбит на подканвасы и канвасы. Хотя это конечно плохой способ.