Introducción

Hola, soy Kevin, en internet me presento como Keviinplz por una talla en el liceo hace ya unos 15 años.

Llevo varios meses buscando algún proyecto personal en qué invertir mi tiempo, y siempre termino pensando en las ganas que me darían de jugar cara de caca de manera online con amigos. Algo así como aquellos tiempos en los que uno pasaba el tiempo en TeamSpeak / Discord jugando.

Le he dado varias vueltas a como programar cara de caca, de hecho hice unos dos o tres avances pero, sin una ruta clara, termino abandonando el proceso.

Voy a decir la típica frase “ahora si que si”, pero realmente creo que ahora si tengo bien definido que hacer para darle con este proyecto.

Voy a forzarme (xd) a hacer bitácoras cada vez que avance con este proyecto, de tal forma de recordar que estaba intentando hacer y un poco para escribirme a mi mismo desde el pasado.

Pensaré quizás, si saco este proyecto al público y se hace popular, de subir estas bitácoras. Trataré de que sean lo más reales posibles en el sentido de que, si me siento perdido o picado con mis avances, las bitácoras puedan reflejar eso.

¿Por qué quiero hacer eso?, creo que, personalmente, me servirá mucho para evaluar mi proceso de desarrollo y de nuevo, si hago esto público, espero desmitificar bastante el cómo uno construye proyectos. Un proceso que, por lo general, es bastante sufrido y lleno de dudas, y espero que eso ayude a alguien a motivarse a incursionar en un proyecto, sabiendo que es completamente normal llegar a ese momento en el uno cree que está haciendo puras weas y quiere abandonar.

A esa persona desde ya le digo, he abandonado esto unas 3 o 4 veces, y aquí estoy, soy porfiado, pero bueno.

Esta es mi primera bitácora, así que les contaré sobre este juego y qué tengo pensado para desarrollarlo.

¿Qué es cara de caca?

No tengo idea de donde salió el juego. Hay blogs que mencionan su origen en Chile, y puta, yo le creo.

Pero bueno, respondamos la pregunta.

Cara de caca es un juego por turnos.

El objetivo es quedarse sin cartas, siendo la última persona sin cartas la que pierde, o el “cara de caca”.

El juego tiene tres grandes fases: Preparación, Juego y Termino.

Preparación

En esta fase, cada jugador recibe 9 cartas distribuidas en 3 grupos:

• Mano: Lo típico, cartas en tu mano y que solo tu puedes ver.
• Públicas: Estas se ponen boca arriba en la mesa, todos los jugadores las pueden ver.
• Escondidas: Se ponen bajo las cartas que pusiste boca arriba donde la particularidad es que, nadie, ni siquiera tu, puede ver qué cartas son.

Ejemplo de como se vería la mesa para un jugador

Una vez recibidas tus cartas, puedes intercambiar las cartas de tu mano con las cartas públicas. No puedes tocar las cartas escondidas. No puedes intercambiar cartas con otros jugadores. Siempre tienes que tener 3 cartas en tu mano, y 3 cartas públicas antes de iniciar el juego.

Una vez que todos los jugadores terminaron de intercambiar, entonces se comienza a jugar.

Juego

Este es un ejemplo de como se vería la mesa para cuatro jugadores, ya te puedes hacer la idea con menos o más jugadores.

Los turnos del juego van en el sentido de las agujas del reloj (derecha) y parte el jugador de la derecha de quien repartió (en realidad da lo mismo, queda a criterio de tu grupo).

El orden de las cartas (de menor a mayor) es 2, 3, 4, 5, 6, 7, 8, 9, 10, J, K, Q, A (me estoy reservando el Joker a propósito, sigue leyendo).

Ya bacán, pero… ¿Cómo se juega?

El jugador tiene que lanzar una carta de su mano que sea mayor o igual a la última carta jugada. Evidentemente si no hay cartas en la mesa, el jugador puede lanzar cualquiera de su mano.

En caso de que el jugador no tenga una carta mayor o igual, se lleva a su mano todas las cartas acumuladas hasta el momento.

Si ese no fue tu destino y si tenías una carta para jugar, entonces para finalizar tu turno tienes que robar una carta para volver a completar 3 en tu mano.

Puedes lanzar más de una carta, siempre y cuando sean del mismo valor. Por ejemplo, en tu turno puedes tirar dos cartas “3”, o tres cartas “Q”.

Si hay tres cartas acumuladas del mismo valor y tu tiras una cuarta del mismo valor, entonces las cartas acumuladas se queman, es decir, el montón que se estaba acumulando ahora salen del juego. ¿Recuerdas ese cuadrito vacío en la foto que dice “cartas quemadas”?, ahí van, desaparecen del juego. Ah, y te toca de nuevo.

Lo primero que va a pasar es que la baraja se acabe, en ese caso ya no tienes que robar cartas.

Lo siguiente que va a pasar, es que no tengas cartas en tu mano para jugar. Ahí puedes usar las cartas públicas. Acá seré claro, siempre tienes que jugar las cartas de tu mano, no puedes jugar las cartas públicas si tienes cartas en tu mano.

Luego pasará que tampoco tengas cartas públicas, y ahí es donde tienes que elegir una carta oculta, la gracia está que tienes que tirarla a ciegas, es decir, no puedes voltearla, solo tirarla a la mesa y ahí voltearla y revelar si tuviste suerte o no. De igual forma que arriba, siempre tienes que jugar las cartas de tu mano o las públicas, no puedes jugar las cartas ocultas si tienes cartas públocas o cartas en tu mano.

Finalmente, te quedarás sin cartas, perfecto, te libraste de ser cara de caca.

Ya, bacán, hasta aquí el juego se entiende perfecto, aunque está incompleto, porque me falta hablar de los efectos de las cartas.

Efectos

Acá hay varios debates porque depende mucho de donde conociste el juego. Yo hablaré de los efectos que se usaban cuando aprendí a jugar esto en mi universidad (saludos para la gente de Beauchef - UChile).

• Carta 2: Se conoce como “comodín”, siempre lo puedes lanzar, independiente de la carta que esté en juego. Algunos dicen que “el 2 resetea la cuenta”. Es glorioso cuando te tiran una carta alta para cagarte pero tu tienes ese “2” guardadito para salvarte.
• Carta 7: “Invierte” la cuenta, ahora el jugador en turno tiene que tirar una carta menor o igual a 7 o se come la caca.
  • Si el jugador tiene y tira una carta, perfecto, el siguiente jugador juega normalmente (mayor o igual).
  • Si el jugador se come la caca, entonces el efecto sigue en curso, es decir, la siguiente persona aún tiene que tirar una carta menor o igual a 7.
• Carta 8 (esto es polémico, algunos lo juegan así, otros no): Salta al siguiente jugador, es como un “skip” en el UNO. De todas formas, solo lo puedes tirar cuando sea “valido” hacerlo. Los comodines no aplican acá. Daré ejemplos más adelante.
• Carta 10: Comodín (igual que el 2), y quema la mesa.
• Carta J: Invierte el orden, si está de derecha a izquierda, ahora es de izquierda a derecha, (y viceversa).
• Carta Jóker: Comodín (igual que el 2 y el 10) y el siguiente jugador se come la caca. El jugador que la tiró repite el turno.

En lo personal, jugando el juego se va entendiendo esto, a mi me costó al principio, así que daré ejemplos que espero que despejen algunas dudas:

• Te lanzaron una Q, tu lanzas un 2, perfect.
• Te lanzaron un 7, tu lanzas un 8 para saltar, te comes la caca. El 8 no es comodín, por lo que no está sobre las reglas.
• Te lanzaron un 6, tu lanzas un 8 para saltar, perfect.
• Te lanzaron un 7, tu lanzas un 3, perfect.
• Te lanzaron un 7, tu lanzas un 10. Es válido porque es comodín, y quemaste la mesa y ahora te toca otra vez, perfect.
• Te lanzaron un 8, tu lanzas un Jóker/10/2, te comes la caca. Te saltaron el turno, así que jugaste fuera de turno.
• Te lanzaron un 7, tu lanzas un Jóker, la persona de al lado tuyo te mira con rabia, juegas denuevo victorioso, perfect.

Hasta acá, ya puedes jugar cara de caca sin problemas.

Relámpago

En la u jugabamos una variante: “relámpago”.

Es medio enredado de explicar, así que puedes jugar sin esto, pero ya cuando tienes un grupo con las reglas bien interiorizadas, de verdad recomiendo mucho probar esta variante.

Es el mismo juego con las mismas reglas y mismo efectos, pero le agregamos un detallito más: Puedes jugar fuera de tu turno siempre y cuando tengas una carta del mismo valor que el que está en juego.

Por ejemplo, hay un “3”, si tu tienes un “3” en tu mano o publica u oculta, juégala. Eso pone super frenético el juego.

Recuerda eso si, las reglas se mantienen, no puedes jugar ese “3” de las cartas públicas si tienes cartas en tu mano aún.

Dije “jugar de tu mano oculta”, si, yo a veces para tontear, cuando me quedaban las cartas ocultas, llegaba y tiraba una, cuando le achuntaba era precioso.

Final

El juego termina cuando solo queda un jugador con cartas. Ese jugador es el “cara de caca”.

Yo lo jugaba así, aunque he escuchado de otros lados que se raya la cara de la persona perdedora con las letras “CACA” por cada vez que se pierde, y el juego termina cuando una persona tenga la palabra completa.

En lo personal, prefiero lo primero, simplemente pierde la persona que se queda sin cartas y chao. La de completar la palabra “CACA” hace que el juego sea muy largo en la mayoría de los casos.

Ya, ahora que sabemos cómo se juega cara de caca, veamos las definiciones y alcances del proyecto de llevarlo a un juego online.

Definiciones del proyecto

Limites

Para la primera versión del juego, quiero rayar la cancha de tal forma de que el juego sea jugable, pero también simplificándome la vida cuando tenga que programar esto.

1. Sólo se podrá jugar cara de caca si hay mínimo 2 jugadores, y máximo 8 jugadores
   • No quiero arruinarme la vida pensando en cómo chucha dibujar 15 o 30 jugadores en la pantalla. De todas formas siento que el juego se vuelve aburrido si hay más de 8 jugadores en la mayoría de los casos.
2. No hay relámpago:
   • Tengo la corazonada que va a ser un martirio el sincronizar relámpago al jugarlo online, así que prefiero mantenerlo simple. Quizás en una segunda versión, si.
3. Los efectos son fijos:
   • Mira, la verdad pienso programarlo de tal forma de que una persona pueda, al menos, asignar efectos predefinidos a cartas. Pero para la primera versión tanto las cartas como los efectos asignados a las cartas serán fijos. A primera vista creo que va a ser muy fácil permitirle a los jugadores cambiar las cartas con efectos, pero no quiero abrir esa puerta aún.
4. Respecto a la jugabilidad online, no habrá chat de texto:
   • Al menos para la primera versión, creo que igual es un must a tener, pero para esta primera versión quiero que, al menos, el juego se pueda jugar online no más.

Reflexión

Antes de hablar de la arquitectura, quiero detenerme un segundo.

Mucha gente empieza a construir castillos de arena con cosas del estilo

Esto lo haré en Google Cloud Platform con un Cloud Run haciendo blabla…

O tipo

El juego lo haré con el patrón State y blabla…

Considero que eso, en etapas tempranas, es un error por varios motivos:

1. Ya tener súper definido en donde lo vas a desplegar te acopla el diseño al lugar donde lo quieres desplegar. No saber donde lo vas a desplegar te fuerza a considerar eso al programar, lo que lo vuelve flexible.
2. Lo mismo para patrones de diseño.

De hecho, estoy 99.9999% seguro de que parte de los motivos por los que no lograba avanzar en esto, es porque me ponía a pensar en los detalles de arquitectura (código, despliegue, etc…) generándome parálisis del análisis.

