Unity компонентно-ориентированный подход

[Palesandr]

а не проще тогда научиться в ECS, раз столько минусов?

[OusIU]

Возможно. Про ECS слышал, пока не пробовал. Хочу попробовать разные подходы и оценить плюсы и минусы. Поэтому я не остановлюсь на одном лишь КОП.

[SadOcean]

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

[Chillingwilli]

Кому-то проще, кому-то не очень

[TubeSound]

Сложность исправления багов

это нивелирует все достонства

[OusIU]

У меня пока не возникало сложностей с исправлением. Но вполне уверен что они возникнут, когда один компонент используется +100 раз, и исправление в нем бага, повлечёт за собой создание еще 1000.

[DizzyJump]

По статье выглядит так что автор пытается изобрести вот эту штуку https://www.youtube.com/watch?v=raQ3iHhE_Kk

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

[OusIU]

Что то похожее. На опыте понял, что не получится сделать что то сложное. Буду пробовать и другое

[Ipashelovo]

К перечисленным плюсам есть определенные вопросы:
1. Удобное прототипирование? Чем это удобнее, чем 1 год класс или полностью ECS подход? В чем заключается удобство? В скорости? Если так, то как-то много бойлерплейта
2. Легкая взаимозаменяемость логики? Насколько легкая, если есть в инспекторе каша из ссылок? Если мне придется менять общую дату, то насколько сильно придется перелопачивать код? Или сколько навешивать новых компонентов? А уж если команда из 7+ человек будет одновременно ковыряться в эдиторе, то какие же там будут приключения с мерджем...
3. Слабосвязанная архитектура? Вы ссылки храните на интерфейсы? Или просто на базовые классы? А как в таком случае боретесь с превращением кодовой базы в ужас с глубоким наследованием?
4. Узкоспециализированные скрипты? И при этом в примере приводите Shoot Top Down Shooter, который и стреляет, и аудио проигрывает, и на эффекты ссылается. Возможно, я, конечно, неправильно понимаю значение этого слова, но такой скрипт-многостаночник не похож на узкоспециализированный.

[OusIU]

1)Первый пункт я не особо понял. Как говорится пояснительную бригаду. Прототипирование удобно тем, что есть уже готовые классы движения, прыжков, и прочие. Их можно быстро и легко добавить и добавить данные отдельно. Причем добавить их может даже не программист. Минусы: Удобные и готовые скрипты еще нужно написать.

2)Про дату тоже не понял. Если про данные, то они есть уже все заготовленные. И они у меня легко заменяются. Не считая подстановки любых типов.
Если слетят ссылки да, можно переписывать. С таким пока не сталкивался. Но думаю смогу легко откатится к старой версии, когда ссылки были. И в неё добавить, то что было в новой версии.
Что насчёт команды. Так как всё строится на компонентах. Где то можно использовать уже написанное. Где то дописать новое. Ну и я уже тоже вижу, что на большие проекты такой подход не рассчитан.

3) Я храню ссылки на интерфейсы. Наследование не углубляется больше чем на 2 потомка. По крайней мере пока. Стараюсь придерживается такого уровня.

4) В примере со стрельбой я показал как можно расширять возможности скрипта, не изменяя старый. Аудио тоже можно сделать как отдельный компонент (скрипт) и добавить его в список extensions. Я просто пока не вижу в этом смысла. Вполне возможно, что это понадобится сделать.

[RiSilver]

Довольно узкоспециализированный подход. Проще уж в статик переменные вынести, чем хранить их в SO и перетаскивать вручную. У вас, кстати никогда компоненты на сцене не слетали? Юнити славится нестабильной работой редактора.

[OusIU]

К счастью нет. Из интереса всегда хотел попробовать так.

Статические переменные привязываются к конкретному классу. Я же сделал через абстракцию.

Хоть и сам подход не очень. Зато я многому научился.