Melchan
commented
8 years ago Juu huomasin nuo samat asiat mistä mainitsit. Hajoilin kyseistä asiaa demossa. Tästä oppii ja voi tehdä paremmin ensi kerralla. Se että node ei tiedä aikaisempaa ruutua johtuu siitä, että siirroissa palaaminen tapahtuu hieman hassusti, eli palataan siirroissa aina yksi taaksepäin niin ollaan edellisessä siirrossa.
Palaute: Yleisesti suhteellisen helppolukuista koodia, luokat olivat loogisesti nimettyjä ja metodit sopivan pituisia. Huomaan kuitenkin että tallennat joitakin objekteja minulle ei-intuitiivisessa muodossa. Tämä saattaa osittain johtua siitä että käytät uudelleen vanhaa koodia. Huomasin seuraavat "hauskat" ratkaisut: -Nappuloiden väri on RGB-muodossa, vaikka sillä määritetään vain nappulan omistajaa. Myös pelaajan identiteetti on RGB-arvo. -Shakkiruutuja esitellään 1d char array-muodossa, missä kirjain määrittelee onko ruudussa nappula ja mikä se on. Intuitiivisesti käyttäisin 8x8 2d-arrayta ja datatyyppinä vaikka nimettyjä enumeja, jotka ovat tosiaan jo käytössä projektissasi. -Shakkinappulat joiden koodit eivät vastaa mitään määriteltyä tyyppiä ovat "keltaisia" ja vastaava enum on "NOTCHESSPIECE". Tämä kuulostaa epä-standardinmukaiselta exception handlingiltä. Itse asiassa koko ongelma tulee siitä että ruuduissa voi olla ei-määriteltyjä arvoja.
Valitettavasti en ehtinyt perehtyä UCT search algoritmiin tarpeeksi että voisin antaa siitä parannusehdotuksia. Yllätyin kuitenkin siitä miten olet toteuttanut puuta. Oletin että node-luokassa olisi referenssejä child-noodeihin, mutta noodit olivatkin pelkkiä elementtejä hash mapissä.