mmog II

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...

Con todo a medias. mmorg I

Sin tiempo para aburrirse... Cagonlaputa...

Bueno, vamos a ver, vamos a aclarar conceptos.

Primero: Lo mio a medias.

Segundo: Puede que empecemos a desarrollar un encargo serio,  firme y facturable para hacer un MMORPG para navegadores y dispositivos móviles. La cosa no es complicada, es un tamagotchi gordo pero se complica por los requisitos pedidos... Jeje. Estoy a punto de cumplir un año en la empresa, uno en Santander, ¡Quién lo diría!  ¡Cómo vuela el tiempo! ¡Qué tiempo perdido!

A ver si me aclaro a mi mismo, esto de escribir suele ayudar.

Se me ocurrió dando un paseo hoy a mediodía que eso de hacer un mmorpg de estos de matar zombises o de esos otros de construir naves, no deja de ser un tamagotchi gordote, Al menos en lo tocante al manejo de tus propios recursos.

En un tamagotchi convencional tienes un personaje con cuatro o cinco variables (no mas, en serio) que lo hacen particular. Pongamos que hacemos un tamagotchi gato. Un gato tendrá: estado de ánimo, edad, personalidad, peso, agilidad y cansancio.

En pantalla o en el paratín, tendremos pocos botones, seleccionar opciones y ejecutar. Acciones hay muy pocas, normalmente menos que propiedades. Por simplificar podemos poner tres o cuatro: limpiar, acariciar, alimentar, jugar. Además hay un añadido que es el paso del tiempo. Las unidades de tiempo nos dan igual con tal de saber cuántas hay desde que hace una comida hasta que muere por inanición, aunque eso también es variable pero variable en función de otras cosas. Mh... Más bien sería cuántas unidades pasan hasta que tiene hambre... Y, complicándolo mas: cuántas pasan si está en reposo o cuántas si está jugando.

Ocurre que, igual que el usuario puede ejecutar acciones sobre el bichejo, también puede el tiempo. Habrá un segundo actor que será el paso del tiempo. Con el tiempo se ejecutarán acciones casi contrapuestas a las que pide el usuario. En función del tiempo pasado se deberán ejecutar estas acciones:
envejecer
tenerHambre
cansar
ensuciar
muscular
aprender

Todas esas funciones, al igual que las que provoca el usuario se alimentan de una o más variables y las hacen crecer o menguar según se describa la acción. Unos ejemplos:
jugar (provocada por el usuario): hace crecer el hambre, aumenta el cansancio, disminuye el peso, sube la agilidad y cambia la personalidad a más amigable

tenerHambre (provocada por el tiempo, hay que distinguir el pasar un tiempo con hambre de tener hambre por cansancio de jugar con el usuario): disminuye el peso, disminuye la agilidad, cambia la personalidad a más arisco.

Lo jodido es ponderar todo esto. Porque los gatos envejecen:
envejecer: aumenta la agilidad hasta ser adulto, luego va disminuyendo paulatinamente, va siendo más arisco. En función de personalidad, agilidad, peso, hambre el gato debería rondar los 10-14 años y morir.

Las fórmulas de ponderación pueden ser la coña marinera pero lo básico es tener claro qué aumenta y qué disminuye.

Voy a echar una pensada a cómo un gato se puede pelear con otro. Nota mental: Es fundamental que se haya pasado la vida jugando para saber pelear. Habrá que añadir algo al aprendizaje. Pero esto no nos afecta porque un mmorpg es un juego tonto donde el entrenamiento es una variable más a tener en cuenta.