Как MVVM для игр?

В частности, для игр 2d и, в частности, игр silverlight/wpf.

Если вы думаете об этом, вы можете разделить игровой объект на его представление (графическое изображение на экране) и модель/модель представления (состояние, ai и другие данные для объекта). В silverlight обычно кажется, что каждый объект управляет пользователем, помещая модель и просматривая ее в один объект. Я полагаю, что преимущество этого - простота. Но, возможно, он менее чист или имеет некоторые недостатки с точки зрения основного "игрового движка".

Что вы думаете по этому поводу? Каковы некоторые преимущества и недостатки использования шаблона MVVM для разработки игры? Как насчет производительности? Все мысли приветствуются.

Ответы

Ответ 1

Одним словом - отлично!

На самом деле Джош Смит только что опубликовал книгу о MVVM, используя игру в качестве своего объяснительного приложения. Рекомендуем вам прочитать Уорда Белла превосходную (и бесплатную) критику в работе Джоша.

Ответ 2

Вы можете столкнуться с проблемами производительности, поскольку MVVM обычно приводит к большому количеству функций привязки данных в WPF для обеспечения чистого разделения. Однако это все еще отличная идея и стоит преследовать; вы всегда можете профилировать приложение позже и оптимизировать определенные элементы, если вам нужно. Скорее всего, это будет ИИ, а не интеграция пользовательского интерфейса.

Что касается определения, где делить модель | Просмотреть модель | View, мне нравится использовать следующий подход:

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

  • Я пытаюсь создать Модели представления для каждого основного компонента интерфейса. Например, если вы создавали RPG, у вас могут быть InventoryViewModel, CharacterStatsViewModel, WorldMapViewModel и т.д. Обычно я не создаю их для отдельных элементов управления/виджетов (например, индикаторы работоспособности, глифы элементов или знаки "+" ) если они не имеют достаточно сложного интерфейса.

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