Як керувати залежностями між картою плитки та одиницями

У мене є 2D-стратегія, заснована на плитці. Я блукаю, як вирішити взаємозв’язок між картою та одиницями на карті.

Враховуючи координати плитки, мені потрібно мати змогу отримати одиницю, що стоїть на ній, якщо така є. У той же час, якщо мені дають одиницю, я хочу отримати координату підрозділу.

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

Другим рішенням було б лише одиниці відслідковувати свої координати. Щоб сказати, чи містить плитка одиницю, і щоб отримати цю одиницю, я пройду через весь набір одиниць одиниці, я знайду одну з відповідними координатами. Це позбавляє циклічної залежності, але воно втрачає властивість O (1), яке перше рішення мало для пошуку одиниць з карти. Це може скластись, оскільки я хочу мати змогу регулярно сканувати карту для таких речей, як пошук шляху, визначення дальності руху та пошук дійсних цілей для даної одиниці.

Я також не можу просто зберігати одиниці на карті (чи можна?). Підрозділи асоціюються з "арміями", або гравцями, або AI. Армія повинна мати можливість легко отримувати доступ до всіх своїх підрозділів і перебирати їх.

Оскільки це, як видається, є загальним питанням у стратегічних іграх, чи існують інші схеми, окрім двох, які я описав для управління взаємовідносинами одиниця / карта?

Це не популярна модель, але світ реляційних баз даних пропонує третій спосіб: використовувати структуру даних, яка має кілька клавіш. У табличній формі це може виглядати приблизно так:

Unit id    Location
-------------------
  1309     13,15
  2357      7,93
  8552      7,93

Ви хочете мати можливість запитати: "де підрозділ 2357?" і поверніться 7,93. Ви також хочете мати можливість запитати: "що там у 7,93?" і поверніться назад 2357 та 8552. Існують структури даних, які дозволяють використовувати кілька клавіш для пошуку речей. Ви можете зберігати це за межами одиниць та за межами карти, якщо ви хочете усунути залежності.

Однак на практиці частіше зберігати місцеположення в кожному блоці, а потім на стороні використовувати структуру даних просторового розподілу, яка повідомляє, які одиниці є в даній області. Оскільки це окрема структура, регіони не повинні бути просторами сітки; вони можуть бути більших площ.

Я рекомендую робити все, що найпростіше (ваше друге рішення), а потім пізніше, якщо це проблема продуктивності, ви можете додати просторовий розділ для швидшого пошуку.

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

Насправді, навіть якщо у вас було 4000 одиниць на гравця, використовуючи два цілих числа для зберігання там місця, і 8 гравців, що займає лише 2 Мб, але з першим рішенням ви отримаєте можливість скористатися координатором O (1), а не O (n) (якщо вважати несортованим), що з великою кількістю одиниць може бути повільним.

Більшість ігор здаються піксельними, а не плитковими, а зараз днями, тому їм потрібно лише придбати блок для зберігання команд.