• Ștefan Rușeți
• Dragoș Corlătescu
• Ionuț Bîrsu
• Andrei Dumitrescu
• Ianis Bacula
• Marius Vintilă

Tema proiectului de anul acesta din cadrul materiei Proiectarea Algoritmilor va fi realizarea unei inteligențe artificiale capabile să joace șah[1]. Proiectul se va realiza în echipe de câte 2-3 studenți (minim 2, maxim 3 studenți pe echipă) și se va desfășura pe parcursul a 4 etape. Se va folosi platforma XBoard 4.8 pentru a interfața, vizualiza, înregistra și reda partidele jucate între aplicațiile realizate în cadrul proiectului. Dacă vreți să testați pe Windows, puteți folosi varianta WinBoard, pe care o puteți descărca de aici.

Reguli de upload: La fiecare etapă (în afară de etapa 0) veți salva în repository-ul vostru (cel specificat la înscriere) o arhivă zip, numită “EtapaX.zip” (unde X reprezintă numărul etapei: e.g. “Etapa1.zip”)

Arhiva va conține:

• Codul sursă (toate sursele folosite)
• Makefile (sau CMakeLists.txt)
• README

Pentru notare, toate arhivele vor fi descărcate automat - asigurați-vă că arhiva există în repository, este numită corect și este completă.

Makefile:

Boții vor fi evaluați pe un sistem Linux/GNU pe 64 biți, deci este foarte important să verificați că aveți un makefile care funcționează corect pe Linux, chiar dacă lucrați pe Windows sau MacOS. Scriptul de testare va apela “cmake .” (dacă ați trimis un fișier CMakeLists.txt), respectiv “make”.

Asigurați-vă că fișierul Makefile nu conține path-uri absolute (să poată fi rulat și pe alt sistem). Este util sa aveti o regula “clean”, pentru a sterge executabilul si fișierele obiect/log-urile generate (dacă este cazul).

Fișierul Readme va respecta următoarea structură:

• Instrucțiuni de compilare.
• Detalii despre structura proiectului.
• Detalii despre abordarea algoritmică a etapei: ce algoritmi ați folosit, cum i-ați combinat, de ce, complexități, etc.
• Surse de inspirație
• Responsabilitatea fiecărui membru al echipei.
• Documentația valorează 10% din punctajul proiectului.

Atenție! Deadline-urile la proiect sunt hard, deci nu se permit întârzieri. Dacă s-a ratat deadline-ul la o etapă, se poate lucra în continuare pentru celelalte etape, dar punctajul se va pierde pentru respectiva etapă.

Etapa 0 presupune formarea unor echipe de câte 2-3 persoane. Echipele se pot forma între oricare 2-3 studenți din aceeași serie. Studenții restanțieri pot participa cu colegi de la orice serie.

Fiecare echipă va desemna un membru al acesteia cu rolul de căpitan. Căpitanul va avea, printre altele, sarcina de a trimite în numele echipei sale soluțiile pentru fiecare din etapele rămase. Ceilalţi membri ai echipei nu vor trimite soluții, decât in cazul in care căpitanul nu poate face acest lucru din motive obiective.

Un obiectiv al acestui proiect este lucrul in echipă. Recomandăm să citiți cu atenție regulile jocului și să vă alegeți fiecare rolul in echipă, rol pe care să îl mentionați în momentul inscrierii. De exemplu, o echipă de 3 studenți poate fi formată dintr-o persoană care să scrie codul, 0 persoană care să facă cercetare (tactici, algoritmi, optimizări) și un tester. Rolurile se pot schimba pe parcurs.

Pentru a ajuta colaborarea în echipă, veți folosi un sistem de versionare a surselor numit git. Mai multe indicații aici.

Pentru înscriere, accesați acest link.

Această etapă va avea 1 săptămână. Punctajul alocat acestei etape este de 0 puncte.

Deadline-ul acestei etape este duminică, 1 martie 2020, ora 23:55.

Se va realiza reprezentarea internă a tablei de joc și a pieselor de joc, precum și o interfațare cu programul XBoard.

Interfațarea va presupune posibilitatea de a interpreta și interacționa cu următoarele comenzi ale XBoard: xboard, new, force, go, white, black, quit, resign, move.

