Dentro de un motor de ajedrez

He añadido en mi página web un apartado sobre programación:

DanaSah

La intención es explicar como funciona por dentro un motor y familiarizarse con el lenguaje C de una forma sencilla, no es necesario tener conocimientos previos de programación para seguirlo.

De momento he incluido la lección 1 (No prometo cuando habrá más lecciones, me ha llevado más tiempo del esperado). Está en un archivo pdf en la web.

Si alguien lo sigue y hay alguna duda con la primera lección, comentarlo en este hilo.

Pedro

Gracias Pedrox. Ahora mismo, no tengo tiempo de mirármelo, pero sí lo haré. El año pasado me matriculé en un módulo de FP de Desarrollo de Aplicaciones Web. En programación, estamos dando Java, que por lo que dicen es bastante parecido al C.

Apenas conozco el lenguaje Java, ni siquiera soy un experto en C, pero si se que son bastante parecidos y se puede pasar de uno a otro en un corto periodo de tiempo. Si conoces Java por tanto no tendrás ningún problema en seguir las lecciones y entender enseguida el C que utilizan los motores.

También hay algunos motores escritos en Java, el más fuerte es CuckooChess con aproximadamente unos 2750 puntos de ELO, también se puede ver el código de varios motores en Java (ejemplo motor mediocre) e incluso algunos motores tienen una doble versión (ejemplo motores TSCP y Olithink), están escritos en C y también en Java, lo que es un buen material para comprobar las diferencias entre C y Java.

El gran handicap del Java en los motores de ajedrez, es que éstos precisan la máxima velocidad posible, ya que su juego va a depender de ello y en eso el Java no es especialmente bueno al ser un lenguaje interpretado, no se que relación de velocidad hay entre uno y otro para un motor, pero quizás un motor escrito en C es el doble de rápido que en Java y eso en términos de ELO podría ser hasta unos 100 puntos.

La segunda lección la colgaré la semana que viene, seguramente el lunes.

Gracias pedrox,
La verdad, que por el momento Java es la asignatura que peor llevo. Aunque poco a poco iré aprendiendo.
Respecto a la velocidad, lo sé. Java requiere más recursos, pero tiene la ventaja de ser multiplataforma, y por tanto, muy viable para trabajar en entornos web.
Cuando sepa algo más, antes que crear un motor de ajedrez, me apetecería hacer alguna página web, con recursos dinámicos de ajedrez, que ayuden por ejemplo a los chavales a mover las piezas, y cosas así. Y creo que el conocer cómo funciona un motor me podrá ser de ayuda.

Ya está la segunda lección en la web (en el menú en español en el apartado de programación):

https://sites.google.com/site/danasah/

En la página ya indica que archivos hay que bajarse para esta lección.

Esta lección trata el tema de las variables, en concreto las variables globales.

La tercera lección tratará el tema de las funciones y posiblemente se vea la función principal o main.

En la cuarta lección posiblemente se vea el tema de IDE de desarrollo para poder generar el código, compilarlo y linkarlo (esta lección sería opcional, interesante para aquellas personas que quieren empezar a programar y pasable para las que solo están interesadas en conocer el funcionamiento del programa)

La quinta lección podría ser sobre los protocolos de comunicación del motor con los interfaces gráficos o GUIS, protocolo xboard y uci.

Pedro

Muchas gracias Pedro

exelente amigo pedrox, estaba haciendo algunas pruebas con bitboards y me sirvio mucho lo de la funcion and y el desplazamiento, bueno tu trabajo y podriamos considerarlo como pionero de la programacion de notores en español pues la informacion que hay en ingles es a veces dificil de digerir , buen trabajo amigo pedrox

Ya está subida la tercera entrega, explicación de lo que es una una función, lo que es un prototipo de función y lo que es la función main (principal) y que es lo que debe hacer dicha función si nuestro programa es un motor de ajedrez.

Una lección un tanto teórica pero trato de explicar lo mínimo imprescindible para alguien que no conozca la programación pueda comprender profundamente como está hecho un motor. Si alguno se queja que piense que hay libros de lenguaje C que pueden tener 500 páginas o más.

También me gustaría conocer si alguna persona que no conocía nada de programación, si al leer las 3 primeras lecciones puede comprenderlas o todo le resulta confuso. También está disponible este hilo para posibles dudas que puedan surgir de las lecciones o para sugerencias de como hacer las lecciones.

