Programe de tip chess engine

Un program care să joace şah (un chess engine) - dar la fel şi unul care joacă checkers, etc. - are trei-patru părţi de bază, care trebuie să fie bine corelate între ele:
—structuri de date pentru reprezentarea poziţiei (tabla de şah, poziţia pieselor, modelarea mutării, cine este la mutare, drepturile curente de rocadă şi de capturare "en-passant", etc.);
—modelarea unor tehnici de căutare, plecând de la un generator de mutări posibile şi asigurând selectarea unei mutări de o calitate cât mai bună;
—evaluarea poziţiei - funcţii care investighează anumite caracteristici ale poziţiei şi le integrează într-o anumită valoare finală asociată poziţiei, asigurând astfel o ierarhizare a mutărilor posibile pe parcursul desfăşurării jocului (servind în procesul de căutare a mutării de răspuns).

Mai este necesară o interfaţă cu utilizatorul - de obicei o componentă independentă, care poate deservi diverse "chess engine"; aceasta asigură transmiterea mutărilor între părţi, precum şi redarea într-o formă grafică "umană" a jocului. Majoritatea programelor "chess engine" din categoria "open-source" folosesc XBoard.

Există numeroase programe "chess engine", multe fiind "open-source"; majoritatea sunt scrise (desigur!) în C/C++. Am început să mă ocup de acest domeniu în 2008, văzând câteva "chess engine" în javaScript - reţin p4wn - şi constatând că ele nu acopereau decât "reprezentarea poziţiei" şi "generarea mutărilor" - încât jocul era redus la mutarea pieselor (şi cu diverse scăpări faţă de recunoaşterea unor categorii de mutări, sau reguli de joc). Mi-au trebuit cam şase luni pentru a mă documenta (tocmai apăruse chessprogramming - o excelentă sinteză pentru "computer chess") şi a realiza treptat prima versiune de chessJSengine:

Se poate deduce cam cum juca programul meu - pe de o parte din lista mutărilor (programul avea albul), iar pe de alta din statistica menţinută dedesubtul diagramei şi care reflectă "efortul" programului (numărul de poziţii evaluate pe o adâncime de 4 - 5 semimutări). Deja începea să semene a joc, dar "efortul" era prea mare - semn că încă ar fi de lucrat asupra metodei de căutare în adâncime pe arborele de joc corespunzător poziţiei (iar căutarea a trebuit să fie limitată la maximum 6 ply-uri, pentru că Firefox abia atingea versiunea 2.0 - mult mai înceată decât versiunea actuală).

Cum era de aşteptat, lucrurile n-au stat pe loc şi astăzi n-am decât să constat că Garbochess-JS (publicat în 2011) "vede" pe o adâncime mai mare decât programul meu, are funcţii de evaluare mai simple şi mai eficiente şi este mai complet ca "chess engine" (implementează şi "transposition table" ceea ce mie nu prea mi-a reuşit şi în plus, prevede utilizarea unei cărţi de deschideri) - încât trebuie să joace mai bine decât programul meu (care a stagnat între timp, "perfecţionările" aduse vizând interfaţa grafică şi… complicarea funcţiilor de evaluare).

O partidă închegată, cu Fruit

Sunt un "şahist talentat" şi în orice caz - am ceva carte la bază şi am ceva experienţă de joc (deţin categoria de "candidat de maestru" atât la "şah practic" cât şi la "şah prin corespondenţă"). Totuşi, cu GNU Chess pierd regulat partide "la 5 minute", iar cu Crafty şi cu Fruit nu am deloc succes (este de precizat că textele-sursă ale acestor trei programe sunt materiale de studiu clasic pentru oricine se ocupă de programe de şah).

În 2008, dynarch a lansat biblioteca DynarchLIB.js şi ca "demo", a lansat şi Dynarch Chess - care între altele, permitea să joci şi cu un "chess engine" (Crafty sau Fruit). Am jucat pe acest server circa 20 de partide cu Fruit (ale cărui surse le tot răsfoiam la vremea aceea) şi am pierdut într-una; abia ultima partidă am reuşit să o câştig, uzând însă de câteva ori de butonul "Undo Move" şi întinzând jocul pe mai mult de o oră - dar a rezultat o "partidă închegată", meritând să o reţin:

Am setat diagrama la mutarea 12.Nc2 pentru că de fapt, de aici "începe" jocul; dar bineînţeles că se poate parcurge partida începând de la prima mutare, sau de la oricare alta (fie derulând lista mutărilor şi făcând click pe mutarea respectivă, fie cu click pe unul dintre butoanele aflate dedesubtul diagramei). Iar caseta de adnotări începe cu o linie pe care (după notarea mutării tocmai efectuate pe diagramă) este transcris FEN-ul poziţiei rezultate - acesta poate fi copiat şi transferat unui program "chess engine" care permite analiza poziţiei.

Poziţia negrului nu are slăbiciuni evidente, în timp ce pionii a2 şi c3, precum şi câmpurile c4 şi (potenţial) d3 sunt obiective de atac clare; deocamdată, albul are oarecare compensaţie prin faptul că poate controla coloana b şi diagonala h1-a8.

Albul ar avea de ales între un joc aparent pasiv, de apărare a flancului damei şi respectiv o încercare de contrajoc în centru şi pe flancul regelui. Dar şi negrul trebuie să decidă ce este mai bine: să atace direct slăbiciunile albului, sau să-şi întărească poziţia pieselor (de exemplu prin Nb8-d7-c5, Qd8-d6, Bc8-e6, Rf8-d8) şi apoi să forţeze cumva schimbul damelor (după care slăbiciunile albului de pe flancul damei ar fi greu de compensat).

