До релиза игры остался месяц, я решил переписать ее полностью...(

Так суть тега player в том, что он висит ТОЛЬКО на одном объекте, но хорошо, если это медленнее, тогда в чем проблема передать с игрока реф на себя при посадке?

Я конечно не эксперт, и программированием занимаюсь чисто для себя, но это выглядит как оверинжиниринг для выдуманной проблемы (и как раз в таком случае при работе с командой, вместо того чтобы просто знать как работать с юнити, им приходится изучать какой-то зенжект, что по сути является проблемой)

Тут скорее проблема в том, что при использовании тегов нет "защиты от дурака". Кто то может поставить тег на две сущности, когда это не предусмотрено по программной логике. Тег может быть переименован и тогда везде в коде надо будет тоже это передергивать.

Не всегда можно просто "передать реф". Например некоторые объекты должны быть доступны на самом старте сцены. Более того. некоторые объекты могут быть необходимы для инициализации других объектов также на старте. В этот момент появляется необходимость контролировать порядок выолнения скриптов, т.к. нельзя инциализировать обьект, пока не проиницииализированы объекты от которых он уже сам зависит.

Иньекция же зависимостей это решает автоматически.

А кто-то может стереть весь код, удалить весь проект и т.д. Глупость же

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

если использовать гит, то никто кроме влаельца репозитория не сможет стереть код)

проблема передать с игрока реф на себя при посадке?

Так Зенжект по сути это и делает. Зенжект это просто реализация DI, с которым разобраться куда проще, чем делать самописный.

Поступить проще здесь, без потери в эффективности - синглтон, а он достаточно проблемный.

оверинжиниринг для выдуманной проблемы

Прокидывание зависимостей это один из главных архитектурных вопросов на юньке, насколько могу судить.

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

Ну, кстати, сейчас почти везде, даже на джунов Unity требуют уметь работать с зенжектом :D

>разобраться куда проще

Кому как, видимо

Я любые фреймворки не перевариваю, из-за них всё становится только сложнее

>Прокидывание зависимостей это один из главных архитектурных вопросов на юньке

Более точно - это решение проблемы, которую изначально можно было легко избежать

Имея пятилетний опыт в продуктовой разработке (на пхп), могу отметить, что DI используется там серьезными дядьками очень плотно, что наводит на мысль, что это один из наиболее удачных способов решения подобных проблем.