Які переваги використання системи ідентифікатора юридичної особи?

Зараз я читаю книгу Гра програмування AI за прикладом.

У книзі згадується присвоєння унікальних ідентифікаційних номерів кожній суті в грі. Часто, коли суб'єкту А потрібно звертатися до об'єкта B , A отримує посилання на B , надсилаючи ідентифікаційний номер B до класу EntityDatabase . Цей клас отримує ідентифікаційні номери та повертає посилання на сутності.

Ідентифікаційні номери деяких об'єктів також можуть бути отримані з файлу, що містить ідентифікатори деяких сутностей (основних персонажів гри).

Моє запитання: навіщо мені це робити? Чому я не можу працювати безпосередньо з посиланнями? Чи іноді важко отримати прямий довідник? Чи використання системи ідентифікації є загальним підходом? Чи є ігри, які не використовують ідентифікатори?

Я новачок у розробці ігор. Поясніть, будь ласка, переваги роботи із системою ідентифікації особи. Переваги та недоліки. Конкретні приклади були б чудовими. Дякую

architecture

— Авів Кон
джерело

Довідники добре працюють у багатьох ситуаціях. Однак є три важливі ситуації, в яких посилання не спрацюють:

Мережі . При надсиланні інформації про синхронізацію стану об'єктів по мережі посилання використовувати не можна. Вам потрібно буде певним чином визначити сутність, щоб віддалені машини знали, про кого ви говорите.
Збереження / завантаження . Зберігаючи стан вашої гри на диску, посилання на об'єкти не можуть із цим поширюватися. Це означає, що коли ви завантажуєте штат, суб'єкт A, на який було спрямовано об'єкт B за допомогою посилання, вже не знає, на кого слід націлити. Місця пам'яті різні, об'єкти - різні.
Управління пам'яттю . Центральне місце для зберігання посилань означає, що при видаленні об'єкта вам не доведеться проходити всі ваші сутності та видаляти посилання на нього, щоб очистити пам'ять. Посилання повинні використовуватися лише за потреби, а потім видалятися в будь-якому іншому об'єкті. Зменшення кількості посилань гарантує, що у вас немає об'єктів зомбі, на які посилається лише остання річ, з якою вони взаємоділи, або інша особа. Це також допомагає уникнути нульових посилань зі стандартизованим способом тестування, якщо організація все ще існує.

— MichaelHouse
джерело

останній абзац повинен бути власною точкою кулі (управління пам'яттю). Бувають ситуації, коли одному класу протягом певного часу потрібна посилання на іншу сутність, але посилання на сутність може стати недійсною (тобто, загинуло цільове ціле). Повертаючи NULL при запиті суб'єкта за ідентифікатором, кожен клас бере на себе відповідальність зробити правильну справу (а не збій), коли посилання на сутність стає недійсною.

— LearnCocos2D

Дякую за відповідь. Питання для уточнення. Загалом: У ситуаціях, коли суб'єкту А потрібно отримати посилання на сутність B (для того, щоб напасти на нього, надіслати йому повідомлення, перевірити зіткнення з ним чи взагалі будь-яку іншу причину) - Чи слід використовувати систему ідентифікаторів для того, щоб отримаєте це, чи іноді добре отримати посилання безпосередньо? Значення: Чи повинен суб'єкт A завжди отримувати посилання від EntityManager, надсилаючи йому ідентифікатор об'єкта B (який перехресних посилань-посилань суб'єкта та ідентифікаційних номерів), і лише потім звертатися до об'єкта B, використовуючи посилання від EntityManager? Чи слід завжди використовувати систему ідентифікаторів?

— Авів Кон

Або іноді добре отримати посилання безпосередньо? Іншими словами, коли я повинен створити EntityManager EntityManager для отримання посилання, що зберігається всередині нього, і коли сутність A може отримати посилання на B будь-якими способами?

— Авів Кон

На це немає реальної правильної відповіді. Особисто я б спроектував, що система сутності не залежить від логіки гри. Це означає, що логіка гри навіть не має доступу до прямих посилань сутності. По суті, я б уникнув збереження будь-яких посилань на суб'єкт господарювання, що виходять за межі місцевого рівня поточного методу. Це означає використовувати EntityManager кожен раз, перш ніж працювати з компонентами об'єкта.

— MichaelHouse

Я бачу. Дозвольте скористатись прикладом, щоб зрозуміти, чи розумію ви, що ви маєте на увазі. Скажімо, я використовую рівномірну сітку для виявлення зіткнень. Сітка - це 2d масив. Кожна сутність перевіряється на зіткнення лише з сутностями, що знаходяться в одній «клітинці» в сітці. Використовуючи "регулярний" підхід, кожна комірка міститиме посилання на об'єкти GameEntity в області, яку вона представляє. Використовуючи підхід "система ідентифікаторів", кожна комірка міститиме ідентифікаційні номери сутностей. Ці номери будуть надіслані EntityManager для отримання конкретних посилань для виявлення зіткнення. Це добре розуміння?

— Авів Кон

Останнє - це те, що якщо ви використовуєте шаблон об'єктного пулу і суб'єкт буде скинутий через те, що істота загинула (наприклад) і поновлюється десь в іншому місці, посилання все одно вказуватиме на ту саму суть (помилка) і ідентифікатор більше не залишатиметься дійсний.

ID 5067 вказує на адресу 0x8765 помирає істота, а інший породжує новий ідентифікатор істоти до 7073 Хтось перевіряє ID 5067, він вказує на 0x8765, але ця історія тепер зареєстрована з ідентифікатором 7073, тому база даних ідентифікаторів особи знає, що ви використовували застарілий ідентифікатор і повідомляє вас, істота, яку ви намагалися досягти, більше не активна.

Це та всі чудові причини, про які згадував Byte56, - це те, що це хороший дизайн, щоб уникнути використання посилань безпосередньо.

— AturSams
джерело