Dat fiind că n-am mai jucat în concursuri serioase de mulţi ani, se înţelege că am fost foarte mândru de jocul albului: aducerea calului în d5 (în timp ce negrul curăţa pe flancul damei), e2-e4, Qd1-h5 şi g3-g4-g5, combinat cu Rbe1-e3-g3 şi cu o justă evaluare a raportului dintre atacul propriu pe coloanele g şi h şi respectiv, contraacţiunea negrului pe coloana f.

Dar mereu, am avut senzaţia că negrul putea undeva să joace mai bine… Şi este drept că Fruit a fost configurat să joace "repede", dat fiind că trebuia să ruleze într-un mediu Web (nu pe calculatorul fiecăruia, ci pe server). Am amânat însă analiza partidei, fiind atunci interesat nu de şah cât de mecanismele unui "chess engine".

Analiza partidei, cu Crafty

Comentariile derulate mai sus în caseta de adnotări reprezintă expeditiv propriile vederi. Dar deja de mult timp, "partidă comentată" înseamnă neapărat şi verificarea prealabilă a variantelor folosind un "chess engine".

Putem folosi Crafty pentru a analiza partida respectivă - de exemplu prin comanda:

vb@vb:~$   crafty "annotate  vb_fruit.pgn  wb  12-36  0.500  120"

Crafty va crea fişierul "vb_fruit.pgn.can", corespunzător partidei indicate. Pentru mutările 12..36, pentru ambele părţi (datorită parametrului wb) - dacă scorul celei mai bune mutări găsite de Crafty este mai mare decât scorul mutării efectuate în partidă plus marginea de 0.5 (jumătatea valorii unui pion), atunci Crafty va adnota în fişierul respectiv varianta găsită de el.

Ultimul parametru specifică limita timpului de analiză per mutare; în cazul de faţă, 120 secunde este exagerat - concluziile de apreciere sunt cam la fel şi indicând numai 30, în loc de 120.

Pentru a depista momentele semnificative în care fiecare putea juca mai bine decât a făcut-o în partidă (şi a găsi eventual, momentul cheie al jocului) poate fi convenabil să plecăm de la sfârşit spre începutul partidei.

Mai întâi, negrul se putea salva jucând 30...Bf5 în loc de 30...Rh1:

În al doilea rând negrul a greşit şi mai devreme, când a jucat 27...Bc5; atacul asupra punctului f2 nu dă nimic (cum s-a demonstrat în partidă), deci 27...Bc5 este o mutare inutilă. Crafty indică în analiza sa 27...Bxd5!, conducând aproape forţat la un final avantajos pentru negru; motivul pentru care Fruit a evitat această mutare simplă derivă dintr-o anumită supraestimare faţă de "perechea de nebuni", obişnuită de altfel pentru "chess engine".

Pentru a evita schimbul 27...Bxd5, albul ar trebui să retragă calul pe e3 (în loc de 27.h4 - pe care o cotasem iniţial ca "good move"!), rezultând un joc complicat dar cu şanse mai bune pentru negru:

Această ultimă variantă nu este forţată şi merită analizată mai amănunţit, sperând că jocul albului se poate îmbunătăţi. O analiză "mutare cu mutare" se poate întreprinde foarte comod folosind Scid.

Din cele constatate mai sus rezultă că întreaga idee de atac g3-g4-g5, Rbe1-e3-g4, h2-h4 nu rezistă unei analize mai atente. Prin urmare, trebuie încercat altceva, în loc de 20.g4. În general, dacă ajungi la concluzia că un atac pe flanc nu poate avea succes, atunci ideea de joc cea mai bună rămâne centralizarea (şi în general, jucătorii buni nu se gândesc la atacuri pe vreun flanc, până ce nu şi-au asigurat o centralizare suficientă!):

Dar această centralizare este posibilă numai fiindcă negrul a jucat pasiv la mutarea precedentă, 19...Rb8. Atacând imediat calul din d5 prin 19...Ne7, negrul anihilează ideea Rfd1 + Bf1:

Rezultă că nici mutarea precedentă a albului 19.Qh5 (care în fond, "descentralizează" dama) nu este tocmai bună (ar urma 19...Ne7, cum tocmai am arătat). Nu rămâne altceva, decât reorganizarea pieselor grele pe flancul damei:

Mutarea damei pe h5 a trebuit pregătită (nebunul din d2 rămânea fără apărare) prin 17.Bg5 (forţând şi slăbirea flancului regelui negru) f6 18.Be3 (după care dama poate pleca pe h5). Acuma, de vreme ce analiza expusă mai sus a invalidat deja ideea atacului pe flancul regelui, rezultă că mutarea 17.Bg5 nu este de loc utilă. Crafty indică în loc de 17.Bg5 o variantă de joc elementară (omisă impardonabil de către alb, captat fiind de ideea atacului "frumos" pe flancul regelui) care evidenţiază excelenta cooperare existentă în poziţie între piesele albe:

Tot coborând astfel spre începutul jocului, ajungem să depistăm că momentul în care negrul trebuia să joace mai bine (pentru a evita să ajungă în finalul tocmai indicat mai sus) este la mutarea 15...Be7-d6, la care ne-am referit deja (vezi comentariul de la mutarea 16.e4, în textul iniţial al partidei). Trebuia jucat 15...Be7-d8, pentru a controla câmpul b6 (prevenind ameninţarea pierderea calităţii prin Nd5-b6) şi totodată, pentru a păstra damei un câmp de acces în propria tabără (câmpul d6); negrul ar fi obţinut atunci un joc promiţător.