Как правильно спроектировать «космический корабль»?

Question

[Георгий Пелагейкин]

Здравствуйте, это снова я. Есть космический корабль. Класс Ship. В нем лежит массив отсеков корабля. Класс Hardpoint. В каждом отсеке может быть установлено оборудование. Там такая схема - IEquipment - базовый абстрактный класс, определяет общие параметры вроде массы, размеров и т.д. Наследники IEquipment - типы оборудования, Generator, Engine и т.д. Ну и их экземпляры, лежащие в отсеках - конкретные модели этого оборудования.
Проблема в их действии. Простой пример - двигатель определяет скорость корабля (физика, прости). Соответственно чтобы внешние скрипты (движения в данном случае) узнавали скорость корабля пришлось разместить свойство Speed в главном классе (Ship), которое проходит по всем двигателям на корабле и считывает результирующую скорость с них. Проблема в том, что по ходу разработки добавляется множество новых свойств и все это висит в Ship. Это нормально или это плохая архитектура и нормальные люди делают все по другому? В общем, прошу гуру проанализировать это и вынести вердикт.

Comments

[Георгий Пелагейкин]

Было предложено вот такое решение проблемы разрастания класса корабля:
В базовом классе оборудования разместить метод Active(Ship ship), который будет считать действие для данного оборудования, реализовывать в наследниках. И в классе корабля разместить только переменные - ту же скорость, например. Когда кому-то нужна, например, скорость, запускается проход по всему оборудованию и выполняется их метод Active, обновляются перемнные. Ну не знаю, лично мне кажется это не очень хорошее решение - в классе корабля все равно куча переменных, лишние сложности, постоянный пересчет, проблема неопределенности - результат активности прибора может зависеть от другого, а оно может быть еще не пересчитано.

Answer 1

[Евгений]

Используй систему статов. Например у тебя есть класс

enum StatType {
   speed;
   power;
   mobility;
}

class StatManager {
    // Выставляет начальное значение стата
    void setStateBase(StatType type, float value);
   // Добавляет новый модификатор для стата
    void addStatModf(StatType type, StatModf modf);
    // Удаляет модификатор стата
    void removeStatModf(StatType type, StatModf modf);
    
    // Возвращает значение стата со всеми повешенными на него StatModf 
    Float getStateValue(StatType type);
}

enum StatModfType {
   set;
   add;
   mult;
}

class StatModf {
   var StatModfType type; // как именно модификатор влияет
   var Float value;  // значение с которым он влияет
}

При выполнении getStateValue перебирай все модификаторы для этого стата на базовое значение.
Рекомендую применять модификаторы в порядке их типа (StatModfType) вначале set потом mult, потом add а не в порядке добавления. Тут самый простой вариант предложен, подумай и переработай под свои нужны.

Comments

[Георгий Пелагейкин]

Спасибо, хорошая пища для размышлений.

Answer 2

[Руслан Роскошный]

Точно так же делаю. Не запариваюсь. Только Hardpoint назван Module xD
Хинт: Можно кэшировать сумму показателей и пересчитывать только при поломке отсека/оборудования, либо при смене отсека/оборудования.

Answer 3

[Vitaly Sivkov]

Можно сделать подсистемы для модулей, типа:
- двигательные установки;
- оружие;
- корпус (броня, щиты и т.д.);
- электроника.
А в коде уже можно обращаться к этим подсистемам в виде ship.drive.getSpeed()
И интерфейс корабля будет меньше загроможден, и архитектура будет более гибкой.

Comments

[Георгий Пелагейкин]

Да, пожалуй это лучше чем список свойств в корабле, спасибо.

Answer 4

[Алексей Елецкий]

Вам нужно ознакомиться с компонентным подходом к архитектуре:

habrahabr.ru/company/wargaming/blog/245321
https://www.youtube.com/watch?v=1zLqgQ_-F84

Comments

[Георгий Пелагейкин]

Да, пишу на юнити, там КОП. Может... каждый слот представить компонентом юнити и повесить на объект игрока... хотя что это мне даст?