De asemenea, programul va trebui să primească mișcări de la XBoard și să trimită mișcări legale. Nu este nevoie pentru această etapă să trimită orice mișcare legală posibilă.

Este suficientă mișcarea legală a unei singure piese (ex: pion, cal etc). Dacă programul nu mai găseste mișcări valide, va putea ieși din joc (prin resign sau orice altă metodă; de preferat una elegantă)

Această etapă va avea 2 săptămâni. Punctajul alocat acestei etape este de 0.4 puncte.

Deadline-ul acestei etape este TBD.

Programul va trebui sa implementeze macar un algoritm de bază minimax pentru a putea juca împotriva unui adversar. Programul va trebui să poată interpreta orice mișcare legală primită de la adversar, ceea ce presupune implementarea tuturor regulilor jocului.

Această etapă va avea 4 săptămâni. Punctajul alocat acestei etape este de 0.5 puncte.

Deadline-ul acestei etape este TBD.

Această etapă este dedicată implementării unor algoritmi avansați pentru a crește calitatea jocului prestat de program. Punctajul pe această etapă poate fi obținut în urma unor meciuri cu boți puși la dispoziție de noi. Recomandăm implementarea algoritmului alpha-beta și a cel putin două tehnici avansate/euristici pentru a putea calcula cât mai multe mutări în față. Administrarea timpului rămas este o componentă foarte importantă acestei etape.

Detalii despre boții puși la dispoziție, reguile de punctare și formatul meciurilor vor fi anunțate ulterior. Această etapă va avea 4 săptămâni. Punctajul alocat acestei etape este de 0.5 puncte.

Deadline-ul acestei etape este TBD.

In cadrul acestei etape se va realiza un concurs intre proiectele realizate. In functie de numarul de proiecte finite realizate se va stabili formatul concursului: campionat, tournament tree sau grupe+tournament tree.
Punctajul aferent acestei etape este de 0.5 puncte si se va acorda dupa urmatorul algoritm:

• Locul 1 va primi 0.5 puncte
• Locul 2 va primi 0.4 puncte
• Locul 3 va primi 0.35 puncte
• Restul proiectelor vor primi in functie de locul in clasament intre 0 si 0.3 puncte, marja intre doua proiecte consecutive fiind de 0.3/(numar_proiecte_finaliste-3)

• Fiecare partida intre doua proiecte se va desfasura dupa urmatorul format:
• Fiecare aplicatie va avea 40 de miscari posibil efectuabile in 10 minute.
• Dupa efectuarea unui set de 40 de miscari proiectul respectiv va mai primi inca 5 minute, care se vor fi adaugate la timpul ramas.
  ATENTIE: Daca un program ramane fara timp, dar nu a efectuat inca 40 de miscari, acesta va pierde partida, adversarul fiind declarat castigator.
• Partida ia sfarsit cand oricare din urmatoarele conditii sunt indeplinite:
  1. Ordered List Item Unul dintre proiecte castiga dand sah mat.
  2. Unul dintre proiecte comite o miscare ilegala, adversarul fiind declarat castigator.
  3. Se constata o stare de repetitie (draw by repetition), o stare de imposibilitate de castig (lack of material for either side), prin regula de 50 de miscari (50 move rule) sau daca unul dintre progarme nu dispune de nici o miscare legala, insa nu este in sah (pat). In aceste cazuri se declara partida ca remiza.
• Daca dupa 15 minute nu s-a indeplinit nici o conditie de sfarsit de partida (dupa cum sunt mentionate la punctual anterior) va fi declarat invins programul care intra in criza de timp primul, adeversarul fiind declarat invingator.

Ba da, dar ultima oara a fost acum 4 ani. Atunci proiectul a fost unul de succes, competitia finala fiind una palpitanta. Didactic este o idee de proiect buna din mai multe puncte de vedere (provocari de implementare, intelegerea unor concepte de algoritmi avansati, provocari de time management, abilitatea de autodocumentare, abilitatea de a lucre in echipa etc). Sahul a fost ales datorita rezonantei sale ca joc. Din experienta va spunem ca un motor de sah decent facut da bine la un interviu.

