Bueeeno, pues va tomando forma el controlador y la separación de acciones.
El controlador procesa el click y luego pide a los manager (que serán propios de cada juego). Al final un juego presentará su modelo, su configuración sobre qué pintar y dónde y, además, sus managers con la lógica de negocio. El resto debería ser pluggable e independiente.
Resumo la interacción del controlador con los manager (que podrán ser muchos, pero vamos a suponer que es uno sin perder generalidad en el ejemplo). Procesamos un click y el manager de turno ya heredará la funcionalidad básica de almacenar en el metadata del modelo los valores de x e y y la vista sobre la que se pincha. No olvidemos que puede haber n vistas:
UIController --> manager.click()
En ese mensaje ya se almacenan en metadata los valores x, y además del nombre de la vista.
UICOntroller -> manager.onPrepareActionList()
El manager deberá procesar la lista de acciones que presenta y cambiarles el estado dependiendo de dónde se haya pinchado para ponerlas a ejecutables o no ejecutables.
UIController -> manager.getActionList()
El ui controller deberá saber iterar la lsita de managers y la lista de acciones de cada uno. Las acciones se ejecutarán una a una hasta que uan devuelva WAIT o BREAK. Las acciones se encolarán (¿apilarán mejor? digo yo que si) en bloque de forma que se pueda restaurar la ejecución anterior en caso de que se tenga que esperar por el resultado de una vista en cualquier momento. Vamos a pensar en una ejecución simple en la que no haya que esperar...
UIController <-- processActions()
UIController --> manager.executeAction()
Terminada la iteración de las acciones estaremos en espera de más comandos del usuario como al principio.
El modelo tiene una propiedad especial que se llama metadata donde va todo. No todo si no lo que es susceptible de modificación sin que, verdaderamente deba tener que afectar al modelo. Ocurre que el modelo no debiera verse afectado (según quiera el diseñador del juego) quizá hasta que termine un turno. Podríamos pensar que lo que ocurra en una de las fases de un turno no se pueda deshacer, entonces, esos cambios se deberían aplicar al modelo diréctamente. Esta es la causa de que haya un metadata.
Además se ha pensado en en el tema de los metadatas para soportar el funcionamiento de la ejecución de diálogos y que, esta, sea independiente de la lógica y del propio modelo. En el modelo habrá una pila de metadatas. EL manager podrá manejar la pila mediante un evento que enviará a los managers onPushMetadata(). De esta forma, el controlador no sabe qué hay en el modelo, sólo avisa a los managers de que quiere almacenar lo que hay ahora porque se prepara para procesar un evento sobre un evento.
Dado que el almacenamiento (de haberlo) sería FIFO (una pila de toda la vida), la llamada inicial sería inversa al volver, es decir, onPopMetadata() recorrería inversamente la lista de manager.
Cuando el controlador recibe como resultado de un action un WAIT que indica que se está esperando por una entrada de usuario, ejecutará el onPushMetadata() de todos los managers. Cuando reciba un evento (creo que ya hablé de los listeners en otro post) en el que se confirme que se ha recibido el evento esperado por los managers
NOTAMENTAL: quizá no hagan falta los listeners, aunque veremos...
decía, que cuando se reciba este evento, tras ejecutarse toda la lista de acciones o recibirse como resultado de una acción un CANCEL, se ejecutará el onPopMetadata para volver al estado anterior.
De esta manera se podrá ejecutar un diálogo sin afectar al flujo anterior al mismo.
Ahora aparte. Concretando lo que empaqueta el jar de un juego:
- datos de las unidades (el fw debería manejar la creaciñon y destrucción de las mismas a partir de estos datos) que está por ver
- managers con la lógica de negocio y de presentación. Esta última sobre una interfaz abstracta que deberá implementarse externamente al jar
- modelo del juego
- un manager concreto que sepa qué enviar y qué recibir en el caso de jugar en remoto. Debería no conocer cuál es el transporte del mensaje.
- un manager concreto que diga qué persistir de una partida, es decir, qué objetos forman parte de un savegame
La "máquina virtual" sobre la que se ejecute el juego deberá presentar implementaciones para:
- Persistencia/emisión/recepción de mensajes sobre los turnos
- Persistencia de savegames que se hará siempre de forma que se pueda explotar más tarde y me explico: no sirve de nada almacenar en un stream cuando lo interesante es poder pintar un menú con el estado acutal de las partidas. Quizá convendría estandarizar datos básicos como quién tiene turno, etc. Cosas que puedan ser útiles en pantalla.
- presentación mediante un motor abstracto representado por la interfaz View (¿granularizar las vistas? botón, menú, mapa...)
- aplicación de explotación: los savegames serán lo suficientemente interpretables y rápidamente accesibles por máquina como para que pueda haber un número n indeterminado de partidas en funcionamiento sin perjuicio del rendimiento del sistema.
Esto último permitiria que un usuario pudiese estar jugando simultáneamente varias partidas con varios jugadores y que, para conocer los datos básicos como si ya es su turno, o quién ha movido anteriormente, no tenga que pasar por cargar el juego y ver el tablero.
mmh.. valió por hoy. Han salido términos nuevos, se han detallado cosas. Es suficiente.
