Dificultad con la implementación del layout MVC (juego iOS)

Empecé a desarrollar una aplicación para iPhone simple, pero estuve completamente estancado por unos días. Este es mi primer progtwig que haré fuera de las classs de CS, por lo que es innecesario decir que es 20 veces más grande que cualquier otra cosa que haya hecho. Tengo una buena idea de las prácticas básicas de OO y los patrones más simples, pero estoy luchando para crear un buen Modelo-Ver-Controlador. Posiblemente podría implementar una aplicación de procedimiento y estrechamente acoplado, pero me gustaría usar buenas prácticas de OO. Quiero evitar usar el patrón Singleton.

Entiendo el outlook general, pero me siento confundido cuando trato de concentrarme en su implementación real.

Hasta ahora tengo (no estoy usando el atm API exacto como UIView):

Una class GameModel con variables de instancia Player * player, Player * dealer y Deck * gameDeck. Los methods son: (void) dealCardtoPlayer, – (Player *) getPlayer (para que la vista / controller pueda usar la reference para get puntuaciones fácilmente), etc … Las classs de Player tienen información como mano y puntaje. Esto es en realidad una implementación de un protocolo, por lo que puedo utilizar un patrón de estado si lo necesito.

Una class de GameController . Contiene references a GameModel y GameView. Eso es todo lo que puedo averiguar. Si alguien hace clic en un button de acceso en el GameView, ¿el método de ese button simplemente llama a un método hitPressed en el controller que luego llama al método GameModel – (void) dealCardtoPlayer: (Tarjeta *) de la tarjeta superior? ¿El controller sondea constantemente el model para determinar si el jugador perdió o el model registra el controller como un observador y lo actualiza?

Clase GameView . Contiene references a GameModel y GameController (ya que envía inputs al controller). ¿Esto simplemente llama a algo como getPlayerHand en el model 60 veces / segundo hasta que encuentre que se agregó una tarjeta a la mano y luego la renderiza? ¿Cómo se manejará la animation? ¿Tendrían la vista sus propios elementos de tarjeta ya representados y los transformarían (para dar cabida a la nueva tarjeta) una vez que detectara una nueva tarjeta en la mano del jugador y luego mostrara la nueva? Siento que debería hacer un patrón de estado para esto también. Creo que también leí en algún lugar que los datos de animation están almacenados en el model, pero no estoy seguro de cómo hacerlo.

Otras preguntas aleatorias: ¿la IA usa la misma reference de controller exacta que el jugador y envía su input simulada al controller? También quiero implementar el multijugador más adelante.

También me preguntaba cómo se implementan algo así como un menu principal y un menu de pausa. ¿Utilizaré algún controller maestro que controle dos MVC o simplemente cambie las vistas en el mismo GameController? Mi primera idea era que el controller tendría un método menuButtonPressed que asignaría una reference de vista diferente (escribe sobre la vista existente y se borra y desasigna cuando se reanuda el juego para que veas el anterior). Si quiero usar el mismo motor para hacer un desplazamiento lateral, ¿cómo funcionarán juntos dos controlleres (sé que la detección de colisiones usualmente tiene su propio controller)?

Siempre aprendo mejor con el ejemplo: busqué en Google, pero me faltan algunas gems ocultas o no puedo encontrar la información que necesito.

Pregunta principal: ¿Hay que leer tutoriales en profundidad o grandes libros sobre cómo implementar realmente el layout de juegos de OO / MVC?

Pido disculpas por la avalancha de preguntas largas, pero realmente siento que no puedo rodearme con las complejidades de los MVC. Siento que esta aplicación tardará meses en get algo básico en ejecución (una vez que las classs comiencen de nuevo) …

¡Bienvenido al mundo real! MVC es una buena teoría, pero rara vez se ajusta a la práctica, especialmente en Objective-C / iOs donde la interfaz de usuario es la queue que menea al perro.

Es mucho más importante gastar su esfuerzo en una buena estructura, de lo contrario, no incluya funciones no relacionadas en la misma class, no extienda partes de una function entre una docena de classs, etc.

Y es posible que haya mordido más de lo que puede masticar con su juego. Pero a veces eso es bueno para aprender.

El sondeo es una mierda. Algunas personas sugieren una interfaz entre el Modelo y el Controlador que permite que el controller escuche los events en el model y el model para desencadenar los events. De esta forma, el Modelo no interactúa con ningún código que también interactúa con la vista, por lo que desacopla el layout. Sin embargo, no te metas demasiado en seguir a MVC al pie de la letra. Solo intente hacer su código de manera que sea fácil cambiar la Vista para otra Vista (por ejemplo, si desea convertir su juego a un juego basado en la web). Si el código cumple con ese criterio, es un buen layout de MVC.