Foro de la JavaCup > Cambios javaCup: Disparos perfectos
Yo sigo pensando, que si no se está aplicando el error en el eje Z, esa sería la forma más realista y efectiva de evitar por completo que se pueda calcular un tiro a un punto exacto como ha pasado en esta edición con este tipo de goles.
no se si yo entendí bien como funciona la generación del disparo. Por lo que entendí es imposible calcular un disparo a un punto exacto. Por favor que alguien me explique como es que se calcula de forma exacta.
Con la modificación que se propone aquí ya se evitan los goles imparables. Otra cosa es que al aplicar un error en el ángulo vertical el juego gana en realismo, pero esto por si solo no evita los goles imparables solo los harías más difíciles de lograr.
En cualquier caso creo que si se aplica este error debe hacerse también siguiendo una distribución gaussiana y con un probabilidad de error menor a la del ángulo horizontal.
Saludos
Aplicando el error en el ángulo vertical se conseguiría el efecto deseado en un principio, que es hacer que se marquen más goles, y además se evitaría practicamente al 100% que se pueda lanzar a propósito a ese punto con efectividad.
Aún así se podría implementar la otra solución para evitarlos por completo, pero habría que buscar nuevas fórmular de facilitar los goles.
Sobre lo que comentas de la probabilidad de error, pienso que si lo que buscamos es ser realistas, la probabilidad de error en el ángulo vertical debería ser mayor que la del ángulo horizontal, o al menos igual, pero nunca menor.
Saludos.
Seguramente me he perdido algo, pero creo que la frase "Aplicando el error en el ángulo vertical se conseguiría el efecto deseado en un principio, que es hacer que se marquen más goles" no es cierta.
Y estoy con yoemy en que la actual implementación no permite tirar a un punto en concreto, sino que tiras a una 'linea'. Así que meter un error vertical añadiría una dimensión más a la zona de tiro convirtiéndola en una superficie, aunque tengo que revisar el código de los equipos de este año para ver si se me ha pasado algo por alto...
En resumen: si se hacen cambios para mejorar el realismo, estoy a favor. Si son para introducir aleatoriedad y restar importancia a los algoritmos de selección de tiro, no.
No se trata de introducir aleatoriedad, sino de acercarse más al realismo, ya que cuando un futbolista dispara a portería, en la vida real tiene un margen de error en todos los ejes, por lo tanto pienso que se debería aplicar también al eje vertical.
En cuanto a la frase que señalas, me refería a que se comentó, que se introdujo a propósito un punto 'ciego' para el portero para que se marcasen más goles, y que con esta solución no estaríamos anulando ese punto ciego, sino simplemente haciendo más dificil acertar en él a propósito.
Yo también tengo que echarle un vistazo a fondo al código para ver como funciona exactamente, que no he tenido tiempo, pero lo que quiero proponer es que, como en la vida real, un jugador no pueda lanzar con el 100% de acierto a ningún punto o componente del mismo (x, y, z), simplemente calculando la potencia y el ángulo con el que tiene que golpear, sino que siempre haya un margen de error en todas las dimensiones.
el error angular horizontal ya impide eso mismo: es casi imposible conseguir tirar a una línea recta (y el 'casi' creo q sobra)
piensa q dados un azimuth (orientación del tiro), una velocidad inicial y un ángulo de elevación, lo q defines es un conjunto de trayectorias que forman una superficie. esta superficie tiene 'forma' de una porción de donut con el radio interior de 0 (el agujero sería el punto desde donde se dispara). Y el tamaño de la porción del donut depende precisamente del error angular. La intersección de esta superficie con un plano vertical difícilmente será una línea recta, más bien será un arco. cuanto más 'plana' sea la trayectoria y más perpendicular sea respecto del azimuth escogido, más plano será el arco y más se parecerá a una recta. cuanto más se eleve la trayectoria o más 'ladeado' tengas el plano con el q interseccionas, más diferencia de altura tendrás entre los extremos y el centro (o entre el extremo más cercano y el más lejano).
por supuesto, el plano de intersección es y = LARGO_CAMPO/2, con lo q sí sabes siempre la coordenada "y" del punto de destino. es decir, la línea de fondo.
móntate un simulador de trayectorias que te dibuje el corte de todas las parábolas posibles dadas unas condiciones de tiro y lo verás más claro (pq a mi tb me costó un poco caer en esto con el simulador de tiros que viene en el paquete).
A mi ententer el punto ciego al que hace referencia mbr no se introdujo a propósito sino que fue un error en la programación, lo que se quiso introducir a propósito fue que un balón que realmente era gol lo fuera y además se le dio una iteración de más al portero para poder detener pero no se implemento bien.
Con este cambio se soluciona este error y no hay un "punto ciego" si estoy equivocado ponme un ejemplo.
Con respecto al error vertical pues para mi más realismo lo justo, obviamente no favorece que se marquen más goles.
1-Si me permiten hacer los calculos como hasta ahora sería lo mismo solamente agregar un variable mas a mi algoritmo.
2- Si se pone limites al tiempo para devolver la táctica al tener en cuenta una variable mas el disparo no sería el mejor por lo que anotar es más dificil.
Con respecto a disparar a un punto fijo, actualmente no se puede ya lo ha demostrado kpacha aunque un poco dificil de entender, pondré un ejemplo a ver si se hace más fácil.
disparas con una fuerza, un ángulo vertical y un ángulo horizontal al existir un error en el ángulo horizontal el punto (x,y) en todas las iteraciones es imposible de calcular y al no conocer el punto en el plano (x,y) el punto (x,y,z) mucho menos. Que puedes saber exactamente cual es el valor de z pues sí pero que puedes hacer con esto si para saber si es gol tienes que proyectar el disparo con la recta y = LARGO_CAMPO/2, esto implica que la z en esa proyeción no sea siempre la misma por la sencilla razón que los disparos que puedes obtener no alcanzan la recta en el mismo número de iteraciones por lo tanto el valor de z que puedes calcular de manera exacta para una iteración poco te puede ayudar.
Gracias por las explicaciones sobre el cálculo de los tiros. Me queda un poco más claro el funcionamiento.
Respecto al tema del realismo, pienso que sí da realismo, ya que en la vida real existe un error en todos los ángulos, por lo tanto debería de aplicarse el error en todos los ángulos.
Otro asunto es que esto haga más dificil marcar goles, pero pienso que para que se marquen más goles se deben buscar otras soluciones más orientadas a la jugabilidad que al cálculo de un tiro preciso que te haga marcar goles desde mediocampo. Se pueden buscar fórmulas por ejemplo para facilitar los mano a mano con el portero, aumentar la capacidad de remate para que se utilicen más las jugadas por banda, etc.
Respecto a lo que comentas sobre que añadir una variable más y restringir el tiempo de cálculo hará que sea más dificil encontrar en mejor tiro, pienso que es eso precisamente lo que necesita el juego. Creo que se debe valorar más un algoritmo que en poco ciclos encuentre un buen pase/tiro, a un algoritmo que calcule y procese 100.000 posibilidades hasta que encuentre el tiro perfecto. (Ejecutar un partido en debug contra la masia cuando estaba creando mi equipo era un suicidio de lo que tardaba en calcular cada vez que un jugador podía golpear el balón, esos tiempos de cálculo no se deberían permitir).
De esta manera estamos evitando que se creen equipos perfectos que hacen el torneo mucho más aburrido y se premia más la creatividad a la hora de hacer jugar a tu equipo en lugar de permitir que se evaluen todas las posibilidades y elegir siempre el movimiento perfecto.
Para evitar los disparos perfectos el cambio a realizar en el método gol de la clase Partido es el siguiente:
if (alturaBalon - balonDz0 > Constants.ALTO_ARCO)
por
if (alturaBalon - balonDz > Constants.ALTO_ARCO)
Creo que prácticamente hay unanimidad en aplicar esta modificación, pero bueno, en este hilo lo podemos debatir.
Saludos.