Pull to refresh
15
0

Game developer

Send message
Извените, но вы не поняли принцып. Таким же аргументом было бы писать код прыжка в менеджере сцены. Actor-ы и Command-ы — это способ инкапсулировать от юнита код прыжка. Тоесть в самом юните кода прыжка быть не должно. В случае с Actor-ами менеджер вызывает метод на юните, а юнит вызывает метод в Actor-е и он уже проделывает всю работу. В случае с Command менеджер цеплчет команду на юнита и она все делает. В любом случае сам юнит не содержит в себе кода прыжка и не знает как он прыгнет. И это дает легкий способ заставить гнома порхать как бабочка не меняя код в самом юните а просто прицепив на него подшодящую компоненту или запустив правильную команду.
Вы сейчас говорите о том что команды могут вызываться из многих мест или я не понял про увеличение точек входа? В таком случае можно и публичный метод юнита вызывать из разных мест, но обычно это делает менеджер сцены, например.
Конечно команду можно сделать и не MonoBehaviour, но удобнее держать команду на объекте из-за одтладки (в любой момент видно что исполняется на контролере). Плюс для отслеживания коллизий или триггеров команда на объекте не будет нуждаться в дополнительных event-ах от контроллера.
При использовании SendMessage возникает сильная привязка к названию метода и при этом пропадает легкий способ отследить что и откуда вызывается. К примеру Вы случайно опечатались при названии метода, эта ошибка перешла в Ваши SendMessage, и если кто-нибудь исправит ошибку в названии метода, то сломает логику программы и долго никто не будет понимать почему.
Суть статьи — показать подход, который позволяет динамически изменять поведение при этом остается легким для понимания и изменения. Особенно хорошо ощущается легкость изменения при работе над проектом в команде — для внесения нового функционала достаточно будет написать команду и не перелопачивать класс вникая в зависимости оставленные там кем-либо. Это касается чего-угодно в Вашей игре, будь то юнит (каст заклинания), окружение (изменение погоды) либо сам игровой процесс (показать обучение).
Вы правы, здесь чувствуется функциональный стиль.
А что за проекты позволите поинтересоваться? Интересен контекст, в котором используется подобное решение.

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

Да, но я не делаю для этого дженерики.
зачастую напрягает не столько объем выделяемой памяти, сколько сам факт её выделения (GC Pressure)

Заметно будет только в очень исключительных ситуациях. Мобильные игры не на столько большие, чтобы одновременно исполнялось больше 100-а команд, и запускаться в таких количествах они тоже вряд ли будут.
Это просто дело привычки, ничего больше
Спасибо за комментарий, приятно слышать.
По поводу AddComponent я действительно забыл, и я пока не думал как решить это. Пока это не вызывало проблем с производительностью, хотя проекты, с которыми я сейчас работаю, целиком построены на использовании команд.
Типизированные аргументы — хороший вариант для рассмотрения, хотя если мне надо передавать больше 2-х параметров, то я просто пишу кастомную структуру привязанную к команде и мне не приходиться запоминать порядок.
И по-поводу callback-ов, я тоже могу только сказать, что это значительно удобнее чем event-ы а памяти на них выделяется не так уж и много. Чаще из-за текстур и моделей по памяти не помещаются и в таких случаях оптимизация callbeck-ов не поможет.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity