MVC-подобная компартментализация в играх? [закрыто]

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

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

Распространен ли этот вид разделения в играх? Должен ли я попытаться сломать вещи дальше? Могу ли я пропустить осложнения?

Настольная игра - хороший пример игры, которая может быть сделана с использованием MVC, поскольку игровая логика (модель) существует совершенно независимо от визуальных эффектов (вид). Однако, если вы рассматриваете экшн-игру, подобную Gears of War, геометрия 3D-моделей является неотъемлемой частью игровой логики, поэтому разделение вида, как если бы оно было взаимозаменяемо, становится бессмысленным. Unity3D - отличный пример более специфичного для игры способа организации кода. У вас есть базовый класс сущностей, к которому вы добавляете функциональность с компонентами, где один компонент может обрабатывать рисование сущности, другой - игровую логику и т. Д. Посмотрите эти известные посты в блоге на эту тему:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

Мой взгляд на это:

• Модель , где большинство лжи данных и вся логика происходит.
  Он читает очередь входных событий и соответственно изменяет состояние игры.
  Затем он обрабатывает такие вещи, как физика и другие основные компоненты, которые также обновляют состояние игры.
  Loop. Это все.
  Цель состоит в том, чтобы сделать модель независимой: она не имеет никакой зависимости от вида или элементов контроллера: вы должны быть в состоянии создать программу, которая запускает только модель.
• Вид просто читает игру состояние модели, обновляет свои собственные компоненты , посвященные представление данных, а также отображать вещи на экране.
  Он никогда ничего не записывает в модель, это процесс только для чтения, за исключением, может быть, регистрации какого-либо обработчика событий (например, «Эй, мистер Модель», когда вы обнаруживаете коллизию между этими двумя объектами, пожалуйста, вызовите мой обработчик событий, который воспроизводит звук!) «).
• Контроллер ловит событие ввода и передает их в очередь ввода модели. Он читает представление (это нажатие кнопки происходило на кнопке пользовательского интерфейса?).

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

Не забывайте обновлять модель с постоянной скоростью (фиксированный шаг по времени), а представление и контроллер выполняйте как можно быстрее (но не слишком сильно).

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

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