Capturas consecutivas

[LuisFros]

No me queda claro como funcionan las capturas consecutivas. Como jugador, si la pieza roja de la imagen es una dama. Esto se considera captura consecutiva? Si ese es el caso, se considera como 1 movimiento o 4 movimientos?

[nivek0o0]

Hola,

eso sí se considera una captura consecutiva válida ya que la dama, a diferencia de los peones, tiene el poder de moverse tanto hacia adelante como hacia atrás.

En este proyecto vamos a considerar esta situación que planteas como 1 sólo movimiento, con el único objetivo de simplificar el flujo que debe seguir el servidor para preguntarle a los jugadores sus movimientos.

Si lo consideramos como movimientos separados, el servidor tendría que preguntar al: jugador 1, jugador 2, jugador 2, jugador 2, jugador 2, jugador 1, ..... Lo que es más difícil de manejar. En cambio, si se considera como un solo movimiento, no se rompe la alternación: jugador 1, jugador 2, jugador 1, jugador 2, ...

Por lo tanto, el jugador rojo solo debe ingresar 1 vez la casilla final donde quiere que quede su ficha y el servidor debe hacer las validaciones necesarias y remover las fichas capturadas.

Esto puede generar casos borde, en que hay más de una ruta de captura múltiple para llegar a la casilla final que envió el jugador. En este caso pueden suponer que el jugador siempre quiere comer la mayor cantidad de piezas rivales posible, por lo que el servidor debería remover dichas piezas en la ruta más larga.

EDIT: No es necesario que encuentren el camino más largo, basta con el primero válido!

[cataherrera]

Me surge una duda con respecto a cómo revisar los movimientos de las fichas. Si solo se da la posición inicial y final de la ficha movida, y se espera que encontremos el camino mas largo posible (donde se coman más fichas en el proceso), significa que debemos revisar todas las opciones posibles de caminos válidos que lleven desde la inicial a la final. La única forma que se me ocurre hacer esto es hacer backtracking. Se está pidiendo este nivel de dificultad para esta tarea o hay una forma de recorrer todos los caminos de una forma más sencilla? Se ma ha explicado que muchos caminos no serán válidos desde un principio, haciendo esto más sencillo, pero no concuerdo con esto ya que a pesar de que el algoritmo va a funcionar mucho más rápido y tendrá que recorrer menos caminos, la complejidad de crear el algoritmo sera la misma. Existe alguna forma de que el cliente indique las posiciones que quiere hacer para así simplificar el algoritmo de chequeo al igual de asegurarse que se haga la jugada deseada? En caso contrario, recomiendan algún algoritmo diferente a backtracking para resolver este problema? Muchas gracias

[yoavnavon]

@cataherrera No soy ayudante ni nada pero se me ocurre que DFS puede ser más simple que algo basado en backtraking quizas (?).

Aprovecho de preguntar que pasa si hay dos caminos del mismo largo? Se elige uno aleatorio?

[beayancan]

Me sumo a la pregunta sobre cómo manejar estas situaciones, ya que incluso según como estén las fichas del jugador contrario, podría llegar a comer 4 fichas y volver a la posición inicial, por lo que cada situación posible acaba siendo necesaria tomarla en una revisión bastante grande de posibles movimientos, lo cual no pareciese ser el objetivo del proyecto.

[nivek0o0]

Hola @cataherrera, disculpa la demora en responder, vi tu respuesta hace un par de horas y lo estábamos discutiendo con los ayudantes.

Todos tienen razón en que la tarea no busca que sean capaces de desarrollar ese tipo de algoritmos complejos. Por esa razón hemos decidido eliminar el requisito de buscar la ruta más larga. Esto significa que el servidor puede elegir cualquier camino válido. Sin embargo, la forma más fácil de encontrar este camino es usar backtracking o DFS.

Un backtracking básico no necesita más de 20 líneas de código en C, por lo que esperamos que no les tome mucho tiempo. Esto es resultado del tradeoff resultante de simplificar el flujo que debe seguir el servidor para preguntarle alternadamente a los jugadores.

Para ayudarlos a avanzar en el proyecto, en la ayudantía de mañana vamos a desarrollar un algoritmo de backtracking en C, por lo que les aconsejo que asistan! :smile:

Saludos! @yoavnavon @beayancan

[beayancan]

Una duda ¿van a subir el código de backtracking que vieron como ejemplo?

[nivek0o0]

@beayancan el código ya está subido. Mandé un aviso. Saludos!

[beayancan]

Gracias

[nfbalbontin]

Hola, sobre lo mismo, ¿qué pasa si existen dos rutas más cortas posibles? como comerse dos fichas pero en diferentes direcciones donde la posición final termina siendo la misma. ¿Se elige la primera que se encuentra o el usuario de alguna manera tiene que indicar la dirección a la que juega?

[nivek0o0]

@nfbalbontin Hola, se elige la primera que se encuentre!

[ManuelOchagavia]

Hola, imposible que dejen que se repita simplemente el turno? Ya tenemos implementado el juego y lo pusimos como que se repitiera el turno. No entiendo porque debe ser simplemente un turno en que se haga dfs. A nosotros nos resultó muy sencillo repetir el turno. Espero sus respuestas. Saludos

[nivek0o0]

Hola Manuel, el requisito de poder realizar una captura múltiple en 1 solo turno no se puede cambiar, porque perjudicaría a los grupos que ya han dedicado tiempo en eso. La decisión se tomó para que todos los grupos lo implementen de la misma forma y luego sea más sencillo conectar las tareas.

Si ustedes ya tienen una función que chequea si un movimiento corresponde a una captura, no les debería resultar difícil utilizarla dentro de un algoritmo como el que subimos.

Ánimo que aún quedan varios días! :muscle: