Optimicé el JUEGO de ALVA MAJO 

Hola, la solución propuesta se puede optimizar más usando programación dinámica. Hay estados que se pueden generar a partir de diferentes secuencia pero producen el mismo estados entonces en vez de calcular nuevamente esas posibilidades se puede usar programación dinámica para optimizar. Según mis cálculos en el peor caso solo hay que calcular 2×3^9 estados.

La diferencia en las cantidades no se debe a que Alva está ignorando las partidas espejadas y/o rotadas?

Ojalá hubier aplicado programación dinámica para optimizarlo aún más. Alguien debería a atreverse a optimizar la optimización

​@@jpanianacaso quieres que explote el universo

@@jpanian Lo malo es que no tenemos acceso al código fuente pero la implementación con dp no es tan compleja y solo usaría 2x3^9 operaciones. Si tenemos en cuenta que 1e8 ops toma más o menos 1s sería mucha la optimización jsja

jajaja nmms si

si lo ve tal ves le de igual

@@elpeluca Suele interactuar en videos de este estilo para dar su punto de vista

@@Alnidru me refería a aplicar la optimización, ya que no habrá un impacto real en el juego pasar de 0.5 a 0.01

@@elpeluca Ah, eso si que no lo hará, pero si entro a un video que hablaba de las cuestiones que el comento en su video sobre Godot, y el porque no funcionan para él o porque seguía viendolo como una funcionalidad imcompleta

@@elpeluca a Alva le llegará al webo al final dirá que 1s o 1ms no es crucial es su juego xd

Exactamente, ha vuelto a caer en el mismo error que dijo alva, no es la cantidad de jugadas si no la cantidad de jugadas que llevan a victorias o a empate. A ese número que ha sacado habría que descontarle los tableros completos cuando el estado 1 y 2 forman una linea diagonal, horizontal o vertical antes de estar completos, y te daría el número de alva.

Es un buen punto... 🤔 Aun así, quitando los movimientos mas allá de la victoria, sigue sin dar 549,945. *(Mas info en el comentario fijado)* Lo mas probable es que se haya inventando algún filtro del que no habla en su video, y en el código es bastante difícil de identificar.

​@@EterDelta Interesante, revisando el código de python puesto en el comentario fijado creo que hay un problema, cuando no se filtran posibles tableros está correcto (986,409 tableros sin contar el tablero vacío), pero cuando se filtra por tableros válidos, por ejemplo, se puede encontrar contabilizado múltiples veces el tablero: [[1, 2, 1], [2, 1, 2], [1, 2, 1]] El cual no es válido dado que el jugador 1 estaría ganando 2 veces (una por cada diagonal).

​@@ginko3353 Pero esa situación si es posible en un juego, claro que el jugador 2 tiene que ser trenendo manco pero si se puede llegar a dar. Aqui una posible partida con ese final (Con el ejemplo de matrices que usaste) [1,0,0] [0,0,0] [0,0,0] [1,2,0] [0,0,0] [0,0,0] [1,2,1] [0,0,0] [0,0,0] [1,2,1] [0,0,0] [0,0,0] [1,2,1] [2,0,0] [0,0,0] [1,2,1] [2,0,0] [1,0,0] [1,2,1] [2,0,2] [1,0,0] [1,2,1] [2,0,2] [1,0,1] [1,2,1] [2,0,2] [1,2,1] [1,2,1] [2,1,2] [1,2,1] O sea (Tomando 1 como x, 2 como o y 0 como vacío) x o x o x o x o x

Sin embargo, la solución sería buscar una ruta dentro del árbol, que es lo que (creo) Alba Mayo propone de cualquier forma en su vídeo de iteraciones 🤔

Sólo seria poner una probabilidad de que el enemigo no elija la rama optima, o para no perjudicar el rendimeinto, que en x ramas enemigas siempre se elija la primera, asi tendrias un parametro para modificar la dificultad.

Para eso simplemente modificas la función de evaluación y cambias la forma que tiene de comportarse a la hora de buscar el mejor movimiento.

Las mates lo volvieron a hacer. :''c

El número de movimientos está mal lo veas por donde lo veas. El script que pase también tiene en cuenta el orden. ¡De resto, completamente entendible! Como menciono en el video, con tantas ideas en tu juego, el sistema actual sirve y basta. Quizás en un futuro podrías considerar refactorizarlo. ¡Mucho éxito con el proyecto!

​@@EterDelta El script que has pasado no tiene en cuenta el orden y cuenta este estado como válido decenas o cientos de veces independientemente de cómo se llegue a él, pese a que solo sería válido si el último movimiento es el centro: xox oxo xox

​@@AlvaMajo Ah, ahora creo que entiendo tu punto. Es más específico de lo que parece. ¡Sí, con eso da 549,945! *Lo curioso es que se puede seguir usando la formula para hallarlo* 👀 ¡Actualicé el script y el comentario fijado para que la gente pueda verificar tu resultado!

👹👹👹

Igual sería bastante aburrido luchar contra él, después de todo es el tres en raya

No son los mismos tableros reflejados, ni rotadod. El primero tiene 2 horizontales, 2 verticales y 2 diagonales en total 6 posibilidades de ganar. Y el otro 2 horizontales, 2 horizontales y 1 diagonal en total 5 posibilidades de ganar. Pero si seria interesante hacerlo porque el algoritmo al inicio calcula 9*8 tableros, despues 8*7 tables, hasta llegaf a 1*0, o sea, (9*8+8*7+7*6+6*5+5*4+4*3+3*2+2*1+1*0). Mientras mas se juega menos tiene que calcular menos. Si eliminamos las reflexiones habría que decidir como reflejamos arriba-abajo o izquierda-derecha o quizas ¿ambas?, bueno cualquiera que sea la reflexión se pueden reflejar 6 casillas...(9-6/2)(8-6/2) = (6)(5) el primer movimiento (5)(4) el segundo, 4*3 el tercero, 3*2 el cuarto y 2*1 el quinto y finalmente 1*0. O sea 6*5+5*4+4*3+3*2+2*1+1*0. El "problema" de hacer esto es que habria que cuando sea una reflexion hay que sobreescribir el tablero y depende como se lo haga podria llevar un proceso de (6*5+...+1*0)/2 de veces para reflejar el tablero y sumando eso da (3/2)*(6*5+...+1*0). Aunque creo que eso sigue siendo mucho menor que (9*8+...+1*0) Y solo aplicando una reflexion Si le aplicamos las dos juntas seria (9-8/2)*(8-8/2)+...+(1*0) 5*4+4*3+3*2+2*1+1*0 y asi mismo hay que aplicar reflejos cuando se calcula la jugada que en el peor de los casos necesitara reflejarse dos veces de derecha-izquierda y arriba-abajo. 4 si o si se reflejaran 2 veces, 4 solo 1 y 1 ninguna vez seria 4*2 + 4*1 + 1*0 = 12 12*(5*4+4*3+3*2+2*1+1*0), menor que aplicando solo un reflejo Y esto lo hace mas eficiente y ocupa menos memoria pasando de 2*(9!) tableros a 2*(4!), pero con la complejidad que ahora 3 casillas tienen que llevar si esta reflejado(iz-der, arrib-abaj) y el valor que hay en esos reflejos Pero creo que en PC actuales estas optimizaciones no causaran un gran impacto. No se no soy un experto hablo desde mi total ignorancia

@@XaviIntheHouse Tanto texto para estar mal, son el mismo tablero pero con una reflexión horizontal y una inversión de jugadores. Se pueden mapear a un mismo elemento y evitar redundancias.

No es lo mismo bro, ni el propio mojang puede optimizar Minecraft así como así y le estás pidiendo eso a un desarrollador indi XD

1 millón de likes y que optimice la versión Java 🧐🙏

Pa que si ya existe el optifine

yo creo que solo pidió el codigo fuente... si lo piensas, es más probable que lo haya pedido a alva que lo haya extraido via-ingeniería inversa.

@@REESIX1 se tendrían que conoser y tener confianza que no lo ba a publicar después ya que Alva dijo que no quería documentarlo