Más problemas. discutiendo conmigo mismo, acabo de ver que no es sólo el problema de pintar el estado del juego si no que hay que añadir el estado de la interfaz. El estado de la interfaz depende de la lógica que controla los turnos. Mmmh... a ver si me explico, en un juego en el que hay varios pasos por cada turno, se tendrán acciones que se puedan o no realizar a ciertos elementos de la interfaz dependiendo si estamos moviendo piezas, atacando con una, etc. vaya jodienda.
De todo esto debiera dar cuenta el controlador, el modelo debería almacenar el estado de la interfaz. Además el estado de la interfaz dependerá de la ficha seleccionada, por ejemplo. A ver si con un ejemplo lo pongo más claro. Volvemos al Advance Wars o Colonization.
Al principio de un turno se presenta el tablero y el usuario puede seleccionar cualquier casilla del mismo. El seleccionar una casilla vacía actualizará una vista en pantalla que muestra la información del terreno. Esto no haría cambiar el modelo salvo que también queramos almacenar la casilla seleccionada por si acaso la necesitamos.
Según lo veo, se debería almacenar porque de ello dependen las acciones posibles a realizar por parte del usuario. Seguimos con el ejemplo.
El usuario pincha sobre una casilla ocupada. Si está ocupada por una pieza enemiga, además de la info del terreno, se presentará la info de la unidad pero no se podrá realizar ninguna acción. Están saliendo conceptos que intentaré desarrollar después. Si pincha sobre una pieza propia aparecería la info del terreno, la info de la pieza y las acciones que se pueden hacer sobre la misma. De mano podría mover y /o atacar si es que tiene una pieza enemiga en rango.
Esto todo lo estoy jodiendo de mala manera porque creo que estoy llegando a las mismas conclusiones que la vez anterior y me estoy perdiendo por el mismo derrotero... Pero es que lo veo así.
Voy a ver probando con otro tipo de juego, un juego de cartas tipo siete y media. Tendríamos el tapete con las cartas que tenemos, el mazo y las del otro.
Al comienzo del juego tenemos una carta boca abajo y apostamos a lo que tenemos. Entonces hay reparto y apuestas hasta que todos pasen, o se pasen salvo uno que será quien gane.
Entonces un turno consiste en tomar carta y apostar, son dos pasos. Además el tomar carta se puede hacer o no, dependiendo de si estás subjetivamente cerca de las siete y media.
Empieza el juego, la primera apuesta es automática, el duro de apertura de toda la vida. Además con ese duro ya viene una carta. Es un turno especial porque no se ha podido elegir. La interfaz cambia y permite apostar o pasar. Son las acciones permitidas. No haría falta pinchar sobre nada. Estas acciones ya vienen en el turno. Sería similar a "Fin de turno" de cualquier juego de tablero como Colonization cuando consideras que ya has movido o te gusta cómo está la cosa actualmente. Esta acción está activa siempre.
Si pasas pierdes todos los turnos hasta fin de juego. Si apuestas subes tanto. El siguiente puede pasar o verlo, nunca apostar menos. Siguiente turno, acciones permitidas "¿Carta? si/no". Je. Este sería un paso del turno ya que el turno completo requiere apostar.
Creo que funcionaría.
Para separarlo por comunicación en red, habría que verlo como turnos distintos porque el resto de jugadores tiene que ver las apuestas para seguir. Serían dos turnos de naturaleza distinta. Pero turnos.
¿Y tres en raya? sólo hay una acción permitida por turno y es en cualquier casilla libre. En las demás nada. Si sólo hay una acción permitida se ejecutará.
Entonces tenemos nuevos conceptos:
- Acciones permitidas,
- Vistas descriptivas que no son el tablero en sí como, quizá, cuánta pasta cuesta apostar si pinchas sí, qué terreno pisamos...
Con esto tenemos ya un flujo algo distinto de eventos que podrían separarse en MVC
V-> click
C->comprueba y actualiza la lista de acciones disponibles para el click, modifica el modelo con esa info
C->provoca que las vistas se actualicen a partir del modelo
V->se actualiza con nueva info
Mmmh... hay que ver el flujo de un turno complejo y cómo simplificar la implementación del controlador. Seguimos pensanding...