Para la siguiente lección que podría ser opcional, tengo pensado hablar un poco de los IDE de desarrollo, si hay alguien que está interesado en probar la programación, que pueda descargarse un IDE y hacer sus primeras pruebas.

He subido a la página web un archivo pdf con información sobre los entornos integrados de desarrollo (IDE) gratuitos para el lenguaje C. En principio no es una lección obligatoria para seguir el curso ya que quizás haya alguna persona que esté segura que no va a realizar nunca un motor ni programa en C, pero aún y todo animo para leer el documento a todo el mundo y comprobar lo sencillo que es tener un IDE en nuestro ordenador y lo sencillo que es compilar un motor si tenemos la fuente y es compatible con nuestro compilador.

En la próxima lección veremos alguna instrucción más del lenguaje C por ejemplo alguna instrucción que permite recibir información del usuario (fgets, sscanf) y aquellas que permiten variar el flujo del programa (if-else, for, break, continue). Y terminaremos con la función main explicando el código de la misma (en la lección anterior explicamos más bien que cosas debería realizar dicha función en un motor sin hablar de código).

Excelente hilo el que has abierto Pedrox. Tu curso de programación de un motor es muy interesante y divertido. Siempre había querido acercarme a la programación de un motor y tus lecciones son un modo muy ameno de introducirse en este mundillo. Aunque sé programar en C, C++ y algo de Java no sabía exáctamente por dónde empezar.
Muchas gracias y enhorabuena por tu trabajo.

dronstein escribió:Excelente hilo el que has abierto Pedrox. Tu curso de programación de un motor es muy interesante y divertido. Siempre había querido acercarme a la programación de un motor y tus lecciones son un modo muy ameno de introducirse en este mundillo. Aunque sé programar en C, C++ y algo de Java no sabía exáctamente por dónde empezar.
Muchas gracias y enhorabuena por tu trabajo.

Gracias por tus palabras.

Ya está subida la lección 4, el objetivo de dicha lección es comprender el código y funcionamiento de la función principal (main). Para ello se explica las instrucciones que son necesarias conocer y se da algunos ejemplos para que finalmente se pueda comprender paso a paso el código de dicha función. Me imagino que será una lección dura para aquellas personas que no han programado nunca, de golpe y porrazo se enseñan más de 10 instrucciones nuevas y se empieza a combinar con ellas, pero es algo necesario, sin conocer las instrucciones no se puede comprender el código.

Las personas que superen dicha lección creo que no tendrán ningún problema en comprender las siguientes (por ejemplo es posible que para la siguiente lección solo haga falta explicar un par de nuevas instrucciones) e incluso el funcionamiento completo del motor. Así que ánimo con esta lección y las dudas que tengáis las exponéis aquí.

EDITO: En la lección 4 he hecho unos pequeños cambios en el archivo pdf (se ve ahora en el archivo v2), he eliminado básicamente la información de 3 instrucciones que no se explicaban luego a la hora de hablar del código de la función principal y dichas instrucciones junto a un par más serán explicadas en la siguiente lección donde si tendrán un papel más importante. Trato de dejar lo más sencillo posible la lección 4 que ya por si misma será complicada para los que se inician en la programación.

Si habéis leído ya dicha lección no es necesario que descarguéis de nuevo la lección, salvo que queráis guardar las lecciones a modo de curso.

Ya están publicadas las lecciones 5 y 6.

La lección 5 trata el tema de la configuración de los motores, si el motor tiene el protocolo xboard la configuración se suele hacer mediante un archivo de texto o pasando una línea de comandos al ejecutable. Se explican los 2 métodos y se estudia el código. Para comprender el código se explican 5 instrucciones, pero el código es relativamente sencillo de entender si se ha comprendido la lección 4 porque se basa en la comparación de palabras clave.

La lección 6 habla sobre los protocolos de comunicación, se explica el protocolo xboard y se explica el código de la función xboard. Una vez estudiadas la lección 4 y 5, el código es sencillo de leer, no ha sido necesario explicar ninguna instrucción nueva ya que el código está basado principalmente en lectura de comandos.

En la próxima lección seguramente se tratará el formato FEN de posiciones.

exelente pedrox tus lecciones son muy buenas puesto que nos permiten comprender como funciona un motor hasta ahora las he leido todas.. muchas gracias!!!

Veo que las personas que han tenido relación con la programación no tienen problemas en seguir el curso, incluso aunque no conocieran el lenguaje C o algoritmos relacionados con la programación de ajedrez.

Estaría bien saber la opinión de alguien que no tuviera conocimientos previos de programación, saber si puede comprender el contenido de las lecciones y si ahora el código empieza a ser entendible y no solo se ven caracteres chinos que es lo que me pasaba a mi cuando vi por primera vez el código de un motor.

Yo no se programar mas que lo básico que aprendí en las épocas del Commodore 64 en los 80. Sin embargo entiendo perfectamente todo esto. Supongo que cualquiera que tenga un conocimiento mínimo de programación lo entiende.

Ahora bien, hay personas que no saben configurar el winamp para que no distorsione en los graves pero que son genios jugando al ajedrez, así que va en cada persona y el interés que tenga. Creo yo que si está lo suficientemente interesado como para seguir el curso, se lo puede seguir sin inconvenientes. No creo que pase tanto por la dificultad sino por el interés de aprender.

Digamos que el hecho de enseñar a programar un programa de ajedrez hace que la gran mayoría de los interesados tengan un cierto conocimiento de ajedrez, de programación o de ambas.

Fenix escribió: No creo que pase tanto por la dificultad sino por el interés de aprender.

Gracias, esta frase contesta mi pregunta.

Aprovecho para decir que ya he subido la lección 7 en la que se trata el formato de posición FEN y la función SetBoard(FEN) que permite configurar una posición en el motor, bien la inicial o bien otra cualquiera.

La lección 8 tratará sobre los libros de aperturas y el formato PGN.

Ya que estamos con todo esto, te hago una pregunta Pedrox, porque pensas que los programadores en general no han seguido la linea de Ed Schröder en cuanto al estilo de juego, personalización y opciones de configuración innovadoras/raras/diferentes?

Yo noto que hay muchos motores muy fuertes que tienen muchos de los parámetros mas interesantes para hacer personalidades ocultos dentro del mismo programa y no son accesibles al usuario promedio. También leí muchas ideas sobre pequeños cambios que humanizan a los motores y que no están realmente implementadas.

En el foro de Rybka una vez hace no mucho leí un post sobre "noise" o ruido aplicado a la evaluación, que agregaba una variación de un centipeón mas o menos sobre cada posición analizada, de modo que nunca el mismo motor jugara 2 veces la misma partida sin perder realmente casi fuerza de juego.

También otras ideas interesantes que llegue a ver fueron las basadas en el cambio de los parámetros internos del motor (lease personalidad) basados en un análisis de la posición actual, de modo que el mismo motor podía ajustar por ejemplo la agresividad o la importancia de una torre en una columna abierta.

En fin, se ha leído tanto, pero aplicado tan poco...

Pienso que puede haber 3 motivos:

1. La búsqueda del mayor ELO. Muchos usuarios, posiblemente la mayoría, quieren el motor más fuerte en ELO, aunque este gane tan solo por un punto al segundo mejor clasificado y podemos hablar de motores que pueden tener un nivel de más de 3300 puntos. Sabemos hoy en día que el mundo de los motores no da para que haya muchos motores comerciales, es complicado ganarse la vida solo con la programación del motor, por eso es complicado que podamos ver más de 10 motores comerciales, normalmente esos 10 motores comerciales serían los primeros de la lista, los top 10, salvo algunas excepciones de motores libres. Houdini, Rybka, Komodo, Critter, Stockfish están compitiendo por cada punto de ELO, sus programadores aprovechan cada segundo de trabajo en ello. Shredder, Junior, Hiarcs y Fritz quizás se quedan fuera de esa competición pero tienen algo que ofrecer a sus usuarios, hay usuarios a los que les gusta el estilo sólido de Shredder, también usuarios que valoran su interfaz gráfica, Junior y Hiarcs son 2 motores que ofrecen un estilo de juego atractivo para algunos usuarios, Fritz sobretodo es su interfaz gráfica. Quizás alguno de los motores de esta segunda parte que no pueden competir en fuerza sería los que podían incluir mayores opciones de personalización para los usuarios, por ejemplo Deep Junior y Hiarcs, ya que no ofrecen un GUI...

2. La gran mayoría de usuarios con motores que están por encima de los 3000 puntos de ELO han dejado de jugar contra los motores, ahora utilizan los motores para analizar partidas o posiciones o para enfrentarlos a otros motores. No es divertido jugar contra un motor que termina por ganarte material en 20 jugadas. Así que en estas condiciones no tiene mucho sentido las personalidades, salvo que hagamos una quizás para jugar partidas y otra para analizar. El ajuste del ELO por parte de un motor y que parezca real es realmente complicado y costoso.

3. El desconocimiento. Puede haber unos 25 motores que puedan ganar al mejor jugador humano y sin embargo no pueden competir en fuerza con los top 10, son motores que no incorporan su propio GUI, dichos motores no son muy conocidos por el gran público, es difícil que un jugador titulado de ajedrez los conozca y más bien son conocidos solo por los fanáticos del mundo del "computer chess" (quizás 500 personas?). Estos motores que no compiten en fuerza con los top, que no tienen un GUI, serían buenos candidatos para hacerlos atractivos a los usuarios por otros motivos, bien por un estilo de juego único, bien porque permite personalizaciones, etc. El problema es que la mayoría de usuarios solo se preocupan de los top 10. Si un programador de esta lista pide personas voluntarias para jugar con su motor y establecer personalidades seguramente tendría muy pocos candidatos o ninguno. Por lo tanto un programador sin ayuda externa se lo piensa y al final decide hacer lo más fácil, si su motor juega torneos, seguir mejorando el nivel de ELO. Hacer personalidades en un motor no es una cosa muy sencilla para los programadores, muchos programadores pueden no llegar a los 1700 puntos de ELO y si queremos que nuestro motor juegue con un determinado estilo o con una determinada personalidad deberíamos jugar contra el motor, estimo que con menos de 1700 puntos de ELO es complicado sacar conclusiones de una partida.

Cuando Ed Schröder dotó a su motor entonces Rebel de opciones de personalización era otra época, entonces todavía se podía jugar contra programas como Rebel, MChess Pro, Genius o Fritz ya que aunque era difíciles de ganarles tenías una oportunidad. Por eso a Rebel se le valora las opciones de personalización, lo mismo que a Chessmaster.

Hay un motor relativamente nuevo llamado Glass de unos 2700 puntos que tiene personalidades, pero me imagino que sus programadores no habrán tenido mucha ayuda por parte de los usuarios y más que desarrollar estas personalidades terminan luchando por ELO.

Hay alguna versión de TOGA con opciones añadidas por Jim Abblet, también alguna versión de Fire que tiene muchas opciones de personalización, el problema con estos motores es que si quieres modificar algo casi tienes que ser programador.

Por tanto parece que solo puede funcionar algo con personalidades y opciones si tienes un motor top 10 y si haces que esas personalidades sean sencillas de configurar por los usuarios, además que te permitan ganar al motor, que hagan que no te aburras y sigas jugando con él. Algo tremendamente complicado.

Tienes razón, para jugar contra un motor es importante que tengas la impresión de que no es inaccesible, que puedes llegar a ganar. Un programa que tiene una buena regulación elo es el shredder classic, interfaz shredder. Quizás no coincida exactamente con la regulación humana, pero una vez que le pillas la medida puedes jugar con adversarios de tu nivel sin que se deje piezas a lo loco, ni cosas de esas que hace por ejemplo stockfish cuando le bajas la fuerza desde los parámetros. Afortunadamente tenemos motores gratuitos para todos los protocolos (uci, winboard y android) y de todas las fuerzas posibles. Sólo hay que encontrar el/los adecuados para cada uno. Además, para analizar, los motores más flojos (relativamente) suelen dar variantes más entendibles para un humano normalito (como yo) que uno de esos monstruos de más de 3000.

Estoy de acuerdo con chusé, la regulación de nivel de Shredder es posiblemente la mejor disponible. Y sin embargo, es claramente mejorable.

Pedrox habló de las dificultades de añadir personalidades a un motor como Glass, con una fuerza comparable a Danasah. Muy de agradecer una explicación tan clara y detallada.

Pongo todo junto, y lo primero que se me ocurre es: Pedrox, ¿no has pensado en añadir a Danasah o a Calígula, o crear un motor nuevo, la capacidad de jugar como un humano de nivel, pongamos, 1500?

Ya sé que ningún motor jugará nunca como un humano, pero se puede emular de alguna forma. Se puede limitar la profundidad, disminuir la poda, variar la evaluación, añadir una dosis de 'errores' o de azar, etc. Todas esas cosas que ya han intentado otros con éxito muy limitado. Pero, ¿no hay ahí un campo de mejora poco trabajado?

Disculpa la osadía de pedir más a alguien que ya nos da mucho.

