El ajedrez representa un mundo infinitamente interesante e infinitamente complejo en todos los sentidos. Como juego, como jugador, como mero espectador apasiona al que llega entenderlo. Pero son dos de estos sentidos los que me han traido hasta aquí y los que conseguirán que esto, algún día, llegue a ser o no algo importante.

En primer lugar, como jugador, es algo que no pude evitar. La herencia genética es demasiado fuerte para pasarla por alto y el hecho de que en mi casa siempre hubiera un ajadrez donde poder mover una pieza de un lugar a otro también ayudó bastante.

Como jugador llegas a conocer las reglas, los estilos de juego, los pequeños trucos que casi nunca funcionan, pero sobre todo llegas a conocer la complejidad del juego desde dentro. Pronto entiendes que el ajedrez no es un juego como tal, es algo mucho más grande que supera con creces el concepto de juego.

Por otro lado, como programador, el ajedrez representa un reto tan grande como el propio juego en sí. Plantea tantas incognitas como posibilidades existen de mover una pieza. Pero lo más dificil de entender o asimilar cuando te enfrentas con el problema de crear un programa que sea capaz de jugar al ajedrez es que un ordenador, por avanzado que sea, por muchas cosas que sepa hacer, no sabe jugar al ajedrez, al menos no en el sentido que le damos a saber. Un ordenador no sabe de estrategias de juego, de aperturas, de reglas. Es más, un ordenador no sabe, en principio, de tableros ni de piezas.

Sabemos hacer aplicaciones que realicen acciones repetitivas, acciones automáticas mediante reglas predefinidas y bien establecidas. Eso es relativamente sencillo y nos entrenan para hacerlo. Lo realmente dificil es hacer que un ordenador piense. En el ajedrez no vale eso de "si ha pasado tal o cual cosa entonces hacemos esto, y si no pues esto otro". Si esto fuera así, tendríamos jugadores perfectos de ajedrez y programas de ajedrez aún más perfectos, y todos sabemos que no es así. Incluso siéndolo, hay que recordar que estamos hablando de ajedrez y no de juegos como el tres en raya. No hablamos de unas pocas decenas de posibilidades, sino de millones de ellas. ¿Alguien se presenta voluntario para escribir millones de reglas distintas en un programa de ajedrez? ¿Sería posible escribirlas? Por si hubiera algún valiente, anticipo que no es posible, no tendrías donde guardarlas, y sí, aunque tengas un disco duro de 120 Gb.

Con todo esto en mente, no es dificil ya entender que el primer reto y quizá el más importante a la hora de afrontar un problema de este tipo es que hay que empezar a pensar de otra manera, y que esto debe quedar reflejado en el programa que escribas. Por todo esto y por más que poco a poco iremos viendo a lo largo de las descripciones teóricas que iré publicando en esta web, es por lo que me embarqué en su momento en este proyecto, y por lo que sigo embarcado con todos vosotros.

¿ Qué voy a aprender ?

Como he dicho, la lección principal será la capacidad de pensar de una manera diferente. ¿que quieres algo más concreto? Pues puedo decirte que primero te familiarizarás, si no lo conoces ya, con un lenguaje relativamente nuevo como es C#, aprenderás algunas técnicas de inteligencia artificial, métodos avanzados de búsqueda de soluciones, aprenderás a crear y utilizar interesantes estructuras de datos no muy frecuentes, y entre otras muchas cosas aprenderás a tener en cuenta durante el desarrollo cosas que prácticamente nunca habrás tenido en cuenta como a equilibrar gastos de espacio y tiempo y sacrificar unos por otros, o a optimizar al máximo los requisitos de espacio (primer mandamiento: no utilizaré un entero cuando sólo me hace falta un bit, recordadlo, si no os aseguro que tendréis problemas).

¿ Por que el lenguaje C# ?

Cierto es que conociendo los requisitos de cualquier software de ajedrez, la primera opción a la hora de elegir lenguaje hubiera sido para cualquiera de nosotros algún lenguaje que compile a código nativo, más rápido y eficiente que cualquier otro lenguaje interpretado. Sin embargo también es cierto que C#, bien utilizado (reconozco que no es mi caso en algunas ocasiones), difiere muy poco en rendimiento con lenguajes compilados comol C++ ya que no se trata realmente de ningún lenguaje interpretado, sino que se compila a código nativo a la hora de ser utilizado. Y direis: aún así me sigue pareciendo mejor idea utilizar C++. Es posible, pero por encima de todas las razones que podamos poner sobre la mesa, existen dos principales que quiero expresar a mi favor.

1. El lenguaje C++ añade cierta complejidad al desarrollo por la propia naturaleza del lenguaje (hablo de punteros, gestión de memoria, etc). En mi caso, yo sólo quería centrarme en el problema del ajedrez como software, y no en preocupaciones propias del lenguaje elegido. C# por su parte da bastantes facilidades en cuanto a la gestión automática de la memoria y es un lenguaje bastante limpio en general.
2. Y como segundo argumento, y esto no se trata de ningún criterio técnico, pongo que cuando comencé a plantearme el proyecto también estaba interesado en el lenguaje C#. Supongo que es matar dos pájaros de un tiro.