Puede ser la polla lo de hacer un combate.
Como parte de los requisitos de la aplicación tenemos la transaccionalidad. En un mundo transaccional de esos, las cosas no es que estén vivas del todo. No va la cosa en tiempo real en el toma y daca de golpes. Poner un NPC (un gato zombi, por ejemplo) en ese mundo y que el usuario no se conecte en un día entero, significaría que su mascota no muera de inanición, ya que un gato puede vivir de comer una vez al día, pero si a mordiscos del otro.
Si además añadimos que otro gato, un PC, ataque, deberíamos tener las unidades de tiempo del gato anfitrión intactas por si se conecta. Añado aquí el término ese de "unidades de tiempo" o UTs. Las unidades de tiempo crecerán hasta un límite con el tiempo real. Lo que se necesita es que el usuario se conecte, al menos, una vez al día. Así que cada día tendrá ene UTs. Podemos hacer crecer las unidades hasta esa N pero no mas. Deberíamos saber cuántas UTs ha gastado en 24 horas para permitirle ese tope pero ir haciéndolas crecer porque si se conecta a las ocho de la mañana puede tener ocho y gastarlas en comer, jugar, dormir... Pero a mediodía debería tener otras cuatro con las que atacar, jugar...
Así irá entrenando, corriendo por ahí o atacaría a sus vecinos. Estamos ampliando el concepto de tamagotchi que es una máquina tonta donde sólo hay una escena, no hay vecinos ni gatos zombi.
Otro requisito es que la mayor parte o la totalidad del juego se pueda describir por configuración. Necesitamos soltar un juego terminado pero poder hacer otro en un momentajo sin importancia. El que una aplicación sea completamente configurable no es trivial como no es simple tampoco la configuración de una aplicación nueva. No es trivial el parametrizar un juego nuevo. La configuración parametrizada puede implicar el tener a alguien no sólo especializado en el código que se va a ejecutar, también debería ser un experto funcional sobre el juego y quizá esto segundo sobre todo. Mis peleas tuve sobre estos temas cuando me dio por cambiar la función distancia de la modular a la de Manhattan porque el diseñador del juego no comprendía el nuevo sistema.
Se podría entremediar con implementaciones por omisión (gracias a Spring) y hacer alguna burradilla por código cuando la configuración no de para más... Por ejemplo la algoritmia de los enfrentamientos. Imaginaos, Sicilia... Digo... Imaginemos que enfrentamos el gato a un gato zombi. Creo que sería un error de diseño el hacer que aparezcan zombis sin avisar al usuario. Sólo deberían aparecer cuando el usuario esté online, es decir, justo al ejecutar uno de sus movimientos. Hay que respetar los derechos del usuario y no podemos matar a su gato al estilo de los juegos de los ochenta en los que por un paso en falso te comían seis vidas en la siguiente pantalla (Abu Simbel). Eso ha pasado de moda, deo gratia, y ahora hay que permitir jugar por jugar. Tendremos al gato zombi dando caña al usuario y, si se le acaban las unidades de tiempo, cuando vuelva habrá recibido un par de palos pero podrá seguir mordiendo a sus anchas...
Me salí de madre. Decía un enfrentamiento. Un enfrentamiento no termina por ser una transacción configurable del todo. No es la acción "jugar" con la que el gato aprente, entrena, se cansa... Aunque también... Pero es que tiene factores externos al tamagotchi básico que son los de otro tamagotchi básico. Y quien dice otro, dice otros... La repampolla, ¿no?. No se hasta qué punto querremos hacer esto flexible pero los anidamientos que tengo vistos son tan bestiales como queh ay juegacos de este tipo por ahí en los que hay elecciones para tener un lider que es comandante en jefe de todos los ejércitos. El líder decide a quién atacar y hasta los impuestos. Tiene un poder, limitado, pero poder, sobre tus recursos (pago de impuestos) y gestiona hasta cierto punto qué se debe estudiar o fabricar en cada momento.
En un juego de ese tipo existe esta parte básica con tu tamagotchi pero luego hay esa interfaz de general y esa de jefe de estado, según uno va avanzando, que convierten el básico en uno muy complejo hecho de muchos otros o, quizá, no sea más que ejecutar unas reglas que componen otro básico pero escrito en una entidad aparte para la que habrá un juego configurable que se alimenta del anterior... La repampolla, ¿no?
PC Futbol. Aquel juegaco. Nunca me acabó de gustar, como manager yo era una mierda y como arcade el juego apestaba. Como manager el juego no deja de ser que tienes ventitantos tamagotchis para entrenar y uno aparte que es el público. Tienen sus entradas y salidas.No hay inteligencia artificial ninguna. Lo que corre el jugador, energia, regate... El público viene si hay juego, si vas bien... Quizá lo chulo de aquello, para quien le guste el temita (puaj) sería ver que los jugadores responden a cómo los entrenas y colocas en el campo. Quizá la gente que sabe del juego acabe viendo que este o el otro se cansan y hasta piden cambio o recolocan la alineación para que tengan menos área qué cubrir. Lo que estaba chulo es que se decidían las jugadas en tiempo real a partir de lo que ponías a tus tamagotchis.
Hattrick... Ese juegaco... Igual que el pcfutbol pero en modo web. Los partidos no se ven: ¡se leen!. Entrenas tus gatos y los enfrentas contra otros...
Con todo esto quiero decir que no veo que me equivoque mucho en el concepto del tamagotchi, las reglas, los enfrentamientos...
Necesito saber qué flexibilidad se tiene que tener en la ejecución de reglas. Es inevitable tener que programar los partidos, pero los entrenamientos no dejan de ser transacciones que se pueden describir como las del gato, con un coste y una ganancia en una serie de propiedades. Las propiedades y transacciones pueden ser, tranquilamente, configurables sin escribir una sóla línea de código. Se podría configurar la entidad básica, sus propiedades, niveles, etc. Pintarlos en pantalla, crear editores dinámicos...
Uy... Qué lío se puede montar...
