Смешанный компонентный дизайн и модельный вид (-контроллер)

Question

Разработка 2D-игры, и я хочу отделить игровой движок от графики. Я решил использовать модельный шаблон вида следующим образом: игровой движок владеет объектами игры (EnemyModel, BulletModel, ExplosionModel), которые реализуют интерфейсы (Enemy, Bullet, Explosion).

View принимает события при создании сущностей, получая указатель на интерфейс: таким образом View может использовать только методы интерфейса (т. Е. Запрашивать информацию для выполнения чертежа) и не может изменять состояние объекта. В представлении есть свои onw-классы (EnemyView, BulletView, ExplosionView), которые владеют указателями на интерфейсы. (Существует также шаблон, основанный на событии, так что Модель может уведомить об изменении сущности, поскольку метод чистого запроса является неприменимым, но я не буду обсуждать его здесь).

* В классах моделей используется компонентный компонент компиляции: они используют библиотеку boost :: fusion для хранения различных компонентов состояния, таких как PositionComponent, HealthComponent и т. Д.

В настоящий момент View не осведомлен о конструкции на основе компонентов, а только о части модели: чтобы получить позицию врага, он вызывает метод Enemy :: get_xy(). EnemyModel, который реализует интерфейс, перенаправляет этот вызов в PositionComponent и возвращает результат.

Поскольку у пули тоже есть позиция, я должен добавить метод get_xy в Bullet. BulletModel использует ту же реализацию, что и класс EnemyModel (т. Е. Перенаправляет вызов).

Этот аспект затем приводит к тому, что у него много дублирующего кода: интерфейсы имеют много похожих методов и * классы моделей полны форвардных методов.

Так что я в основном два варианта:

1) разоблачить дизайн, основанный compoment так, что каждый компонент имеет интерфейс, а также: взгляд может использовать этот интерфейс для прямого запроса компонента. Он сохраняет раздел «Вид» и «Модель» разделенными только на уровне компонента вместо уровня сущности.

2) Отклонитесь от части обзора модели и перейдите на чистый компонентный дизайн: вид - это только компонент (часть RenderableComponent), которая имеет в основном полный доступ к движку игры.

Основываясь на вашем опыте, какой подход был бы лучше всего?

Answer 1

Я дам свои два цента. Из проблемы, которую вы описываете, мне кажется, что вам нужен абстрактный класс, который будет выполнять операции, которые являются общими для всех ваших классов (например, get_xy, которые должны применяться к пуле, врагу, взрыву и т. Д.). Этот класс является игровым объектом, который выполняет основную работу. Наследование классов может переопределить его, если они захотят.

Этот абстрактный класс должен быть ядром всех ваших интерфейсов (к счастью, вы находитесь на C++, где нет физического различия между классом и абстрактным классом и интерфейсом). Таким образом, представления будут знать о конкретных интерфейсах и все еще иметь общие методы сущностей.

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

В любом случае, разоблачение внутренней структуры классов моделей не является хорошей идеей. Скажите, вы хотите заменить boost другим? Вам придется переписать всю программу, а не только соответствующие части.

Answer 2

MVC не так-то просто для игр, когда игра становится больше (в том числе меню, врагов, уровней, GUI ...) и переходов, она сломается.

Компонент или Сущность-система очень хороши для игр.

В качестве более простого случая для вас вы можете использовать HMVC. У вас все еще будут проблемы с переходами, но по крайней мере ваш код будет сгруппирован более чистым образом. Вы, вероятно, хотите, чтобы код вашего танкера (рендеринг и логика) приближался.

Answer 3

Были представлены архитектуры презентаций, разработанные специально для агентских систем, таких как Presentation-Abstraction-Control. Трудная часть в разработке такой системы заключается в том, что вы в конечном итоге завершаете последовательность взаимодействия между агентами.

Вы можете сделать это, но не используйте OO-наследование для моделирования иерархии передачи сообщений. Вы будете сожалеть об этом. Если вы думаете об этом, вы действительно не заинтересованы в использовании отношения наследования OO, поскольку определенные интерфейсы - это просто «запись функций», на которые объект может ответить. В этом случае вам лучше формально моделировать ваш протокол связи.

Если у вас есть вопросы, пожалуйста, спросите - это не очевидное решение и легко ошибиться.