Hay varias opciones para bajar el elo que en conjunto pueden resultar interesantes de ver.

Por ejemplo, aumentando los valores posicionales se obtiene un programa mas impetuoso que juega menos tactico. Si tomamos un programa como Stockfish y disminuimos el valor de las piezas a un cuarto cada una, obtenemos un programa muy divertido para jugar, ya que le hace mucho mas caso a su conocimiento posicional que a la táctica. A veces da la sensación de que está acomodando o planeando algo para mas adelante. Obviamente esto hace que contra otros programas juegue terriblemente mal, pero para una persona es algo completamente distinto.

El noise o ruido también es utilizable para bajar el nivel del programa hasta cierto punto sin que se note un cambio en estilo. El problema con el Noise es que a mayor es, menos estilo del programa se nota.

El noise se puede aplicar a cualquier motor de código abierto. tan solo se trata de agregar un par de lineas en la evaluación. Aunque normalmente se usa para que los motores no jueguen 2 veces igual la misma partida, si se aumentan los valores hasta 5 centipeones el nivel cae muchísimo, pero sin embargo no hay errores tácticos ni mucho menos, ya que 5 centipeones de azar a penas esta trabajando en el aspecto posicional del juego. Pasa que 5 en cada ply hace que a mas profundo sea el análisis, mayor el ruido. Es como si el programa viera por la neblina las posiciones mas lejanas, a diferencia de shredder por ejemplo que al disminuir el nivel una de las cosas que hace es reducir la profundidad de la búsqueda, en el caso del noise solo se enturbian mas y mas las posiciones mas lejanas, de modo que el motor "ve algo" pero no con claridad.

Sobre los motores, bueno Scorpio es muy fuerte e increíblemente personalizable, por lo menos desde la evaluación esta todo muy claro. Sería un lindo candidato a un programa con personalidades y reducción de elo mediante noise y el aumento de los valores posicionales.

Muy didáctico Pedrox y Karbunclo. Gracias.

Pedrox y Karbunclo muy interesantes vuestras apreciaciones me he entretenido leyendolas un poco, volviendo tema de el curso Pedro podrias responderme cuales son los pros y contras del protocolo Uci En comparacion Con xboard

Si yo también estuve muy atento a toda la lección. Es mas, baje el codigo fuente de Scorpio y es cierto, esta todo ahi bien modificable cambiando los numeros y muy entendible para cualquier ajedrecista (ni siquiera digo programador eh!). Pero yo no tengo idea ni de como compilar una tortilla para la cena lamentablemente. Sería interesante que todos esos valores y tablas se pudieran modificar desde un .ini y ponerle un nombre y que desde la interfaz del programa cada uno de esos nombres aparezcan como personalidades.

Pedrox, eso del ruido o noise es tan sencillo de implementar? se podría implementar por ejemplo en danash para que veamos la diferencia con respecto a la limitación de la profundidad? Porque parece un poco mas "natural" eso de que el programa vaya "enturbiando" su visión por la suma de pequeños "defectos" en el analisis a mas profundidad en vez de que te corte todo el análisis en 7 plys.

Creo que en este foro se han hecho muchos aportes de ideas a muchos motores, pero al final nunca nos quedamos con nada. Es el caso de Vitruvius.

En cambio el Ajedrez de Lucas si ha recibido buenos consejos y fueron implementados unos cuantos también.

hernansp08 escribió:Pedrox y Karbunclo muy interesantes vuestras apreciaciones me he entretenido leyendolas un poco, volviendo tema de el curso Pedro podrias responderme cuales son los pros y contras del protocolo Uci En comparacion Con xboard

No conozco mucho del protocolo UCI, ya que simplemente me he leído por encima el documento que habla sobre el protocolo pero no lo he llegado a estudiar. Aunque si que he seguido alguna discusión entre programadores a favor de un protocolo o a favor de otro.