Winboard/Xboard a devenit un program standard de interfatare intre diferitele motoare existente in momentul de fata. Fiecare motor minimalist existent stie sa lucreze cu acest program. Usurarea lucrului de mediere a unui joc justifica implementarea sa, precum si faptul ca proiectul realizat va putea juca cu orice alt motor cat de cat performant de pe net. Cat despre timpul pierdut, interfatarea minimalista ceruta in etapa 1. se poate realiza in aproximativ o ora. La ce chestii vor fi de implementat la protocoale de comunicatii, asta vi se va parea floare la ureche .

Da, exista multe surse de documentatie pe net despre cum sa implementezi un joc de sah. Dar de la vorbe la fapte e cale lunga. Doar pentru ca exista multi algoritmi nu inseamna ca oricine va sti sa-i implementeze si sa o faca si bine. Implementarea corecta si eficienta presupune mai mult decat copy paste de pe net. Cat despre proiectele de anul trecut, ele exista in posesia echipei de PA, si cele de anul acesta vor fi verificate contra celor precedente pentru a nu avea cazuri de frauda. De asemenea codul fiecarui proiect va fi facut public inainte de etapa 5. pentru a putea fi inspectat de fiecare echipa ce doreste sa se asigure ca nu a fost comis vreun act de frauda din partea concurentei. Daca se constata o tentativa de frauda din partea oricarei echipe, toti membrii echipei vor avea restanta la Proiectarea Algoritmilor si vor pierde punctajul aferent proiectului.

Da. Nu.

Cum vrei, pe baza oricaror criterii crezi tu ca sunt importante.

Din experienta anilor trecuti, niciodata nu se intampla ca toti membrii echipei sa lucreze la fel de mult. Acest fapt se intampla din varii motive: fie nu toti pot, fie unul sau doi acapareaza toata munca si nu le dau celorlalti o sansa (nu radeti, s-a intamplat :P), fie <insert another reason here>. Fiecare echipa va avea un capitan care va avea, printre altele, datoria de a comunica echipei de PA (asistentului de laborator, titularului de curs etc) orice neregula din cadrul propriei echipe. In afara de asta si de a vorbi putin individual cu membrii fiecarei echipe nu exista alta solutie. Depinde de prioritatile fiecarui membru de echipa si a echipei per ansamblu.

Depinde…in mod normal responsabilitatile de bun simt ar fi de a imparti eficient munca intre coechipieri, de a face un time management bun, de a lega o strategie de joc etc. Dar mai pot fi si altele, precum PR pe forum .

Pe pagina web a cursului de PA va exista o rubrica de incarcare a codului sursa pentru fiecare etapa dedicata proiectului. Codul sursa, un fisier readme, precum si alte eventuale fisiere aditionale (ex: baze de date pentru deschideri) vor trebui sa vina sub forma unei arhive .zip de forma NumeleEchipei_EtapaX.zip (unde X este numarul etapei curente {1,2,3,4,5}). Fisierul readme va trebui sa contina descrierea succinta a functionalitatilor implementate. Marimea maxima a unei arhive va fi de 5Mb.

In oricare limbaj de programare cu care va intelegeti mai bine. De remarcat este faptul ca pentru acest proiect timpul de executie este critic.

Nu. S-a pus problema si anul trecut. Motivul este ca nu toti stiu sa lucreze cu thread-uri, iar un astfel de avantaj ar fi incorect fata de ceilalti. NU postati in legatura cu asta pe forum…it’s final and that’s that.

Da, atat timp cat toata arhiva este pana in 5Mb.

Categoric NU. Proiectul trebuie sa fie stand-alone. Nu se admit conexiuni de genul celor mentionate mai sus.

Nu. Doar cod sursa (si eventuale aditionale precum opening data bases). Codul se va compila si link-edita dupa regulile prezente in makefile-ul, ant file-ul, script-ul etc-ul vostru de build.

Trimite codul sursa si fisierul de proiect (*.vcproj in caz ca este realizat cu Visual C/C++).

Pe forum-ul dedicat proiectului de pe pagina web a cursului de PA.

[1] - http://en.wikipedia.org/wiki/Rules_of_chess