При написании игры, вы должны делать объекты / враги / и т.д. есть уникальные идентификационные номера?

Question

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

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

Например, если у вас есть Кролик и Волк, Волк, возможно, выбрал Кролика в качестве своей цели. Что я делаю, так это то, что у волка есть GameObject Target = null;, и когда он решает, что голоден, Цель становится Кроликом. Если Кролик умирает, например, если его убил другой волк, он не может быть удален из игры должным образом, потому что этот волк все еще имеет ссылку на него.

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

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

Есть мысли по этому поводу?

Answer 1

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

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

Это, по сути, шаблон наблюдателя .

Answer 2

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

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

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

Answer 3

Вы подходите, звучит разумно, почему бы и нет? Регистрация всех ваших объектов в hashmap не должна быть слишком дорогой. Тогда вы могли бы иметь своего рода шину событий, где объекты могли бы регистрироваться для различных событий.

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

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

Answer 4

Ссылки работают только тогда, когда дизайн остается монолитным.

Во-первых, передача ссылок на другие модули (в частности, сценарии) приводит к проблемам безопасности и техническим проблемам.

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