Los 2 protocolos tienen un concepto un poco diferente de lo que tienen que hacer, mientras el protocolo xboard simplemente actúa como un intermediario entre el motor y la GUI, sin embargo el protocolo UCI es mucho más que un intermediario, hasta el punto que controla todo lo que puede hacer y no hacer un motor, aquellos motores que llevan este protocolo se consideran casi como simples evaluadores de una posición, por ejemplo cuando se hizo el protocolo xboard se pensó que cada motor debería tener su propio libro de aperturas (hoy en día Winboard soporta libro para cualquier motor aunque no lo incorpore) mientras que el protocolo UCI se pensó que sería la GUI quien se encargaría del libro de aperturas. Los motores que tienen protocolo xboard tienen que tener un control, un registro de las jugadas realizadas y tienen que llevar la cuenta de la regla de 50 movimientos, de la regla de posiciones repetidas, etc, los motores UCI se olvidan de llevar ese control y prácticamente lo que hacen es analizar la posición que reciben de la GUI, es la GUI quien toma decisiones si la partida ha finalizado o no, pero hay autores que opinan que eso debería hacerlo el motor. Por este motivo, programadores como el autor de Crafty, profesor Hyatt han comentando que ellos nunca harán un motor con protocolo UCI, aunque puedan tardar uno o dos días en hacer la implantación.

Hasta hace un año o menos, una de las grandes ventajas del protocolo UCI era que se podía hacer la configuración del motor desde la propia GUI, es más sencillo llamar a una opción de la GUI para hacer la configuración que no tener que modificar un archivo de configuración o mandar parámetros en la línea de comandos. Pero esa ventaja hoy en día no existe, HG Muller que es el programador que está trabajando actualmente en Winboard y sobre el protocolo xboard ha hecho modificaciones al protocolo xboard para que los motores puedan configurarse desde el menú, igual que los motores UCI. Uno de los primeros motores que ha hecho esto es Gaviota, tanto en las últimas versiones de Winboard como Arena se puede comprobar. Otra de las ventajas que tenía el protocolo UCI es que permitía analizar varias variantes a la vez, multipv, claro que para eso el motor tenía que estar preparado, hoy en día también es posible hacer eso con el protocolo xboard. Según HG Muller y algunos otros programadores, hoy en día el protocolo xboard es tan bueno o mejor que el protocolo UCI.

Una cosa bastante criticada del protocolo UCI, es que cada vez que un motor va a analizar una posición, imagina que estamos en la jugada 100, bien pues cuando el motor va a analizar la jugada 100, recibe de la GUI los primeros 99 movimientos, lo cual el motor tiene que interpretar y parece algo ineficiente, parece mejor llevar un registro de las jugadas que no recibir en cada jugada los movimientos anteriores.

Tal como estoy poniendo las cosas, uno podría pensar, ¿entonces porque utilizar el protocolo UCI? La cosa es sencilla, si miramos las GUI comerciales que son las que mayormente usan la mayoría de aficionados al ajedrez que no son especialistas en informática, nos encontramos que la mayoría de las GUI tienen soporte solo para el protocolo UCI. El programador de Shredder es uno de los creadores del protocolo UCI, su GUI creo que tiene soporte para el protocolo xboard, pero dicho protocolo hace más débiles a los motores xboard, está mal hecho, así que si quieres jugar con un motor xboard en shredder lo tienes que hacer con un adaptador (WB2UCI). Por otra parte la GUI comercial más vendida, Fritz y Chessbase, inicialmente incluso solo soportaba su propio protocolo, pero desde que Fritz dejó de ser el motor número 1, corrían el peligro de que su GUI se dejase de usar si no podía jugar en ella Rybka o actualmente Houdini, así que se decidieron a incorporar el protocolo UCI, lo mismo que le cuesta a un programador hacer que su motor tenga un protocolo u otro, le costaría a los programadores de Fritz, a ellos menos que son profesionales, de alguna forma se olvidan de más de la mitad de motores existentes (los xboard) aunque de nuevo gracias al adaptador se pueden utilizar. Esto quizás pueda ser algo comparable a cuando salió el vídeo, había 2 sistemas, el sistema beta y el sistema vhs, terminó triunfando el sistema vhs por cuestión de marketing pero técnicamente el sistema beta era mejor. No quiero decir con esto que el protocolo xboard sea mejor que el uci, como he dicho al principio no lo conozco del todo bien, pero al menos si que parece que están a la misma altura.

istolacio escribió:
Pongo todo junto, y lo primero que se me ocurre es: Pedrox, ¿no has pensado en añadir a Danasah o a Calígula, o crear un motor nuevo, la capacidad de jugar como un humano de nivel, pongamos, 1500?

Al igual que hay listas de ELO con los mejores motores, también hay listas con los peores, en alguna ocasión he visto alguna lista con cantidad de motores entre los 1000 puntos y 2000, podemos quizás tener en esta lista 200 motores. Para aquellas personas que quieran jugar con motores seguramente podrían probar varios de esta lista según su nivel. Abriré otro hilo aparte y pondré una lista que hayan puesto en algún otro foro.

