game_architecture.txt

Схема, включающая в себя самые важные объекты - architecture-scheme.pdf

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

1) Game.
Создается в единственном экземпляре в (main.py), затем у него вызывается метод run, который представляет из
себя цикл, в котором каждый такт перерисовывается все окно игры и обрабатываются новые действия пользователя
(нажатия мышки и клавиатуры).
Соответственно, этот объект имеет методы:
    1) render - заново отрисовать весь контент
    2) endmove - обновить свое состояние по окончании хода (внутриигрового)
    3) handle_keyup - обработать нажатие клавиши на клавиатуре
    4) handle_mouseup - обработать нажатие клавиши на мыши.
Логика интерфейса описана внутри методов 3 и 4. Для того, чтобы понимать, в каком "состоянии" взаимодействия с
интерфейсом находится пользователь, используется вспомогательный объект gamestate.
Во время создания объекта он создает и сохраняет ссылки на несколько других объектов.
2) Board. Отвечает за игровое поле и за ту часть экрана,
на котором оно расположено. Создается на стадии создания Game.
Имеет методы:
    1) render - перерисовать себя (вызывается из Game)
    2) endmove - обновить свое состояние по окончании хода (внутриигрового)
    3) серия методов, отвечающих за графику (нужно отвечать Game, в какую клетку попадает нажатие и т.д.)
3) CPanel. Отвечает за панель управления и за ту часть экрана, на котором она расположена.
Имеет методы:
    1) render - перерисовать себя (вызывается из Game)
    2) endmove - обновить свое состояние по окончании хода (внутриигрового)
    3) серия методов, отвечающих за графику (нужно отвечать Game, в какую кнопку попадает нажатие и т.д.)
4) Player. Объект, представляющий собой игрока. Создается в main.py в 3 экземплярах (2 игрока + нейтральные юниты).
Содержит данные о расе, количестве золота и т.д. Ссылки на оба обхекта хранятся в инстансе Game.
5) Rules. Содержит методы, определяющие правила изменения количества золота в конце хода, условия победы,
а также содержит некоторые константы, связанные с правилами.
Создается в конструкторе Game; Game имеет ссылку на Rules.

Основной класс динамики - Unit. Представляет собой юнита, который расположен в ровно одной клетке игрового
поля и имеет набор характеристик. В этом же классе описаны методы взаимодействий между юнитами.
Основные 2 метода - take_action(cell) в связке с able(cell). "able" проверяет, может ли юнит использовать
сейчас данную клетку как целевую для действия, а take_action делает это. Эти 2 метода используются из Game,
когда пользователь отдает соотв. юниту соотв. команду. Сначала "able" проверяет возможность, в случае если
он возвращает True - take_action приводит приказ в исполнение.
В зависимости от того, что находится в целевой клетке, вызывается move_to, act_with_ally или act_with_enemy.

Для непосредственного боевого взаимодействия юнитов используются классы, описанные в BattleActions.py.
Объекты этих классов содержат информацию о параметрах действия а также источнике и пункте назначения.
Источник (source) и пункт назначния (dest) являются обчзательными атрибутами действия, т.е. присутствуют во всех
классах (в том числе и в базовом).

Чтобы создавать юнитов, у каждого Player есть своя UnitFactory, которая по расе и голде игрока определяет,
можно ли того или иного юнита ему заказать, а также ставит новых юнитов на поле с помощью своих методов.
Фабрика использует файл units_data.json как источник характеристик юнитов.

Частью архитектуры юнитов также является их древовидная структура. У каждого юнита может быть 0 или 1 командир.
Командира можно назначить (если его нет) во время любого хода. В каждый момент времени, таким образом, юниты
обоих армий представляют собой лес корневых деревьев. Эта механика используется для изменения морали (влияет на урон).
Все методы, реализующие эту механику находятся внутри класса Unit.

Нейтральный игрок отличается от 2 пользовательских тем, что не заказывает юнитов, а они лишь генерируются в самом начале
и далее вновь не появляются. Специально для этого игрока в Player есть метод act, который вызывается (только у
нейтрального игрока!) в конце каждого хода. Для определения того, как каждый из нейтралов будет себя вести используется
класс соответствующей стратегии, описанной в NeutralsActStrategies.py. Конкретная стратегия выбрана в Config.
Генерация нейтралов также происходит с помощью одного из классов (описанного в GenerateNeutralsStrategies.py)