todo.txt

>>> -1. mini tasks

tests para states
1) en sogT poner un juego nuevo
2) en states test jugar un juego entero 
3) mezclar states test en cada test individual 


>>> 0. Mensaje Personal

Funcionalidad:
No se almacena el estado del juego(-0.33)
Faltan los efectos de unidad y de clima (-0.5)

Diseño:
No se usa un state pattern para manejar el estado de la partida (-0.83)
No usa Composite para manejar los efectos (-0.83)
No usa observer para notificar si un jugador gano/perdio (-0.84)


Revisando los comentarios se menciona que se quería usar un state pattern, 
pero no veo en ninguna parte que se haya hecho de esta manera. 
Ademas, quería acotar que el controlador no esta implementado del to'o bien.
Solo se pedia el controlador, y al usar tantos prints es como si se hubiera implementado 
una vista al mismo tiempo lo cual no es lo que se pedia. 
Me parece que no se tiene del to'o claro el concepto de que es es un controlador,
como se diferencia de una vista y como se debe implementar.



>>> 1. Descripción

El proyecto a realizar será crear un clon (simplificado) del juego de cartas Gwent desarrollado por
CD Projekt RED.
A grandes rasgos el juego tendrá dos jugadores, uno controlado por el usuario y otro controlado por
la computadora.
Cada jugador tendrá un mazo y una mano de cartas que puede jugar en un tablero en una partida al
mejor de tres rondas.
A continuación se explicarán en detalle los requisitos que debe cumplir su programa al finalizar el
proyecto.

>>> 1.1. Jugador

Llamaremos jugador a cada uno de los participantes de una partida, estos serán controlados por un
usuario y una computadora 1.

Cada jugador tiene:

> equals


Las acciones que un jugador puede realizar son:
>   Jugar una carta de su mano: Seleccionar una carta de su mano y colocarla en el tablero para realizar
    una acción.
>   Robar una carta del mazo: Tomar una carta del mazo y agregarla a su mano.


1.2. Tablero
El tablero es la representación física del campo de batalla en el que los jugadores colocan sus cartas.
Está dividido en dos secciones simétricas, una para cada jugador, y cada sección se subdivide en tres
zonas: la zona de combate cuerpo a cuerpo, la zona de combate a distancia y la zona de asedio.
Utilizaremos indistintamente los términos tablero y campo de batalla, así como los términos zona y fila.
Además de las zonas de combate, existe una zona adicional para las cartas de clima que afectan el campo
de batalla y pueden tener efectos como modificar la fuerza de las unidades en diferentes zonas. Esta
zona es compartida por ambos jugadores, por lo que solo puede haber una carta de clima en el campo.
La única diferencia entre las zonas del tablero son las cartas que pueden ser colocadas en cada una de
ellas.

1.3. Cartas
En el juego, las cartas desempeñan un papel fundamental. Existen dos tipos principales de cartas: las
cartas de unidad y las cartas de clima.
Las cartas de unidad son aquellas que cada jugador debe colocar estratégicamente en las zonas
correspondientes del campo de batalla. Estas cartas tienen tres clasificaciones: cuerpo a cuerpo, a
distancia y de asedio, cada uno de los cuales determina la ubicación en la que puede ser colocada. Por
ejemplo, las cartas cuerpo a cuerpo solo pueden ser colocadas en la zona de combate cuerpo a cuerpo,
mientras que las cartas de distancia solo pueden ser colocadas en la zona de combate a distancia.
Además, cada carta de unidad tiene un número que representa su valor de fuerza.
Por otro lado, las cartas de clima son cartas especiales que pueden ser colocadas en la zona de clima.
Estas cartas tienen el poder de afectar el campo de batalla y brindar ventajas o desventajas a los
jugadores, dependiendo del tipo de clima que se haya elegido.
Cada carta tiene un nombre y su clasificación que la identifica. Finalmente, cada carta de unidad puede
tener su propia habilidad especial, esto se explica en la sección 1.4.

1.4. Efectos
Las cartas de unidad pueden tener una habilidad especial que se activa cuando la carta es colocada en el
campo de batalla y que se mantiene activo mientras la carta permanezca en el tablero.
Considere que no todas las cartas de unidad tienen una habilidad especial, pero todas las cartas de
clima sí poseen una.

A continuación se presentan los efectos que debe implementar su programa:

1.4.1. Cartas de unidad
>   Refuerzo moral: Cuando la carta entra en el campo, añade +1 a la fuerza de todas las cartas en su
    fila, excepto a sí misma.
>   Vínculo estrecho: Si ya existe una carta con el mismo nombre en la fila, duplica la fuerza de esa(s)
    carta(s), incluyéndose a sí misma.

1.4.2. Cartas de clima
>   Escarcha mordiente: Establece el valor de fuerza de todas las cartas de combate cuerpo a cuerpo en 1.
>   Niebla impenetrable: Establece el valor de fuerza de todas las cartas de combate a distancia a 1.
>   Lluvia torrencial: Establece el valor de todas las cartas de asedio a 1.
>   Clima despejado: Elimina todos los efectos climáticos actualmente en efecto en el campo de batalla.