En la página web de DanaSah hay un apartado que se llama otras versiones, en dicho apartado tengo guardas más o menos todas las versiones que han sido publicadas, en cada versión indico más o menos el ELO, antes de llamar al motor danasah lo llamaba eire y quizás juega con unos 1500 puntos o algo así. La siguiente versión danasah 1.0 juega como 1800 puntos, la versión 1.1 y 1.2 posiblemente están por debajo los 2000 y la versión 1.3.4 ligeramente por encima de los 2000 (solo la última incorpora un libro de aperturas).

El problema no es hacer una versión del motor que juegue con una determinada fuerza, posiblemente partiendo de la versión actual de danasah y quitando cosas, posiblemente en menos de una hora pudiese tener una versión que juega algo así como 1500 puntos y que lo haga de una forma más o menos natural, sin perder material. El problema supongo que es que unas veces queremos que el programa juegue como 1500, otras 1600, otras 1700, etc y que lo haga de una forma natural. Queremos poder regular el ELO entre por ejemplo 1000 puntos y 2500 puntos, queremos que ese ELO sea el real que tuviera un humano. Para hacer esto, desgraciadamente no hay una fórmula que se pueda aplicar a la búsqueda o a la evaluación y que haga el proceso sea sencillo. Por eso los programadores tienen que jugar con algunas cosas como se ha comentado ya en el hilo, tienen que jugar con quitar cosas que hacen más rápida las búsqueda, tienen que jugar con cosas que reduzcan el tiempo del pensamiento, tienen que jugar con la profundidad y luego hay que jugar muchas partidas para hacer el ajuste de la fuerza de juego igualable al ELO humano. De nuevo los programadores se encuentran con un problema, ¿dónde encuentro yo un montón de jugadores humanos que estés dispuestos a jugar contra el motor para ajustar el ELO? Quizás la opción más sencilla es hacer el ajuste de la fuerza comparado con el ELO de los motores que nos podemos encontrar en una lista, pero ese ELO es complicado saber si es el equivalente de un humano o no. ¿Por ejemplo sabemos que el ELO de Houdini es de 3300 puntos? Si los motores no juegan torneos humanos es complicado saberlo. Hiarcs es uno de los pocos motores que ha jugado algunos torneos, pero no los suficiente para establecer un ELO humano claro.

La verdad es que si que he pensado en alguna ocasión hacer algún tipo de regulación en la fuerza del motor, pero quizás no he estado demasiado motivado porque he pensado que mucha gente no utiliza el motor para jugar como humano, claro eso también es culpa mía si solo intento que danasah juegue con el mayor ELO, por otra parte no tengo muchas ideas de como es posible conseguir algo atractivo al usuario y en caso de tener ideas no soy muy buen programador y me suele llevar tiempo el hacer código. Teniendo algunos programas como Prodeo, Delfi o Shredder, pensaba que el mío no podría portar cosas interesantes.

Ayer estuve haciendo algunas pruebas con Arena, esta GUI tiene una opción para debilitar el motor, utilicé una de las últimas versiones del programa que debe rondar los 2600 puntos y debilitando el programa al 1% de su fuerza lo hice jugar contra el motor TSCP que se le supone un ELO de unos 1850 puntos. Ganó DanaSah 6-4 pero parecían bastante equilibradas las cosas, con ese resultado (10 partidas son pocas) pero quizás danasah bajó su ELO a 1900 puntos. Arena también permite jugar al usuario con un nivel de profundidad, así que es posible decirle al motor que juege en ply 1, 2, 3, etc.

Con estas pruebas que hice he pensado hacer una versión de DanaSah en la que voy a dejar todo el conocimiento posible en cuanto a la evaluación, para que el motor no parezca tonto, pero voy a quitar de la búsqueda técnicas que hagan que el motor pierda algo como unos 400-500 puntos de ELO. De esta forma el motor pasaría a tener una fuerza de unos 2100-2200 puntos. Si con esa fuerza le aplicamos la posibilidad que tiene Arena de regular la fuerza del motor quizás consiga hacer que el motor juegue con 1400-1500 puntos de ELO. Por otra parte, gracias al mensaje de Karbuncio, se me ocurre que podría hacer algunas personalidades, por ejemplo, la que juega el programa normal se le puede llamar algo así como solido, luego Karbuncio propone reducir el material del motor en una cuarta parte y a esa personalidad se le podría llamar super-posicional, quizás se pueda hacer otra dividiendo por 2 y llamarla posicional. No estoy seguro pero he pensado en lo contrario, si aumentamos el doble el material quizás tengamos una personalidad táctica y si aumentamos los valores por 4 por ejemplo personalidad super-táctica. También otra posibilidad que ha comentado Karbuncio, añadir 50 centipeones de ruido podría ser una personalidad llamada medio ciego y si añadimos 100 por ejemplo ciego.

