¿SpriteKit sigue el patrón MVC?

Actualmente estoy trabajando en un proyecto de iOS llamado Old Frank que he estado tratando de seguir un patrón de diseño MVC.

La esencia de esto es.

GameObjects(model) <- Scene(controller) -> Sprites "SpriteKit" (View)

Ahora, si entiendo MVC correctamente, no puede usar muchas de las funciones que SpriteKit tiene para ofrecer si desea seguir MVC. Por ejemplo SKAction, detección de colisión, etc.

¿No depende del modelo donde se encuentran los objetos del juego y cómo deben reaccionar al tocar otros objetos? ¿No depende del modelo determinar la ubicación a lo largo del tiempo?

¿Hay alguna parte de SpriteKit que se considere aceptable usar como "vista" en MVC que no sea el renderizado?

— Skyler Lauren
fuente

"He estado tratando de seguir un patrón de diseño MVC", ¿por qué?

— Paul D. Waite

@ PaulD.Waite Me gusta la idea de mantener mi modelo separado. En teoría, esto hace que sea más fácil portar o recrear en otra plataforma. También hace que sea mucho más fácil manejar la persistencia, que ha sido la razón más importante hasta ahora.

— Skyler Lauren

Gotcha Para lograr el objetivo de persistencia, el patrón de recuerdo podría ser más aplicable que MVC. Tus sprites podrían ser los originadores, y tendrían la responsabilidad de producir una representación de su estado que se pueda guardar y restablecerse de esa representación más adelante. Su controlador de escena podría ser lo que les solicita la representación.

— Paul D. Waite

Eso también podría resultar en que tus juegos guardados se puedan usar en otra plataforma, aunque sospecho que eso es lo más lejos que puedes llegar en términos de capacidad de puerto cuando trabajas con un marco solo para Mac / iOS como SpriteKit.

— Paul D. Waite

@ PaulD.Waite gracias por sus comentarios. Veré el patrón de recuerdo como otro patrón a tener en cuenta en el futuro. Las dos preguntas son sobre el mismo proyecto, pero no están relacionadas. Sorprendido de ver que el otro fue migrado a stackoverflow y analizará su respuesta más tarde esta noche =)

— Skyler Lauren

Respuestas:

Tu pregunta es buena. He tenido exactamente la misma pregunta con respecto a SpriteKit y he estado muy confundido acerca de la falta de información en la web sobre esto. SpriteKit parece alentarlo a poner todo su código de Modelo-Vista-Controlador en la misma clase (su subclase SKScene), lo cual es realmente confuso para mí. ¿Cómo construirías un juego de alguna complejidad usando esa técnica? Combinar el estado del juego (puntaje, numLives, etc.), con un código de controlador como touchesBegan / Ended, y ver renderizado en la misma clase se vuelve realmente difícil de manejar más allá de los juegos más simples.

Estoy de acuerdo en que usar el patrón de recuerdo para ayudar con la persistencia es una buena idea, pero también creo que cambiar a un diseño MVC podría ser beneficioso. Actualmente estoy moviendo mi juego a una arquitectura MVC. Mi enfoque actual es que mi modelo (objetos del juego) administre los cuerpos físicos, la subclase SKScene actúe como controlador y una clase separada que actúe como la vista para configurar y representar los aspectos visuales de SKNodes en la escena. Estoy a mitad del proceso, así que no puedo decir con certeza si este será un buen diseño, pero parece que será mucho mejor que tener una subclase de 10,000 líneas de SKScene.

— John Cleveland
fuente

Gracias por tu respuesta / comentario. Parece que siente que el uso de las características de SpriteKit tampoco sigue el patrón de diseño MVC. No dude en enviarme un correo electrónico skyler@skymistdevelopment.com si tiene alguna pregunta sobre cómo "yo" estoy usando MVC o si desea obtener más detalles sobre cómo "usted" está usando MVC con SpriteKit =)

— Skyler Lauren

No hay nada que te obligue a poner la mayor parte de tu código en la clase SKScene. De hecho, descubro que cuando utilizo SpriteKit, la mayor parte de la lógica recae en los nodos de forma mucho más natural que la escena, ya que los nodos son la peor parte de SpriteKit. La escena es poco más que el "controlador" para manejar la actualización y la entrada de su árbol de nodos. Aunque el modelo "MVC" todavía no coincide con SpriteKit, ya que los nodos tienden a ser la "M" y la "V".

— Attackfarm

En términos simples, un diseño común en los juegos SpriteKit son escenas, capas, nodos y nodos secundarios.

Puede convertir cada parte en una clase discreta que encapsule todas las partes, propiedades y métodos.

Por ejemplo, una clase de fondo que tiene imágenes en capas, partículas, varias propiedades como la velocidad con la que se debe mover cada capa y métodos públicos para comenzar y detener el desplazamiento del fondo.

En este diseño, reúne estas clases discretas que hacen su propio trabajo en la escena, que en su mayoría maneja actualizaciones en ejecución: física, eventos táctiles, etc.

— Jeremy
fuente