Нужно больше инфы, не привязанной к терминам и теории.

Сейчас мы говорим о полностью абстрактных вещах, которые на деле могут оказаться малоприменимыми

Да, это класс-бутерброд)


Просто хочу сделать целосную архитектуру, что бы не было разбросов кода, который относится к определённой сущности по разным файлам.

Идея такова, что сущность имеет своё поведение и живёт своей жизнью. Но когда с ней  случиться то, что должно влиять на другие обьекты в игре то эти объекты должны об этом случае узнать

В видеоуроках обычно вообще не наблюдаю никакой архитектуры.
Всё сводится к куче скриптов в которых взаимодействия с игровыми объектами "розосрано" по этим самым скриптам.

Это всё же игровой движок, тут немного по другому устроено, когда только начал изучать задался тем те вопросом, «почему и зачем», но в итоге спустя какое-то время становится понятно что к чему

Обязательно прочитай мануал официальный

про скриптинг и скриптейблОбжектс

Как у вас дела с Unity IAP? У меня на андроиде иногда пишут юзеры, что non-consumable покупки не появляются на другом девайсе с тем же аккаунтом. Так же иногда пропадают non-consumable покупки.

так "разосрано" по разным это принцып единственной ответственности

Single responsibility это когда каждый несёт ответственность за конкретно самого себя, представляет с себя конкретную сущность с единой конкретной задачей.

А в сети в основном скрипты где всё в перемешку.

Тесть например имеем игровые объекты

1. Счётчик очков.
2. Препятствие.
3. Игрок.

Счётчик должен увеличиваться после прохождения препятствия игроком.

Отследить было ли пройдено препятствие можно проверив одно из его свойств.

Препятствия спавнятся скриптом спавна, а двигается - скриптом движения.

Получается мне в этом скрипте движения нужно в update проверять это самое свойство isPassed.

Допустим проверил, оно тру.
Теперь нужно, что бы счётчик увеличил своё значение.
Что бы это стало возможным то нужно, что бы он внутри своего скрипта, в методе update получил значение  свойства isPassed. А он этого сделать никаким образом не может.

Потому приходится перенносить переменную количества очков в скрипт движения препятствий и делать статической. Таким образом игровой обьект счётчика очков в своём скрипте в update берёт эту статическую переменную и обновляет свой внешний вид.

И где тут выполнения принципа SR ?  Получилась полная каша.

Я как раз к тому и стремлюсь, что бы всё было структурировано. Но у меня уже голова начинает болеть.

Не поймите как наезд, я просто хочу разобраться во всём этом и у меня пока что ничего не получается...

Спасибо. Сейчас, пожалуй, займусь мануалами.

сделай event Passed
подпиши на него счетчик очков

Где его сделать? В скрипте движения препятствий?  

Получается, что скрипт, основной задачей которого есть сценарий их движения - берёт на себя ответственность за определение того было ли препятствие пройдено.

Это уже не SR.

У меня бы все вопросы отпали увидь я пример суперпримитивного проекта с организованой правильной архитектурой. Я бы взял её за основу и не парился б

в компоненте, который отвечает за отследивание преодоления игроком препядствий

И в этом случчае ты бы увидел, что архитектура классических\веб приложений сильно отличается от оной в unity, тут свои правила

Вот из-за этого моя голова и болит. Я думал, что смогу тут сделать Mvc или mvvm но безтолку.

Вот выше человек написал, что для отслеживания прохождения препятствий должна быть отдельная компонента. Логично вроде. Но, а если игра наберёт масштаб и на сцене будет полторы сотни подобных компонентов. Ими всеми должен управлять какой-то менеджер. С этой целью я и пытался реализовать синглтон с observer.

а если не будет?)

лучше решать проблемы по мере поступления, темболее новый движок

первый раз когда я трогал юнити я на него и забил потому что не смог применить свой богатый опыт проектирования приложений