Предотвращение циклических зависимостей при нацеливании на игровые единицы - PullRequest
0 голосов
/ 24 сентября 2018

Я работал над uml для игры, которую я сейчас разрабатываю, и немного застрял, размышляя о том, как сделать таргетинг юнитов.

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

Я хочу, чтобы некоторые отряды могли нацеливаться на другие отряды, если они находятся на определенном расстоянии.Для этого мне кажется, что мне нужно получить ссылку на другие модули в списке UnitManager и проверить, какие из них находятся в некотором диапазоне.

Вопрос: Как юнит может нацелиться на другой юнит, не имея круговой зависимости между юнитом и юнитом-менеджером (или где-либо еще)?

Заранее спасибо, Видар.

Редактировать: Некоторые примеры UML:

enter image description here enter image description here

Ответы [ 2 ]

0 голосов
/ 25 сентября 2018

Наличие двунаправленного отношения - это, конечно, круговая зависимость, но очень особый случай, который может быть принят, если рассматривать его соответствующим образом.Все другие циклические зависимости должны быть опущены, если это возможно (что не всегда так, тогда им нужно еще больше уважения, особенно при обслуживании такой системы).

Чтобы разбить циклические зависимости, доступно несколько методов по умолчанию.В основном это работает, чтобы вытащить интерфейсную часть и сделать зависимости от реализаций только для интерфейсов вместо классов.Это также дает ряд других преимуществ, таких как улучшенное повторное использование, расширяемость или тестируемость.

В данном конкретном случае я буду ссылаться на паттерн наблюдателя, предложенный как часть классических паттернов GoF.Там у вас есть (абстрактный) класс наблюдателя, который будет вашим модулем, который реализует метод, который вызывается для уведомления об обновлении.И есть предметный класс, который будет вашим классом UnitManager.Класс UnitManager знает только, то есть зависит от абстрактного класса или интерфейса наблюдателя, а не от конкретных.И каждый класс модулей, который может инициировать обновление всех других экземпляров модулей, будет зависеть от UnitManger (или когда он является следствием абстрактного суперкласса или его интерфейса).

Если вы захотите разобраться с близостью, это сильно зависит от того, как выглядит оставшийся логис и как он реализован.Основным решением будет регистрация и отмена регистрации единиц в соответствии с их расстоянием.Другой вариант заключается в том, что UnitManager вызывает только тех зарегистрированных наблюдателей, которые находятся достаточно близко.

0 голосов
/ 25 сентября 2018

В основном круговые ссылки неплохие.Им просто может понадобиться дополнительное внимание.

Вы задаете вопрос о дизайне, который определенно основан на мнении.Тем не менее, я полагаю, что должен быть контролирующий экземпляр (например, UnitManager), который имеет контроль и может управлять расстояниями между Unit с.Поэтому, вероятно, было бы неплохо реализовать здесь методы, которые могут сказать о «близости» Unit с.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...