Модель-представление-контроллер хорошо играет с деревьями искусственного интеллекта и поведения?

Question

Я родом из MVC (Flex и Rails) и мне нравятся идеи разделения кода, возможности повторного использования, инкапсуляции и т. Д. Это позволяет легко создавать вещи и повторно использовать компоненты в других проектах. Однако при создании сложных асинхронных анимированных приложений, управляемых состоянием, было очень трудно придерживаться принципов MVC.

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

Очень просто сохранять представления / графику в неведении о чем-то вне их самих, когда все статично, например, в системе HTML CMS или чем-то еще. Но когда вы начинаете добавлять сложные переходы, управляемые состоянием, кажется, что обо всем остальном нужно знать, и MVC почти мешает. Что ты думаешь?

Обновление:

Пример. Ну, сейчас я работаю над сайтом во Flex. Я пришел к выводу, что для правильной анимации каждого вложенного элемента в приложении я должен думать о них как об агентах ИИ. Таким образом, каждое «представление» имеет свое собственное дерево поведения. То есть он выполняет действие (показывает и скрывает себя) на основе контекста (что представляют собой выбранные данные и т. Д.). Для этого мне нужна вещь типа ViewController, я называю ее Presenter. Таким образом, у меня есть View (графика, выложенная в MXML), Presenter (определяющий анимации и действия, которые View может выполнять на основе состояния и вложенных состояний приложения), и модель Presentation для представления данных в View ( через ведущего). У меня также есть Модели для объектов-значений и Контроллеры для обработки URL-адресов, вызовов базы данных и т. Д. ... все обычные статические / html-подобные вещи MVC.

Некоторое время там я пытался выяснить, как структурировать этих «агентов» так, чтобы они могли реагировать на окружающий их контекст (что выбрано и т. Д.). Казалось, что все нужно знать обо всем остальном. А потом я прочитал о Path / Navigation Table / List для игр и сразу подумал, что у них есть централизованно хранящаяся таблица всех предварительно рассчитанных действий, которые может выполнить каждый агент. Так что меня удивило, как они на самом деле структурируют свой код.

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

Answer 1

«Можете ли вы применить принципы MVC к принципы из искусственного Интеллект (деревья поведения, Иерархические государственные машины, вложенные Штаты), как Игры? "

Конечно. 99,9% ИИ чисто в модели. Контроллер отправляет входные данные на него, а представление - это то, как вы представляете его на экране пользователю.

Теперь, если вы хотите, чтобы ИИ что-то управлял, вы можете в итоге вложить понятия, и ваша «модель» игры содержит Модель для сущности, Контроллер для сущности, который ИИ посылает ему команды. и Представление для сущности, которое представляет восприятие этой сущности, с которой может работать Контроллер. Но это отдельная проблема от того, может ли она «играть красиво». MVC - это разделение представления и ввода от логики и состояния, и этому аспекту все равно, как выглядит логика и состояние.

Answer 2

Похоже, вам нужно больше использовать шаблон Observer / Event Aggregator. Если нескольким компонентам нужно реагировать на произвольные события приложения, не вводя чрезмерную связь, то использование агрегатора событий поможет вам. Пример: когда элемент выбран, публикуется событие приложения, соответствующие контроллеры сообщают своему представлению о запуске анимации и т. Д. Различные компоненты не знают о других, они просто прослушивают общие события.

Кроме того, код, который заставляет представление работать (запускает анимацию в зависимости от состояния модели / контроллера) - это часть самого View, поэтому вам не нужно делать свою архитектуру странной, имея контроллер и viewcontroller. Если это специфичный для пользовательского интерфейса код, то это часть представления. Я не знаком с Flex, но в WPF / Silverlight подобные вещи будут включены в код (хотя большей частью Visual State Manager более чем достаточно для работы с анимациями состояний, чтобы вы могли сохранить все в XAML) ,

Answer 3

Имейте это в виду: вещи, на которые нужно реагировать, просто должны осознавать вещи, на которые они должны реагировать.Поэтому, если им нужно знать обо всем, тогда им нужно знать обо всем.В противном случае, как вы их информируете?В 3D видеоиграх, например, в шутерах от первого лица, враги реагируют на звук и зрение (например, шаги / выстрелы и вы / мертвые тела).Обратите внимание, что я указал абстрактную основу и части дерева решений.

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

Надеюсь, что это поможет .. Возьми все с зерном соли:)