De todas formas, creo fuertemente que uno tiene que tener al menos una columna vertebral, definir ciertas lineas, pero esas lineas deben ser flexibles e independiente del lenguaje, despliegue, patrones de diseño, etc…

Por eso quiero definir Arquitectura del Proyecto como esa columna vertebral, una forma de decir:

Así es como yo entiendo el proyecto lógicamente hablando.

Así que démosle, les contaré cómo entiendo el proyecto del punto de vista técnico.

Arquitectura del Proyecto

Lo que más me hace sentido para este juego es modelarlo como un problema de cliente-servidor.

Cada cliente es un jugador, éste verá siempre el estado actual del juego y enviará eventos para intentar cambiar dicho estado. El cliente recibirá actualizaciones del juego.

El servidor contiene el motor del juego, recibe los eventos de los jugadores y los evalúa y traduce en actualizaciones de estado a todos los clientes.

El sistema va a ser prácticamente igual a todos los juegos de mesa online.

Voy a agrupar los clientes en “rooms”, cada “room” representa una mesa. Esa mesa tiene un código único.

Va a haber un “host”, es decir, una persona a cargo de esa mesa. Principalmente el host es la persona que creó la mesa, aunque el host puede entregar su título a otro jugador. El host decide cuando partir y algunas configuraciones del juego (no se cuales aún).

El host puede invitar a otros jugadores a su mesa pasándoles un código único para esa mesa.

El host puede echar a otros jugadores de su mesa.

Entonces, cuando una persona entre a la página web para jugar, primero tendrá que definir su nombre, y luego podrá decidir si crear una nueva mesa, o unirse a una mesa según un código.

Desde ahora, diré “frontend” para referirme al cliente, y “backend” para referirme al servidor.

Frontend

Simplemente va a mandar eventos cuando el jugador quiera jugar una carta, y cada vez que reciba una actualización voy a pintar la pantalla.

Planeo más o menos que el frontend sea así:

1. Pantalla de bienvenida: Me imagino una landing page muy simple con un input para poner tu nombre y un botón de Jugar.
2. Crear o entrar a una mesa: Eso, dos botones: “Crear una mesa” o “Entrar a una mesa”, este ultimo debe tener un input para poner un código de mesa.
3. Pantalla de mesa antes de jugar:
   1. Si no eres host, solo verás los demás jugadores y el host con una coronita o algo, también verás las configuraciones que eligió el host y el código de la mesa
   2. Si eres host, entonces tu nombre tendrá una corona o algo para distinguirte. Verás un botón “Iniciar partida” o algo así.
4. Pantalla de juego: Una mesa, los jugadores alrededor, el jugador de turno está destacado, y eso.

Ejemplo burdísimo de como me imagino el juego a nivel de interfaz, como ven, es lo que menos me importa en este momento y solo quiero preocuparme de eso cuando tenga que implementarlo.

El frontend es lo último que haré.

Backend

Voy a dividir el backend en dos:

1. Capa de API: Acá básicamente recibe eventos del jugador, y emite eventos a los jugadores.
2. Capa engine: El juego cara de caca en sí.

Cada vez que se crea una nueva mesa, pienso crear un nuevo “engine” (algo así como un game controller) y los eventos que se envíen desde esa mesa alterarán el estado del engine. Finalmente enviaré devuelta el estado actual del engine.

La capa de API es lo penúltimo que haré.

Engine

Ya, esto es lo importante.

El engine es quien simulará el juego realmente.

Quise darme la lata de explicar todo lo de arriba para poder definir los “parámetros de entrada” del engine.

El engine va a recibir la cantidad de jugadores (y sus nombre, o no, no sé), los efectos a usar (los definidos en Efectos), y un identificador único (algo así como la semilla del engine).

Con los parámetros de entrada, el engine modelará el juego en tres fases:

1. Preparing Phase: Crea los jugadores y le asigna las cartas, acá vamos a recibir los input de los jugadores para intercambiar sus cartas, una vez que estén todos listos (o hayan pasado 30 segundos), pasaremos a la siguiente fase.
2. Gaming Phase: Aquí comienza el “loop” del juego, esta fase define seis etapas del juego, los definiré a grandes rasgos, pero ya lo detallaremos en la siguiente sección:
   1. Evaluation Stage: Evalúa si, en función de las cartas del jugador y la mesa, el jugador puede o no jugar. Si no puede, se castiga y se va al estado de Turn Management
   2. Play Stage: Espera 10 segundos a que el jugador juegue una carta.
   3. Play Evaluation Stage: Define si la jugada del jugador es válida o no. En caso de que no haya carta (Timeout del estado Play) o la carta no sea válida, se castiga y se va al estado de Turn Management.
   4. Effect Application Stage: Aplica el efecto de la carta válida jugada por el jugador.
   5. Draw Cards Stage: Gestiona lo de robar del mazo
   6. Turn Management Stage: Define quien es el siguiente jugador, también revisa si el jugador actuar ganó (se quedó sin cartas), en tal caso lo saca del turno para que no aparezca más.
3. End Phase: No hace nada, es para que el engine salga del “loop”, es una fase final.

Acá hablaré de fases y etapas, esto para diferenciar cuando hablo del estado del juego, y del estado del turno. Así, si digo fase sabrás que hablo de Preparación, Juego o Fin. Y si hablo de etapas, sabes que hablo de la Evaluación, Jugada, Evaluación de Jugada, etc…

Ahora vamos a los detalles de las fases y etapas.

Preparing Phase

Entrada:

• Lista de cartas (por defecto 1 mazo si son 4 jugadores o menos, o 2 mazos si son más de 4 jugadores).
• Lista de jugadores
• Seed (número o id único para este Engine)

En esta etapa, vamos a crear los jugadores. Cada jugador tiene asociado:

• Identificador o id, puede ser nombre + codigo mesa, o algo así, lo definiré cuando lo implemente.
• Cartas de la mano, que llamaremos hand.
• Cartas públicas o public.
• Cartas ocultas o hidden.

Antes de crear a los jugadores, vamos a barajar las cartas aleatoriamente utilizando el seed. Crearemos la lista de cartas jugadas, y la lista de cartas quemadas.

Luego crearemos los jugadores y le asignaremos tres cartas en hand , public y hidden.

Desordenaremos aleatoriamente la lista de jugadores y notificaremos a los jugadores del estado actual del juego, para que el frontend pueda pintar las cartas y los jugadores.

Acá pondremos un timer de 30 segundos, así el engine queda esperando eventos de intercambio de cartas por parte de los jugadores, o el timeout

Cada vez que recibamos un evento de intercambio de cartas, modificaremos hand y public del jugador emisor del evento.

Al recibir un evento “ready”, marcaremos al jugador como “ready” y notificaremos a todos. El jugador no puede retractarse.

Cuando todos los jugadores estén “ready” o el timeout hay ocurrido, pasaremos a la Gaming Phase.

Gaming Phase

Siempre el primer jugador de la lista de jugadores es quien parte el turno, así partimos inmediatamente a la Evaluation Stage.

Evaluation Stage

El objetivo de esta etapa es evaluar si el jugador actual puede jugar o no.

La primera evaluación es revisar si es el único que aún no ha ganado, en tal caso termina el juego y vamos a la fase End Phase.

Luego evaluaremos si el jugador no tiene cartas, esto es un caso borde porque no debería jugar un jugador sin cartas, de todas formas lo marcamos como ganador y saltamos a la etapa Turn Management.

Tomaremos la última carta de la lista de cartas jugadas. Si no hay ninguna carta, entonces el jugador siempre podrá jugar, por lo que saltamos a la etapa Play.

Si la carta es un Jóker, la carta se quema, penalizamos al jugador y saltamos a etapa de Turn Management.

Bien, ya tomamos los casos bordes, ahora estamos en la situación de que hay un jugador, tiene cartas, y hay una carta en la lista de cartas jugadas, por lo que iremos revisando hand, public y hidden

