Я использовал RobotLegs для игры, которая требовала интеграции с несколькими различными бэкэнд-сервисами. Один сервис предоставил мне многопользовательскую зону лобби, позволяющую игрокам соревноваться друг с другом, один отвечал за игру лицом к лицу после вызова, а один позволял игрокам получать доступ к информации из своих учетных записей социальных сетей.
С самого начала я планировал архитектуру игры так, как если бы я создавал многофункциональное интернет-приложение. Сама игра была реализацией популярной пошаговой настольной игры. Размышления о том, как запустить локальную игру против сетевой игры, определенно помогли мне не сбиться с рамочного подхода MVC к разработке игр. Было много кода, который можно было использовать повторно, и разница между интерпретацией щелчка мышью локального игрока и получением сообщения по сети, указывающего, что удаленный игрок сделал нечто подобное, помогла мне понять, какую логику просто невозможно связать на вид вообще. Я смог очень плавно использовать модели, команды и посредники, и, в конце концов, он сделал код игры более понятным и понятным, когда я доставил его своему клиенту.
Я думаю, что в большинстве игр будет базовая модель, которая отслеживает «доску», будь то фигуры в сетке или вражеские корабли и астероиды в космосе. Как только вы представите модель как отдельную сущность от представления, вам будет проще представить, как взаимодействие игрока через мышь и клавиатуру может запускать команды контроллера для внесения изменений в модель и уведомления представления об этих изменениях. Для некоторых простых игр это может оказаться гораздо более трудоемким. Для других, например для тех, где требуется длительное обслуживание или несколько методов ввода, это может сэкономить некоторые головные боли.
Давайте на секунду подумаем о различных взглядах в игре. Представления могут включать в себя титульный экран, экран настроек / опций, многопользовательское лобби, экран рекордов / таблицы лидеров и саму основную игру (которая может состоять из множества небольших просмотров!). Многие из этих представлений могут иметь модели, такие как список рекордов, различные настройки (которые должны быть общими для экрана опций и видов игры), список игроков, ожидающих игру, и текущее состояние игры, и т.д. Кстати, нужен ли способ сохранить игру, чтобы игрок мог перезапустить с того места, где он остановился? Это проще сделать, когда данные находятся в модели и не привязаны непосредственно к представлению.
Я думаю, что слишком многие разработчики Flash смотрят на игры как на совершенно разных зверей из богатых интернет-приложений. Среда MVC может быть подходящей для игры, особенно для многопользовательской игры и для игр, которые вы собираетесь использовать в течение более длительного периода времени для добавления нового контента и функций. Самая большая проблема состоит в том, чтобы заставить себя вспомнить тот факт, что милые, маленькие пушистые зверюшки, бегущие по экрану, - это просто визуализация данных, которые могут легко отображаться по-другому с помощью DataGrid или диаграммы ... хотя это может быть не так весело играть с ними таким образом!