con un programa Se carga en memoria y se pone al tope del ZOrder, es decir: encima de todas las ventanas. Figura como un visor o banner, puesto donde se quiera, por ejemplo, en la esquina superior derecha de la pantalla;

2. El programa carga en memoria, como un proceso adjunto, el motor de ajedrez que el programero prefiera, por ejemplo Rybka. Debe ser UCI, luego verán por qué. Este motor queda "comunicado" con el programa mediante algo que se llama "tubería" (pipeline). Se trata de un bucle sin fin de mensajes. El motor arranca y queda a la espera de órdenes por parte del "host", que sería el programita que estoy describiendo;

3. Constantemente, algo así como 3 o 4 veces por segundo (esta frecuencia se puede ajustar), este programita saca una instantánea de la ventana siguiente en el ZOrder, ( la ventana del server de ajedrez que ustedes quieran; . Esta instantánea, o "captación" de ventana, es simplemente un bitmap idéntico a lo que ve el ojo humano. Esto se logra mediante las funciones gráficas de la librería GDI de Windows;

4. Cada vez que el programa "mira" la ventana de de la pagina web, la escanea en busca del tablero. El programa está diseñado para saber dónde buscarlo, en qué coordenadas espaciales debe rastrear el tablero, todo según la resolución de la pantalla. Si no lo encuentra, sigue a la espera. Si lo encuentra, supone que la partida ya está en juego, y entonces se pone en acción:

5. Una vez que ha localizado en el bitmap de la pantalla la zona del tablero, la escanea con precisión, para determinar qué pieza está en cada casilla. Esto se conoce como OCR: reconocimiento óptico de caracteres. Las figuras de las piezas se analizan igual que caracteres. Este análisis prescinde de las medidas: es topológico. En cualquier página dedicada a “chess programming” encontrarán módulos y plugins para hacer OCR de tableros de ajedrez. Se usan mucho en edición de libros, etc.;

6. Una vez que se escanea el tablero y se hace su OCR, se obtiene una versión "simbólica" del mismo con todas las piezas en juego, es decir: el programa ya sabe a qué posición se ha llegado en la partida. Esta versión simbólica de la posición ya no es una imagen, un bitmap: es información pura. Por ejemplo, una matriz de 64 elementos, cada uno indicando una pieza (con su color), o bien, una casilla vacía;

--------------------------------------------------------------------------------
7. Esta información se recodifica en formato FEN. Las líneas FEN son la forma estándar de codificar posiciones de ajedrez. Por ejemplo:

2r1r1k1/pb3p2/2q3p1/4p3/5n1p/4NR2/PPP2PPP/R1Q2BK1 b -- - 3 24

 pero los programas de ajedrez así;

8. Una vez que el programa convierte la información visual en simbólica y luego en formato FEN, pregunta si esta línea FEN es nueva, o si ya se ha despachado. Si esta línea FEN (esta posición en el tablero), es distinta a la que se ha procesado anteriormente, es que sobre el tablero se ha movido una pieza, y entonces hay que iniciar un nuevo proceso de cálculo, que es lo que explicaré en el punto siguiente. Pero si la posición FEN es igual, es que no ha habido cambios en el tablero, y entonces se sigue "pensando" la posición actual, la ya reconocida;

9. Detectada una nueva posición, el programa se la pasa al motor para que la piense. El protocolo UCI permite pasarle a los motores posiciones FEN y darles la orden "go", para que ellos se pongan a pensar cuál es la mejor jugada en esa situación concreta. No hay límites de tiempo: el motor piensa indefinidamente. Cuanto más tiempo pase, mejor será su apreciación;

10. Dije que el motor estaba comunicado con el programa. No sólo recibe mensajes: también los envía al host. De estos mensajes, el que le importa al programero es cuál es la mejor jugada posible en la actual posición. El motor la brinda en formato antiguo, por así decir: algo así como "b1-c3", "e4-f5", etc. Como los viejos programas de DOS;

11. Esta jugada es la que muestra el programa usado por los programeros. Su único trabajo es saber interpretar esa extraña notación. Imagino que algunos de estos programas ya son capaces de traducir esos códigos a cosas como "Cf3", "AxT", etc;

12. El programero sólo debe mirar el visor de su programa, para saber qué aconseja el motor para esa posición. No está obligado a jugar lo que el motor sugiere: ese es el problema más grave para nosotros, porque de nada sirve analizar luego la partida sospechosa, buscando coincidencias con las jugadas propuestas por (digamos) Fritz;

13. El programa también sabe detectar qué bando debe jugar, claro está. Sin ese dato, nada puede hacer