Как можно организовать код для игры, чтобы соответствовать шаблону MVC?

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

Если это изменит то, как он выглядит без изменения основных данных, то это в представлении. Если это данные, которые могут быть просмотрены во многих отношениях, это модель. И если это то, как вы играете, то это контроль.

Итак, если вы рисуете "топор" с двумя лезвиями или одним, это вид. Если это сколько хит-пойнтов повредить вам нанесите топором, это модель. И если вы качаете топор, набрав "s" или щелкнув правой кнопкой мыши, это контроль.

Я чувствую с вами я помню, когда я впервые обнаружил MVC я пытался втиснуть все в него. Я действительно сделал игру, которая использовала шаблон MVC. Однако позже я обнаружил, что то, что я сделал, было излишним. Я пытался вписать почти каждый класс, который я сделал в одну категорию в MVC.

то, что я предлагаю, это прочитать "шаблоны проектирования" бандой из четырех человек. Есть много полезных шаблонов, кроме MVC. Иногда вообще нет смысла использовать MVC. Специально для игры я не уверен, что MVC-это хорошая идея. Причина в том, что вы не хотите отображать игровой объект различными способами (видами), но вы хотите повторно использовать код рисунка для различных типов игровых объектов.

для моего собственного 2D игрового движка я использовал стратегия картина довольно активно. Игровые объекты, такие как игрок и монстры, которых я назвал Спрайт. Я позволил рисунку спрайта обрабатываться шаблон стратегии. Вот тогда я и позвонил спрайт.draw () Я бы сделал что-то вроде этого:

class Sprite {
  void draw() {
    this.view.draw(this.currentPosition, this.currentOrientation);
  }

  Point  currentPosition;    // Current position of this sprite
  double currentOrientation; // Facing angle of sprite
};

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

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

class Sprite {
  void setUpdateAction(Action action) {
    this.updateAction = action;
  }

  void update(double start_time, double delta_time)
  {
    this.prevPosition = position();  
    advance(delta_time); // Advance to next position based on current speed and orientation

    this.updateAction.execute(this, start_time, delta_time);
  }

  Action updateAction;
};

есть множество вариантов этого. В моей текущей реализации я даже выделил currentPosition,скорость,ориентация и advance () в отдельный объект, называемый MotionState. Это так я могу постройте деревья поиска возможных положений и ориентаций при выполнении алгоритмов поиска пути. Тогда я не хочу носить с собой информацию о том, как вести себя каждое обновление или как спрайт должен быть нарисован.

концепции MVC централизации логики взаимодействия с пользователем является хорошей моделью для разработки игр.

Я немного поработал с разработкой флеш-игр. здесь это статья о пулах объектов во Flash. Концепция является кросс-платформенной и может дать вам некоторые идеи.

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

существует множество способов организации кода - одним из вариантов может быть написание класса GameManager как Одноэлементного. Все игровые объекты привязываются к нему для управления и взаимодействия с пользователем. GameManager обрабатывает все вводимые пользователем данные и отправляет сообщения в пул объектов. Вы можете использовать интерфейсы для определения общих шаблонов связи между игровыми объектами и GameManager.

насколько оптимизация производительности идет, резьба очень мощная. Асинхронная работа может гарантировать, что вы не тратите эти драгоценные циклы.

все ваши слушатели и обработчики должны войти в класс контроллера, состояние объектов на экране (например, положение, цвет и т. д.) должен быть частью ваших классов моделей, и любой код, который рисует вещи на экране, будет частью представления.

мой образ мышления MVC - это MDUC
Модель
Дисплей
Контроллер пользовательского ввода

модель содержит объекты модели домена
На экране отображается текущее состояние и поведение объектов модели домена.
Контроллер пользовательского ввода обрабатывает все пользовательские входы.

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

Как только вы видите, что вы разделяете данные и операции модели от отображения, от входных данных пользователя, легче увидеть, где группировать то, что в вашем собственном коде.