Caso Jugador tiene cartas en hand: Si tiene cartas en la mano y alguna de ellas es jugable, entonces salta a la etapa Play, caso contrario, lo penalizamos y salta a etapa de Turn Management.

Caso Jugador tiene cartas en public: Acá asumimos que no tiene hand, por lo tanto, si hay alguna carta jugable en public entonces salta a la etapa Play, caso contrario, lo penalizamos y salta a etapa de Turn Management.

Caso Jugador tiene cartas en hidden: Idem, asumimos que no tiene hand ni public. Saltamos directo a Turn Management. La razón es simple, no queremos evaluar un jugador con cartas hidden  sino daremos información de sus cartas.

Play Stage

El objetivo de esta etapa es, simplemente, esperar la carta jugada por el jugador.

Pondremos un timer de 15 segundos y notificaremos a todos.

Esperaremos a que el jugador nos diga qué carta(s) jugó, o el timer termine.

En cualquier caso, pasaremos a Play Evaluation.

Play Evalution Stage

El objetivo acá es validar lo recibido por el usuario. Nunca hay que confiar en lo que nos mandó el usuario.

Primero y más obvio, si no hay cartas (timeout etapa anterior), entonces penalizamos al usuario y pasamos a la etapa de Turn Management.

Ahora bien, ya sabemos a qué montón debería pertenecer la carta que jugó, por lo que haremos evaluaciones de seguridad.

Si la carta jugada no está en el montón esperado, es decir, si el montón esperado es hand  y jugó una carta que no está en hand , entonces penalizamos al usuario y pasamos a la etapa de Turn Management.

Acá sabemos que la carta jugada es del montón correcto, así que obtendremos la última carta jugada.

Evaluaremos la jugada con la última carta jugada.

Si la jugada es inválida, es decir, rompe las reglas del juego, entonces penalizamos al usuario y pasamos a la etapa de Turn Management.

En este punto, tenemos una jugada válida por lo que agregaremos la carta a la lista de cartas jugadas

Si el jugador se quedó sin cartas, lo marcamos como ganador.

Notificaremos a todos y pasaremos a la etapa Effect Application.

Effect Application Stage

Esta etapa tiene como objetivo aplicar en el engine el efecto de la carta jugada.

El primer efecto a aplicar, independiente de la carta jugada, es el efecto quema si existen cuatro o más cartas del mismo valor en la lista de cartas jugadas. Si es así, quemamos las cartas, es decir, movemos todas las cartas de la lista de cartas jugadas y la ponemos en la lista de cartas quemadas, esto naturalmente hará que la lissta de cartas jugadas vuelva a ser vacía. Luego notificaremos a todos los jugadores, notificamos a Turn Management que el turno se repite, y nos movemos a la etapa de Draw Cards.

Ya cubierto el caso anterior, analizaremos la carta jugada.

Por defecto, las cartas 7, 8, 10, J, y Jóker tienen un efecto a aplicar en el estado del juego.

Por lo tanto, primero revisaremos la carta jugada y si no es ninguna de las cartas anteriores, entonces pasamos a la etapa de Draw Cards.

Ahora veamos caso a caso.

Caso Carta 7: Pasamos a la etapa de Draw Cards. Esto porque ya Play Evaluation, al comparar la carta jugada con la última carta de la lista de cartas jugadas, aplica el efecto.

Caso Carta 8: Acá notificamos a Turn Management que debemos saltar al siguiente jugador.

Caso Carta 10: Aplicamos el efecto quema.

Caso Carta J: Notificaremos a los jugadores y notificamos a Turn Management que el turno se invertió.

Caso Carta Jóker: Pasamos a la etapa de Draw Cards. Esto porque ya Evaluation, al revisar la última carta jugada, aplica el efecto.

Acá hay un punto de mejoría, porque solo las cartas que afectan los turnos tienen algo que ver acá, no sé, lo pensaré cuando lo implemente.

Draw Cards Stage

El objetivo de esta etapa es gestionar el mazo y el montón hand  del jugador.

