¿Model Play-Controller funciona bien con inteligencia artificial y árboles de comportamiento?

Question

Vengo de un fondo MVC (Flex and Rails) y me encantan las ideas de separación de códigos, reutilización, encapsulado, etc. Hace que sea fácil construir cosas rápidamente y reutilizar componentes en otros proyectos. Sin embargo, ha sido muy difícil seguir los principios de MVC al intentar crear aplicaciones animadas complejas, impulsadas por el estado y asincrónicas.

Estoy tratando de create animated transitions between many nested views in an application, y me hizo pensar si me estaba engañando o no ... ¿Se puede aplicar los principios de MVC a los principios de la Inteligencia Artificial (Árboles de Comportamiento, Máquinas de Estado Jerárquicas, Estados Anidados), ¿me gustan los juegos? ¿Esas dos disciplinas juegan muy bien juntas?

Es muy fácil mantener las vistas/gráficos ignorantes de cualquier cosa fuera de ellos cuando las cosas son estáticas, como con un sistema HTML CMS o lo que sea. Pero cuando comienzas a agregar transiciones complejas impulsadas por el estado, parece que todo necesita saber sobre todo lo demás, y el MVC casi se interpone en el camino. ¿Qué piensas?

Actualización:

Un ejemplo. Bueno, ahora mismo estoy trabajando en un sitio web en Flex. Llegué a la conclusión de que para animar correctamente cada elemento anidado en la aplicación, tengo que pensar en ellos como Agentes de IA. Cada "Vista", entonces, tiene su propio Árbol de Comportamiento. Es decir, realiza una acción (se muestra y se oculta) según el contexto (cuáles son los datos seleccionados, etc.). Para hacer eso, necesito una cosa tipo ViewController, la llamo una Presentadora. Así que tengo una Vista (los gráficos presentados en MXML), un Presentador (que define las animaciones y acciones que la Vista puede tomar en función del estado y los estados anidados de la aplicación) y un Modelo de Presentación para presentar los datos a la Vista (a través del presentador). También tengo Modelos para objetos de valor y Controladores para manejar URLs y llamadas a bases de datos, etc ... todas las cosas normales de MVC estáticas/html.

Por un tiempo intenté descubrir cómo estructurar estos "agentes" para que pudieran responder a su contexto circundante (lo que se seleccionó, etc.). Parecía que todo necesitaba estar al tanto de todo lo demás. Y luego leí acerca de una Ruta/Tabla/Lista de navegación para juegos e inmediatamente pensé que tenían una tabla almacenada centralmente de todas las acciones precalculadas que cada agente puede tomar. Eso me hizo preguntarme cómo estructuran realmente su código.

Todas las cosas de los videojuegos en 3D son un gran secreto, y gran parte de lo que veo se hace con una interfaz gráfica de usuario/editor, como la definición de árboles de comportamiento. Así que me pregunto si usan algún tipo de MVC para estructurar cómo responden sus agentes al entorno y cómo mantienen su código modular y encapsulado.

Answer 1

"¿Se puede aplicar los principios de la MVC para principios de Inteligencia Artificial (Comportamiento-árboles, jerárquica Estado Máquinas, anidada Unidos), al igual que los juegos?"

Por supuesto. 99.9% de la IA está puramente en el Modelo. El controlador le envía las entradas, la vista es cómo lo representa en la pantalla para el usuario.

Ahora, si quiere comenzar a tener algo de control de IA, puede terminar anidando los conceptos, y su "modelo" de juego contiene un Modelo para una entidad, un Controlador para la entidad que envía los comandos de envío de IA a y una Vista para la entidad que representa las percepciones de esa entidad con las que el Controlador puede trabajar. Pero eso es un problema aparte de si puede 'jugar bien'. MVC se trata de separar la presentación y la entrada de la lógica y el estado y a ese aspecto no le importa cómo se ve la lógica y el estado.

Answer 2

Tenga esto en cuenta: Las cosas que necesitan reaccionar simplemente tienen que ser conscientes de las cosas que necesitan para reaccionar. Entonces, si necesitan saber todo, entonces necesitan saberlo todo. De lo contrario, ¿cómo los haces conscientes? En las cosas de los videojuegos en 3D, dicen los tiradores en primera persona, los enemigos reaccionan ante el sonido y la vista (pasos/disparos y usted/cuerpos muertos, por ejemplo). Tenga en cuenta que indiqué una base abstracta y partes del árbol de decisión.

Puede ser incorrecto en su caso específico separar todo entre varios agentes, y más simple dejarlo en manos de un agente principal que puede delegar órdenes en procesos separados (/ comenzar a balbucear): cada vista podría ser un proceso que el agente principal podría indicarle que pase a una (cantidad de) vistas, según los datos que haya recibido el agente principal.

Espero que ayude ..Tomar todo con un grano de sal :)

Answer 3

Parece que necesita hacer un mayor uso del patrón Observer/Event Aggregator. Si varios componentes necesitan reaccionar a eventos de aplicación arbitrarios sin introducir un acoplamiento indebido, entonces usar un agregador de eventos lo ayudará. Ejemplo: cuando se selecciona un elemento, se publica un evento de aplicación, los controladores relevantes dicen su vista para ejecutar animaciones, etc. Los diferentes componentes no son conscientes de los demás, solo escuchan los eventos comunes.

Además, el código que hace que la vista haga cosas (inicia animación dependiendo del estado del modelo/controlador) - eso es parte de la Vista, por lo que no tiene que hacer que su arquitectura sea rara teniendo un controlador y un controlador . Si se trata de un código específico de UI, entonces es parte de la vista. No estoy familiarizado con Flex, pero en WPF/Silverlight, cosas como esas irían al código subyacente (aunque en su mayor parte Visual State Manager es más que suficiente para manejar animaciones de estado para que pueda mantener todo en XAML) .