AS3 MVC game: нужно ли разделять данные и правила игры в модели

Question

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

1. Группа переменных, описывающих текущее состояние игры (в них будут сеттеры, которые отправляют события при изменении, и геттеры, чтобы представление моглополучить доступ к тому, что изменилось)
2. Правила игры, определяющие, что происходит, когда контроллер получает определенный ввод (например, shoot ();) (они будут обновлять группу переменных по мере необходимости)

Представление будет считываться исключительно с 1, в то время как контроллер будет обмениваться данными исключительно с 2. Именно поэтому я делаю различие и хочу разделить их на класс 1 и класс 2.

Мои вопросы:

• Я не уверен, стоит ли проводить такое различие, поскольку я нигде его не видел.
• Если бы мне следовало;я должен сделать два отдельных класса, или я должен расширить class1 с помощью class2?
• Наконец, у меня возникают проблемы с тем, чтобы убедиться, что только class2 (а не представление) может изменять переменные в class1 (все еще будучи в состоянииотправить событие, когда значение изменяется).Есть предложения?

Answer 1

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

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

Я не кодировал игровую логику с начала восьмидесятых (в сборке 6502), поэтому я решил, что пришло время снова повеселиться. Я только что закончил сенсорную стратегическую игру, используя PureMVC и утилиту StateMachine, и должен сказать, что было забавно использовать инструменты, которые я использую ежедневно в корпоративных приложениях, для игры. Не слишком тяжелый, MVC действительно применяется, и StateMachine сделал это настолько ясным, что происходило и когда. Он был создан для BB PlayBook, но благодаря AIR вы можете проверить его, установить на рабочий стол и попробовать.

Dungeon Joe: сенсорная стратегическая игра. http://dungeonjoe.com

- = Cliff>

Answer 2

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

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

Вы также можете построить свою модель из вспомогательных классов (класса для состояния, которое создает экземпляр Observable, класса для логики и т. Д.) И создавать их как синглтоны в модели. Это, однако, не обязательно решает ваши желания по контролю доступа.

Третий вопрос связан с использованием «друзей», которые некоторые считают плохой ОО-конструкцией. Дизайнеры AS3 решили не использовать дружественные классы и методы как часть языка, такого как C ++.

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

Я бы предложил заглянуть в PureMVC. Это не идеальная структура для всех ситуаций, но она предлагает некоторые решения проблем, которые вы описываете. В этом случае ваше игровое состояние может быть сохранено / доступно в одном прокси, а логика может / будет разделена между несколькими уведомлениями и командами. Некоторые люди считают, что фреймворки ограничивают, но я считаю, что хорошо спроектированная фреймворк позволяет мне сконцентрироваться на специфике приложения, а не на том, как реализовать основное поведение.