1.5. Reglas del juego
El objetivo del juego es acumular más fuerza en el campo de batalla que el oponente al final de cada
ronda. Al finalizar una ronda, el jugador que tenga menos fuerza total en su zona pierde una gema.
El juego finaliza cuando un jugador pierde todas sus gemas. Si se da la situación que ambos jugadores
engan la misma fuerza al término de una ronda, esta es considerada un empate, en cuyo caso ambos
perderán una gema.
Cada jugador cuenta con un mazo de 25 cartas de cualquier clasificación y 2 gemas. Al inicio de la
primera ronda, ambos jugadores barajan sus mazos y roban 10 cartas cada uno. Luego, para las siguientes
rondas, barajan sus mazos y solo podrán robar 3 cartas cada uno, pudiendo tener hasta un máximo de 10 en
sus manos.
Cada ronda se divide en turnos alternados, donde cada jugador tiene la oportunidad de jugar una sola
carta de su mano o pasar su turno, es decir, no jugar ninguna carta. Cuando un jugador pasa su turno,
el otro puede jugar tantos turnos como desee hasta que no tenga más cartas que pueda jugar o hasta que
también pase su turno. Si un jugador no tiene cartas que pueda jugar en su mano, entonces pasa su turno
automáticamente.

Piense que al implementar un proyecto real este comportamiento podría cambiar al agregar nuevas cartas
y mecánicas al juego.
¿Cómo podría hacer para que su programa sea flexible a este tipo de cambios?


1.5.1. Computadora
La computadora jugará cada turno de forma automática siguiendo las siguientes reglas:
1. Si la suma de fuerza de las cartas que tiene en el campo de batalla y en mano es mayor que la del
campo de batalla del oponente, entonces juega una carta al azar de su mano hasta que el oponente pase
su turno.
2. Si la suma de fuerza de las cartas que tiene en el campo de batalla y en mano es menor que la del
campo de batalla del oponente, entonces intentará jugar una carta de clima al azar. En caso de que no
tenga una carta de clima, pasará su turno.

2. Arquitectura
La resolución de este proyecto se hará siguiendo el patrón arquitectónico Modelo-Vista-Controlador,
donde primero se implementará el modelo, luego el controlador y por último la vista. Este patrón se
explicará en más detalle en el transcurso del curso, pero en el contexto del proyecto estos componentes
serán como se explica a continuación.

>   Modelo: Para la primera parte se le solicitará que cree todas las entidades necesarias que servirán
    de estructura base del proyecto y las interacciones posibles entre dichas entidades. Las entidades en
    este caso se refieren a los elementos que componen el juego.
>   Vista: Se le pedirá también que cree una interfaz de consola simple para el juego que pueda responder
    al input de un usuario y mostrar toda la información relevante del juego en pantalla.
>   Controlador: Servirá de conexión lógica entre la vista y el modelo, se espera que el controlador
    pueda ejecutar todas las operaciones que un jugador podría querer efectuar, que entregue los
    mensajes necesarios a cada objeto del modelo y que guarde la información más importante del estado
    del juego en cada momento.




4. Recomendaciones
Como se mencionó anteriormente, no es suficiente que su tarea funcione correctamente. Este curso
contempla el diseño de su solución y la aplicación de buenas prácticas de programación que ha aprendido
en el curso. Dicho esto, no se conforme con el primer diseño que se le venga a la mente, intente ver
si puede mejorarlo y hacerlo más extensible.
NO EMPIECE LA TAREA A ÚLTIMO MOMENTO. Esto es lo que se dice en todos los cursos, pero es
particularmente importante y cierto en este. Si usted hace la tarea a último minuto lo más seguro es
que no tenga tiempo para reflexionar sobre su diseño, y termine entregando un diseño deficiente o sin
usar lo enseñado en el curso.
Haga la documentación de su programa en inglés (no es necesario). La documentación de casi cualquier
programa open-source se encuentra en este idioma. Considere esta oportunidad para practicar su inglés.

Si hay algo que no está especificado en este enunciado, usted tiene la total libertad de implementarlo
a su gusto, siempre que cumpla con lo solicitado y aplicando el contenido enseñado.

Considere (si lo desea) una baraja estándar como:
18 Cartas de unidad, repartidas equitativamente entre las tres clasificaciones,
6 - 10 Cartas de unidad con efecto, idealmente que no sean todas de la misma clasificación, y
7 Cartas de clima.

Por último, el orden en el que escriben su programa es importante, se le sugiere que para cada
funcionalidad que quiera implementar:
1.  Cree los tests necesarios para verificar la funcionalidad deseada, de esta manera el enfoque está
    en como debería funcionar ésta, y no en cómo debería implementarse. Esto es muy útil para pensar
    bien en cuál es el problema que se está buscando resolver y se tengan presentes cuales serían las
    condiciones de borde que podrían generar problemas para su implementación.
2.  Escriba la firma y la documentación del método a implementar, de esta forma se tiene una definición
    de lo que hará su método incluso antes de implementarlo y se asegura de que su programa esté bien
    documentado.
    Además, esto hace más entendible el código no solo para alguna persona que revise su programa, sino
    que también para el mismo programador.
3.  Por último implemente la funcionalidad pensando en que debe pasar los tests que escribió
    anteriormente y piense si estos tests son suficientes para cubrir todos los escenarios posibles para
    su aplicación, vuelva a los pasos 1 y 2 si es necesario.