Fenix escribió:Si yo también estuve muy atento a toda la lección. Es mas, baje el codigo fuente de Scorpio y es cierto, esta todo ahi bien modificable cambiando los numeros y muy entendible para cualquier ajedrecista (ni siquiera digo programador eh!). Pero yo no tengo idea ni de como compilar una tortilla para la cena lamentablemente. Sería interesante que todos esos valores y tablas se pudieran modificar desde un .ini y ponerle un nombre y que desde la interfaz del programa cada uno de esos nombres aparezcan como personalidades.

He realizado un vídeo dónde se ve la posibilidad de descargarse un entorno integrado de desarrollo, es rápido 24 Mb y versión portable, así que no hay muchas excusas para no tener el programa en el ordenador. En el vídeo también descargo 3 motores DanaSah, TSCP y Fruit y realizo un ejecutable para cada motor. Tenía pensado no pasar de 20 minutos pero al final fue más largo al utilizar 3 motores en lugar de 1. Tengo pensado hacer un segundo vídeo para optimizar un poco la velocidad del ejecutable. En cuanto termine este segundo vídeo pongo el enlace a los 2. Espero que esto no sirva simplemente para hacer clones de motores cambiando únicamente el nombre del motor y el autor.

Pedrox, eso del ruido o noise es tan sencillo de implementar? se podría implementar por ejemplo en danash para que veamos la diferencia con respecto a la limitación de la profundidad? Porque parece un poco mas "natural" eso de que el programa vaya "enturbiando" su visión por la suma de pequeños "defectos" en el analisis a mas profundidad en vez de que te corte todo el análisis en 7 plys.

Esto ya he contestado un poco más arriba a Istolacio. Hasta ahora no había pensado seriamente en la posibilidad de hacer algo con el nivel de fuerza, pero posiblemente me anime a hacer alguna prueba. Como dijo Karbuncio añadir el ruido es sencillo y tan solo hay que añadir una línea o 2 de código, en algún foro en inglés han tratado el tema programadores, yo creo que lo leí pero no me acuerdo exactamente como era. Karbuncio ya ha dicho que lo va a aplicar a Scorpio. Quizás yo también lo haga en DanaSah, pero también tengo pensado como dije más arriba, reducir la fuerza del motor en 400 ó 500 puntos y quizás construir algún tipo de personalidades primitivas en el motor. Podría formar parte de una lección más y ver como modificar el código para realizar personalidades (pero claro mejor es primero conocer el código de la búsqueda o la evaluación, sería una de las últimas lecciones).

Creo que en este foro se han hecho muchos aportes de ideas a muchos motores, pero al final nunca nos quedamos con nada. Es el caso de Vitruvius.

En cambio el Ajedrez de Lucas si ha recibido buenos consejos y fueron implementados unos cuantos también.

Espero que su autor siga leyendo el foro y volvamos a verle por aquí.

He subido como complemento al archivo pdf sobre entornos integrados de desarrollo (IDE) 2 vídeos:

- El primero muestra qué sencillo es descargarse un entorno de desarrollo y configurarlo (DEV-C++ portable). También se descargan 3 motores de ajedrez y se procede a crear un ejecutable para cada uno de ellos. El vídeo ha quedado un poco largo, unos 45 minutos, en parte por utilizar 3 motores en lugar de 1, pero de esta forma comprobáis que no solo funciona con mi motor.

https://www.dailymotion.com/video/xpfeth_dev-c-and-chess-engines_tech

- El segundo vídeo muestra como es posible crear ejecutables de 32 y 64 bit (64 bit siempre que hayamos descargado la versión de 64 bit y luego tengáis un sistema operativo de 64 bit para poder ejecutar el motor creado). También se ve como se puede cambiar alguna opción del compilador para crear ejecutables más rápidos. Este segundo vídeo tiene una duración de unos 23 minutos.

https://www.dailymotion.com/video/xpgeff_dev-c-ejecutable-rapido-para-motor-de-ajedrez_tech