Web Analytics

Turnos VI

Seguimos filosofanding... Vale más pensar que picar código. Si hubiese hecho esto la otra vez, tendría un framework completo ahora mismo.

La idea original era soltar un framework ligero, fácil de aprender y con una implementación básica lista para ejecutar juegos, ya me preocuparía de intentar rentabilizarlo de alguna manera (que ya está pensada, programada y con algún bug que otro). El framework se soltaría al público aunque una parte (no la más importante a mi entender) no.

Bien, vaso vertical con la apertura hacia arriba.

Bien... Bien... Bien...

Nos olvidábamos de la inteligencia artificial. No tengo ni puta idea de cómo programar esas cosas salvo que se pueda decidir en un tris el siguiente paso. He estado leyendo modelos de juegos. De hecho había pensado implementar uno sencillo al que jugaba en el colegio. La sola estrategia de ese juego ha dado para capítulos y capítulos de libros. Por sencillo que parezca. El juego debería incluir un módulo que implemente la IA. Además, este módulo debería manejar el juego como un usuario normal, es decir, generar clicks y demás eventos. No olvidemos que cuando juegan las tribus en el Civilization, aparecen los diálogos en los ataques y toda la pesca. El anular el diálogo debería hacerlo un usuario humano, la IA no debería poder tocar los diálogos pero si, por ejemplo, el minimapa, es decir: ve el modelo completo, ve que tiene que atacar con una unidad, desplazaría el mapa hasta ese punto (para que el usuario real vea que va a mover una pieza allí), selecciona la pieza, ataca, se pinta el diálogo con el resultado del ataque y el usuario (real) deberá cancelar el diálogo para que el otro siga pensanding.

Quizá se pueda lanzar la ejecución de la IA como si fuese otro manager. Soltará su lista de acciones. Esto me hace pensar en los resultados de las acciones. Una acción debería poder repeetirse hasta que se cumpla una condición. Así podría implementarse un recorrido por todas las fichas de un jugador para decidir cuál es la mejor jugada y en la siguiente acción, ejecutarla y finalizar el turno. NOTA MENTAL: TBEActionResult.REPEAT

Volvemos a un juego básico de ejemplo:

Por ahí se llama dots and squares, nosotros siempre lo llamamos "el de los cuadros". Es un juego para dos o más jugadores, que se juega en papel y con bolígrafos o lápices de distinto color. Recuerdo que, los días de huelga, jugábamos con un folio completo y luego había peleas por contar y recontar los resultados. El tablero es como sigue:

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

O O O O O O O O O O O

Llenanding el folio era mucho más gordo. La mecánica es como sigue:
por turnos, cada jugador, marca una línea de un círculo a otro. La línea sólo puede ser horizontal o vertical. Cuando un jugador completa un cuadro:
O-O
|  Y  |
O-O

Pone su inicial en el centro o lo rellena con su color y puede volver a marcar. Al terminar, se cuenta y pista.

Para jugar dos, lo que hacíamos era anular un cuadro de una esquina y, así, no había posibilidad de empates. Al jugar tres da igual, uno va a tener mas. que los otros dos.

Al pensar si esto encaja con lo que llevo pensado hasta ahora estuve bloqueado un rato porque, carajo, no tenía pensado que se pudiera pinchar en las esquinas de los escaques... Y le dí vueltas como un tonto hasta que me di cuenta de que cada círculo y cada ralla puede ir en un escaque del tablero. Sólo habría que comprobar cuáles se pueden seleccionar:
- si ya está pintado, no se puede seleccionar
- para un Y cero o par se pueden seleccionar los X impares
- para un Y impar se pueden seleccionar los X pares
- X e Y empiezan en 0

Sin perder generalidad y sin que esto impida que se puedan poner tableros enormemente grandes y luego hacer un scroll chulo para ir hasta otra parte a pinchar en otra celda. Preferiría que los tableros fuesen cuadrados. El mínimo debería ser... Hay que echar cálculos:

Ocurre que las pantallas de los móviles suelen cumplir un ratio de 1.25, esto es, que el alto es 1.25 * ancho, esto en pixels y en tamaño real. Uno muy común es 800x640. Poniendo a escaques cuadrados y sabiendo que habría que pintar unos 3 por cada cuadro, tendríamos:
O O O O O O O O O O
y sobra un tile poniendo 32 pixels por imagen. Así que, tablero básico de 19x19 con 10 círculos por fila y por columna.

Más diagramas de colaboración.

Imaginemos, Sicilia... Bueno. Volvemos.
Imaginemos que funciona la cosa esa del controlador y del manager. Habría por ahí un manager que pueda enviar por red mediante el transporte X que sea (este de los ceros se podría jugar hasta por sms ahora que bajan las tarifas. PERO no tengo muy claro si eso se adapta al resto de managers... No querría complicar el tema con muchos más eventos de los que ya hay.