Esto es simple, si el jugador tiene menos de 3 cartas en hand y el mazo no está vacío , entonces repartimos del mazo a hand hasta que el jugador vuelva a tener 3 cartas, o hasta que el mazo esté vacío.

Acá puede haber un punto de mejoría, porque esta etapa siempre la saltaremos cuando no hayan cartas en el mazo.

Luego pasamos a la etapa de Turn Management.

Turn Management Stage

Esta es la última etapa y tiene como objetivo el ajustar los turnos para volver al “loop”.

En la etapa anterior mencionamos lo de “notificar a Turn Management”.

Con eso me refiero a que el Turn Management tiene que saber, principalmente:

1. Si tiene que saltar o no a un jugador
2. Si el orden es de der a izq, o de izq a der
3. Si el jugador actual tiene que repetir el turno.

Me imagino algo así como que la etapa anterior settee variables del Turn Management, pero no quiero entrar en detalles de implementación.

Bien, el Turn Management tendrá la lista de jugadores, un puntero al jugador actual, y la dirección (izquierda o derecha) a cual moverse.

Si hubo un cambio en el orden, entonces cambiaremos la dirección.

Si debemos saltar a un jugador, entonces avanzaremos dos veces en la dirección.

Si debemos repetir el turno del jugador, entonces no avanzaremos.

Por defecto, avanzaremos una vez en la dirección.

Luego, notificaremos a los jugadores y pasaremos a la etapa de Evaluation.

Resumen

Creo que este diagrama resume perfecto las etapas del juego:

End Phase

Esta es la última fase del juego, y la verdad no sé, es solo una fase terminal para indicar que el engine no puede ir a ninguna parte. Así que eso (?)

Definiciones técnicas

Ya que definimos todo el juego a nivel de flujos, voy a empezar a bajarlo a tierra.

Primero, el backend lo haré en python, ¿Por qué?, porque me gusta. El frontend lo haré en typescript por la misma razón.

Respecto a librerías, el engine lo haré vanilla, y la capa de API usaré FastAPI.

El frontend aún no sé, quizás vanilla o react, lo veré cuando lo haga.

Hitos y MVP’s

Para ordenar el proyecto y tener una sensación de que “estoy avanzando”, pretendo hacer hitos y MVPs.

Cada MVP es una feature usable y jugable, y cada hito una agrupación de MVPs que me permitan jugar el juego completo.

Por lo tanto, los hitos y MVPs son los siguientes

1. Hito 1: Jugable en terminal
   1. MVP1: Poder crear jugadores y jugar la fase Playing Phase
   2. MVP2: Poder jugar una carta con reglas básicas sin efectos, es decir, jugar la Playing Phase, y en la Gaming Phase avanzar Evaluation Stage, Play Stage y Play Evaluation Stage.
   3. MVP3: Poder aplicar el efecto de una carta al jugarla.
   4. MVP4: Poder jugar una carta y robar cartas.
   5. MVP5: Poder dar una vuelta al ciclo
   6. MVP6: Jugar una partida completa de cara de caca.
2. Hito 2: Jugable via API.
   1. MVP1: Quiero seguir viendo los datos en terminal, pero el input enviarlo vía API en otra terminal
   2. MVP2: Quiero dejar de ver datos en la terminal, y enviar input y recibir eventos en la otra terminal.
   3. MVP3: Jugar el juego completo en una terminal enviando y recibiendo data a través de la API.
3. Hito 3: Jugable en browser.
   1. MVP1: Quiero poder crear una room
   2. MVP2: Quiero poder meter varios jugadores en una room
   3. MVP3: (quizas esto es un salto muy grande) Quiero poder jugar cara de caca completo con varios browsers en una room.
4. Hito 4: Jugable Online
   1. MVP1: Quiero poder jugar con un amigo de manera online
   2. MVP2: Quiero poder jugar con varios amigos de manera online
   3. MVP3: Quiero que dos grupos (dos rooms) estén jugando de manera online.

A partir del hito 4 ya diré que el juego, en su primera versión, está listo.