Комментарии 12
а не проще тогда научиться в ECS, раз столько минусов?
Возможно. Про ECS слышал, пока не пробовал. Хочу попробовать разные подходы и оценить плюсы и минусы. Поэтому я не остановлюсь на одном лишь КОП.
ECS позволяет организационно выстрелить себе в ногу столькими способами, что такой наивный компонентный подход не факт что хуже.
Кому-то проще, кому-то не очень
Сложность исправления багов
это нивелирует все достонства
По статье выглядит так что автор пытается изобрести вот эту штуку https://www.youtube.com/watch?v=raQ3iHhE_Kk
Не сказал бы что такой подход дюже популярен, но простые игры на нём делать дейсвительно можно.
К перечисленным плюсам есть определенные вопросы:
1. Удобное прототипирование? Чем это удобнее, чем 1 год класс или полностью ECS подход? В чем заключается удобство? В скорости? Если так, то как-то много бойлерплейта
2. Легкая взаимозаменяемость логики? Насколько легкая, если есть в инспекторе каша из ссылок? Если мне придется менять общую дату, то насколько сильно придется перелопачивать код? Или сколько навешивать новых компонентов? А уж если команда из 7+ человек будет одновременно ковыряться в эдиторе, то какие же там будут приключения с мерджем...
3. Слабосвязанная архитектура? Вы ссылки храните на интерфейсы? Или просто на базовые классы? А как в таком случае боретесь с превращением кодовой базы в ужас с глубоким наследованием?
4. Узкоспециализированные скрипты? И при этом в примере приводите Shoot Top Down Shooter, который и стреляет, и аудио проигрывает, и на эффекты ссылается. Возможно, я, конечно, неправильно понимаю значение этого слова, но такой скрипт-многостаночник не похож на узкоспециализированный.
1)Первый пункт я не особо понял. Как говорится пояснительную бригаду. Прототипирование удобно тем, что есть уже готовые классы движения, прыжков, и прочие. Их можно быстро и легко добавить и добавить данные отдельно. Причем добавить их может даже не программист. Минусы: Удобные и готовые скрипты еще нужно написать.
2)Про дату тоже не понял. Если про данные, то они есть уже все заготовленные. И они у меня легко заменяются. Не считая подстановки любых типов.
Если слетят ссылки да, можно переписывать. С таким пока не сталкивался. Но думаю смогу легко откатится к старой версии, когда ссылки были. И в неё добавить, то что было в новой версии.
Что насчёт команды. Так как всё строится на компонентах. Где то можно использовать уже написанное. Где то дописать новое. Ну и я уже тоже вижу, что на большие проекты такой подход не рассчитан.
3) Я храню ссылки на интерфейсы. Наследование не углубляется больше чем на 2 потомка. По крайней мере пока. Стараюсь придерживается такого уровня.
4) В примере со стрельбой я показал как можно расширять возможности скрипта, не изменяя старый. Аудио тоже можно сделать как отдельный компонент (скрипт) и добавить его в список extensions. Я просто пока не вижу в этом смысла. Вполне возможно, что это понадобится сделать.
Довольно узкоспециализированный подход. Проще уж в статик переменные вынести, чем хранить их в SO и перетаскивать вручную. У вас, кстати никогда компоненты на сцене не слетали? Юнити славится нестабильной работой редактора.
Unity компонентно-ориентированный подход