Skip to content

Архитектура библиотеки

alt

Концепт архитектуры сверху

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

  1. Мир игры (World) - это всё пространство игры, всё что может существовать в игре. Это самая верхняя иерархия.

  2. Общество (Society) - это все взаимосвязи между персонажами и их отношение к миру. Это часть мира.

  3. Задачи игрока и ботов (PlayerJob + RobotJob -> Job) - это фоновые задачи, которые выполняют все активные персонажи в игре и котроль выполнения этих задач. Это часть общества.

  4. Бизнесс (Business) - это здания или логические точки на карте, для которых важно размещение в пространстве мира игры и контроль над ним общества. Это часть общества, но размещенная в мире.

  5. Панель (RunPanel) - это пример пользовательского интерфейса (UI), который запускает или останавливает игровое время и движение правил общества, которые изменяют мир.

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

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

Границы применимости

Если переопределить термины так:

  1. Business → AgentPoint (любая сущность, размещённая в мире и имеющая поведение)

  2. Society → InteractionSystem (система правил взаимодействия между AgentPoint)

  3. Job → Process (любой фоновый или активный процесс, изменяющий состояние мира)

  4. World → Container (контейнер всех сущностей и их состояний)

Тогда архитектура становится универсальной моделью для почти любой игры, потому что:

  1. Невозможно представить игру без сущностей в мире (AgentPoint)

  2. Если есть сущности — есть правила их взаимодействия (InteractionSystem)

  3. Если есть взаимодействия — есть процессы (Process), которые можно автоматизировать

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

Игры, где концепт лежит идеально (здесь Business — это реальные здания, Society — отношения жителей, Job — их повседневные задачи):

  1. Городские симуляторы (Cities: Skylines)

  2. Экономические стратегии (Factorio, Anno)

  3. RPG с системой поселений (Fallout 4)

  4. Симы с автономными персонажами (The Sims, RimWorld)

  5. Тактические игры (Jagged Alliance, XCOM)

Игры, где концепт нужно “натягивать”:

  1. Чистые головоломки (Portal, Tetris)

  2. Аркады (Space Invaders)

  3. Визуальные новеллы (без механик управления)

  4. Чистый аркадный шутер без экономики и ботов (Geometry Wars)

Предметно-ориентированный каркас

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

Преимущества такого подхода:

  1. Сквозная архитектура — одни и те же концепты от дизайна до кода

  2. Повторное использование — готовые системы для экономики, AI, торговли

  3. Быстрый старт — можно собрать прототип стратегии с минимальной настройкой и почти без кодирования

  4. Единая ментальная модель — дизайнеры, программисты и геймдизайнеры говорят на одном языке

  5. Расширяемость — можно добавлять новые типы Business, Job, не ломая ядро

Детализация архитектуры

alt

На этой диаграмме показаны уже классы Tac-библиотек, которые помогают реализовать представленный концепт.