Разработчик игр, интерактивных стендов и интерактивной рекламы. Эксперт в области интерактивов и XR.
100+ проектов за 5 лет. https://whitelabelgames.ru
По вопросам сотрудничества писать: @it_bizdev
Post #1896
1.15K
Про «Наблюдателя»
https://www.youtube.com/watch?v=0wVF68QZrtQ
Хорошее видео, но на самом деле депенденси хелл чутка преувеличен. Потому что тут вопрос реализаций представленной в видео. Да паттерны обладают разными недостатками. Но тут мне не совсем нравится логика регистрации объектов в наблюдателе. Хотя в видео по сути поднимается проблема депендеси хела со всякими менеджерами типа звука.
И в целом берется небольшая проблема прямолинейной реализации. С миллионами зависимостей, узкими точками отказа и так далее. На самом деле это бывает даже не так критично, когда вы пишете не движок, не библиотеку и не фреймворк :)
Разберем на примере менеджера звука. Есть про менеджер звука знают объекты визуализации и объекты игровой логики, это казалось бы потенциальная точка отказа. Но мы не на сервере с сложной реализацией сервиса. Менеджер звука обычно это весьма условно стейтлесс штука (точнее её стейт не особо меняется), и она по сути просто что вызывает «системные вызовы» воспроизведения звуков. По крайней мере в той точке где миллиард зависимостей. Если зависимости не меняют состояния, обращаются в точку которая не может отказать и вызывают довольно тупые методы — там сложно создать себе проблемы. Это происходит в других случаях, где множество зависимостей меняют состояние объекта в не пойми каком порядке.
Но базово как этой проблемы избежать? Вот у нас есть звук при спауне, звук при сборе и так далее. И тут нам помогает композитная система Unity компонент. И абстрактные Unity события. Система компонент позволяет по юнити событиям делать подобные вызовы при этом не зная о контексте остальной системы. Да и в целом это работает специфично. Потому что это как раз ведет нас к разнице подходом Config-First, Code-First и так далее далее.
Но и у них есть своя цена. Код ферст всегда позволяет почти всегда быстро находить проблемы, так как там нет контрактов, которые не зафиксированы в коде. Конфиг ферст всегда имеет какой-то внешний абстрактный контекст и часто требует документации.
Для примера с тем же пресловутым звуком. У вас есть понятное место в коде где по логике вызывается сбор кристаллов. И вы вызываете там звук сбора кристалла. Всё явно и очевидно. Альтернативное решение без лишних зависимостей. У вас есть компонента которая в OnDisable вызывает звук по айди. Айди сериализованное поле. Вам нужно повесить на префаб кристалла эту компоненту и прописать айди соответвующего звука. И это уже некий абстрактный контракт не зафиксированный кодом.
А видос рекомендую посмотреть. Так как понимать как можно играться с архитектурой проекта полезно. И автор говорит дельные вещи. Что в конкретном примере это не критикал — это неважно. Так как когда создаешь подобные материалы трудно подобрать пример который подсвечивает все нюансы.
#новости #мнение
YouTube Why the Observer Pattern Isn't Enough Unity's Observer pattern is everywhere - but most tutorials skip the part where it starts hurting you.
In this episode of the Architecture Series, we take the centralized God Object from
part one and refactor it using C# events and the Observer pattern.… https://www.youtube.com/watch?v=0wVF68QZrtQ
Хорошее видео, но на самом деле депенденси хелл чутка преувеличен. Потому что тут вопрос реализаций представленной в видео. Да паттерны обладают разными недостатками. Но тут мне не совсем нравится логика регистрации объектов в наблюдателе. Хотя в видео по сути поднимается проблема депендеси хела со всякими менеджерами типа звука.
И в целом берется небольшая проблема прямолинейной реализации. С миллионами зависимостей, узкими точками отказа и так далее. На самом деле это бывает даже не так критично, когда вы пишете не движок, не библиотеку и не фреймворк :)
Разберем на примере менеджера звука. Есть про менеджер звука знают объекты визуализации и объекты игровой логики, это казалось бы потенциальная точка отказа. Но мы не на сервере с сложной реализацией сервиса. Менеджер звука обычно это весьма условно стейтлесс штука (точнее её стейт не особо меняется), и она по сути просто что вызывает «системные вызовы» воспроизведения звуков. По крайней мере в той точке где миллиард зависимостей. Если зависимости не меняют состояния, обращаются в точку которая не может отказать и вызывают довольно тупые методы — там сложно создать себе проблемы. Это происходит в других случаях, где множество зависимостей меняют состояние объекта в не пойми каком порядке.
Но базово как этой проблемы избежать? Вот у нас есть звук при спауне, звук при сборе и так далее. И тут нам помогает композитная система Unity компонент. И абстрактные Unity события. Система компонент позволяет по юнити событиям делать подобные вызовы при этом не зная о контексте остальной системы. Да и в целом это работает специфично. Потому что это как раз ведет нас к разнице подходом Config-First, Code-First и так далее далее.
Но и у них есть своя цена. Код ферст всегда позволяет почти всегда быстро находить проблемы, так как там нет контрактов, которые не зафиксированы в коде. Конфиг ферст всегда имеет какой-то внешний абстрактный контекст и часто требует документации.
Для примера с тем же пресловутым звуком. У вас есть понятное место в коде где по логике вызывается сбор кристаллов. И вы вызываете там звук сбора кристалла. Всё явно и очевидно. Альтернативное решение без лишних зависимостей. У вас есть компонента которая в OnDisable вызывает звук по айди. Айди сериализованное поле. Вам нужно повесить на префаб кристалла эту компоненту и прописать айди соответвующего звука. И это уже некий абстрактный контракт не зафиксированный кодом.
А видос рекомендую посмотреть. Так как понимать как можно играться с архитектурой проекта полезно. И автор говорит дельные вещи. Что в конкретном примере это не критикал — это неважно. Так как когда создаешь подобные материалы трудно подобрать пример который подсвечивает все нюансы.
#новости #мнение
- 🔥 5



