No es que quiera pegar estos pensamientos a una tecnología en particular, pero no está de más centrar la finalidad del proyecto para acotarlo de algún modo. La idea no es hacer el DooM entero y ejecutarlo a ver qué pasa. Hacer un cliente capaz de ejecutar pequeñas lógicas de negocio para descartar eventos de usuario y un servidor que sincronice partidas es ya un trabajo suficientemente grande para una persona. Añadir capas a esta estructura o ampliar esta lógica de negocio sería lo mismo que construir una aplicación sobre un buen framework en el que cada acción de usuario se pueda implementar independientemente. Añadir datos al modelo incluso nuevas reglas de negocio…
Sobre nuevas reglas de negocio, vamos a centrarnos ya en Android. Android es lo que quiero que implemente el primer cliente de la aplicación. Sin quitar que luego haya cliente web o lo que venga. Al tener una aplicación desplegada en un aparato con android, se puede actualizar esta arbitrariamente cuando el desarrollador quiera dentro del Market. Una pega bastante gorda de esto es que el cliente tiene que tener la voluntad de actualizarla porque debe activar él mismo la descarga e instalación de la nueva versión.
Quisiera poder esquivar este tema. Las acciones de usuario deberían tener consecuencias distintas según el modo de juego, incluso si se me apura, poder cambiar dinámicamente. Habría que tener un cliente lo suficientemente inteligente como para decir que no se puede mover una ficha del juego de damas en vertical u horizontal. Se me ocurre flexibilizarlo aun más y poder, desde el servidor, introducir nuevas modalidades de juego de damas distintas a las que yo conozco. Los ingleses juegan con las damas (cuando son damas y se le da vuelta a la ficha que por el otro lado les ponen una cruz negra) con un tipo de movimiento particular, pueden mover en cualquier dirección (incluso vertical u horizontal) pero de uno en uno.
Esto de flexibilizar las reglas de juego no es un problema en sí, se podría anunciar una actualización y decir al cliente que si no se actualiza no podrá jugar a las damas a la inglesa… Pero preferiría que si se actualiza el cliente sea por corregir bugs o añadir algún tipo de funcionalidad que, de veras, no se pueda desde el servidor. Además este nuevo requisito se une al depender en dos aplicaciones (cliente y servidor) de un cambio que se podría dar en una.
Me lleva a pensar esto en distribuir la computación y hacer que el cliente pida “permiso” al servidor para mover de a3 a a4 en un juego de damas. Esto usaría red. Un defecto de los informáticos es que pensamos en el usuario y en sus aparatos. Al programar para una consola portatil se pausa de vez en vez la cpu o los sistemas de sonido mientras no se vayan a usar para ahorrar batería. Parece mentira, pero como usuario te acabas dando cuenta de qué juegos o aplicaciones se comen la batería y cuales no. Así que vamos a descartar eso de tirar la énergia y usar la red sólo cuando se necesite.
Esto del ahorro nos descarta de un juego en tiempo real aunque también es posible algún tipo de juego que ya he pensado en el que los eventos de usuario sean bastante espaciados. Al final, lo que me interesa es hacer un juego por turnos que sea “atemporal” no que exista por siempre si no que se pueda jugar en cualquier momento, incluso flexibilizar los turnos para limitarlos a un tiempo o no tipo civilization.
Como soy medio masoca pa todo esto, lo que más me pone es preparar estas milongas que hay por debajo.
Vamos a hacer un proxy del servidor. El proxy deberá contener la lógica de negocio que decida qué acciones son permitidas al usuario y cuales no. Es absurdo preguntar al servidor cuando el usuario pincha sobre una casilla en blanco. En un cliente Ajax ni siquiera se generaría un evento javascript para esa celda del mapa. Pues un cliente algo listo, debería detener la ejecución antes de pedir por red al servidor que le describa qué mostrar o qué hacer. Parte o toda la lógica de negocio podría almacenarse en scripts o en clases que se puedan servir al cliente (ya me estoy limitando a una tecnología), al menos aquella lógica que diga qué eventos del usuario superan el ámbito del cliente y tienen que pasar como un comando al servidor: Al final de un turno, por ejemplo, el cliente no debería haber contactado con el servidor para nada y entonces enviar un lote de acciones que gestionar de las que ha hecho el usuario. En un juego como el poker llegarían todas las cartas que ha tirado el usuario al final de su turno pero no de una en una sino en un solo comando.
El proxy del cliente actuará como si ya se han movido sus fichas y podrá ver el tablero actualizado con sus movimientos incluso deshacerlos antes de terminar su turno salvo que las reglas no permitan deshacer… “Carta en la mesa” o como se diga en cada sitio.
Evento: será un gesto del usuario ante la interfaz que se le presenta o cualquier tarea repetitiva o programada que desencadene una acción contra la aplicación, cosas del tipo un click de usuario, arrastrar, o un timer que haga el tick de una animación.
Accion: un evento pasará a ser una acción cuando la lógica de negocio tenga que responder a él bien sea cambiando la vista, el modelo o comunicando cualquier cosa a un posible servidor de la aplicación.
Proxy: Un proxy es una representación de un objeto que no esxiste realmente como tal o que es un modelo sobre el modelo. Explico esto diciendo que si se centraliza un servidor con toda la lógica de negocio, por ejemplo, es bastante absurdo para un cliente que no sea tonto (osea que haya que programar cierta lógica en el cliente) el tener que consultar qué hacer con un click del usuario o con un tick de las animaciones. Ver proxy pattern en wikipedia o donde sea.
Comando: Una acción pasa a ser un comando cuando modifica un proxy o el modelo.
Continuará...
