Dubtes,Aclaracions i ideas classes CPU i Coneixement

[joanplaja]

Aclariments: Actualment la idea és fer un coneixement simple que serveixi per a la primera versió d'escacs que volem implementar (un joc normal) sense tenir en compte regles diferents per tant a la classe coneixement he optat per fer un map<Escacs,Node>;; la qual per cada situació del tauler tingui un conjunt de nodes encadenats de les tirades a realitzar. Per fer que el map sigui la clau Escacs haurem d'implementar els mètodes HashCode i Equals.

Dubtes:

1. Relacionat amb el d'abans em costa veure com fer perquè sigui un graf com has comentat algun cop. També veig que el meu plantejament te fallos, ja que potser tindrem situacions de tauler que poden tenir més d'una opció(nodes). Per tant nose si seria una bona idea que el node encontes de tenir un node següent tingui un conjunt de nodes següents. Si ho faig d'aquesta forma potser també hauria de guardar els nodes en algun lloc a part per saber si existeix i en el cas que existeixi relaciona la situació d'escacs amb aquell node.
2. També a l'hora de guardar el coneixement a part de guardar la situació inicial amb el seu conjunt de nodes penso que en cada tirada del coneixement que entri hauria de guardar la situació de com queda llavors el tauler i els seus nodes següents.
3. Dubto de moment de com guardar correctament perquè a l'hora de buscar dins el coneixement no hi hagi problema sigui blanques o negres, ja que els taulers seran diferents.

Idees: Pel tema del backtarcking quan no troba cap coneixement el qual seguir he pensat utilitzar un algorisme anomenat minMax la idea principal és no anar al final de l'arbre on puc guanyar més punts sinó que anar cap a la direcció on em puguin treure menys punts també amb certes formes per tallar l'arbre el màxim possible.

[miquelbofill]

Joan, se'm fa molt difícil d'entendre, i per tant de respondre, si no defineixes què és un Escacs i què és un Node. Si no m'equivoco, en el vostre disseny no apareixia res d'això. Per tal de decidir quina és l'estructura de dades més adequada, abans hem de saber quines operacions volem fer. Per tant aquest map que comentes pel que a mi respecta el deixo en quarentena.

Pel que respecta als dubtes:

1. Vaig comentar que el coneixement potser es podria imaginar com un graf de taulers, connectats per jugades, en el sentit que podem passar d'una configuració de tauler a una altra fent una jugada. Com sempre, convé definir bé primer les operacions i després pensar en l'estructura de dades més adequada per donar-hi suport.

2. Mitjançant la situació actual i la jugada, es pot deduir la situació resultant mitjançant les regles. Per tant és suficient guardar la situació inicial i la seqüència de jugades. Per això el format del fitxer JSON és com és. Ara bé, internament el teu programa pot guardar el que creguis convenient.

3. És normal que dubtis. Precisament això confirma el que predico sempre: decidir com guardar les coses prematurament no és bo, perquè fàcilment prendràs decisions equivocades basades en una anàlisi poc acurada. Ja ho decidiràs més endavant. Pensa primer en les operacions, què han de rebre com a paràmetre, què han de retornar... i llavors veuràs més clar com convé guardar les coses.

L'algorisme de Minimax és un bon candidat.

[joanplaja]

Miquel quan he escrit l'issue em m'estava referint al codi que ja tenim penjat. Allà tinc coneixament(node dins) i cpu defint també hi ha Escacs.Potser mires la documentacio o esquema que tenim actualment i hauriem de actualitzaro alla primer abans de fer codi.

[miquelbofill]

D'acord. Ara ho veig. No n'estava al cas. De totes maneres, la meva resposta seria més o menys la mateixa:

1. Aclarir bé quin concepte representa cada classe d'objecte (fer l'esforç de fer-ne una descripció general i abstracta).
2. Definir amb precisió les operacions sense implementar-les.
3. Començar a implementar les operacions, al mateix temps que es determinen les estructures de dades més adequades per emmagatzemar les dades.

PD No cal pas que actualitzeu el primer lliurament. Podeu anar fent directament codi i documentació Doxygen.