udg-propro-spring-2020 / projecte-2020-a3

projecte-2020-a3 created by GitHub Classroom
0 stars 1 forks source link

Bloqueig mortal cpu vs cpu, promocionar peça cpu #29

Closed joanplaja closed 4 years ago

joanplaja commented 4 years ago

Bones @miquelbofill

Quan juga cpu vs cpu si el nivell de dificiultat es baix (per exemple nivell 1 mimax) les cpus es quederán en un bloqueig mortal ja que sempre escollira un parell de movimients. Aixo es degut que sino detecta cap possible puntuació major que 0 i totes són 0 sempre escollira la primera en aquest cas. La idea per solucionar aixo és obligar les cpus a jugar amb un nivell mínimin de dificultat.

L'altre tema és promocionar peça, no vaig pensar en comentar-ho quan vam fer la reunió, la meva idea era simplement escollir la millor peça possible de les que es pogui promocionar sempre. No em sona cap requeriment al respecta a l'enunciat i tampoc ales partides que carguem com exemple a la cpu he vist res de escollir una peça concreta per promocionar. Tot i que si s'ha de fer puc pensar algo no hauria de ser cap problema.

Gracies,

miquelbofill commented 4 years ago

un bloqueig mortal ja que sempre escollira un parell de movimients

No sé a què et refereixes amb "bloqueig mortal". En qualsevol cas, estan previstes les taules per inacció (pàgina 8 de l'enunciat).

Pel que respecta a promocionar, jo escolliria la peça de més valor.

joanplaja commented 4 years ago

Cert, perdó em volia referir a que es quedaria tot el rato fent el mateix. D'acord gràcies miquel.

joanplaja commented 4 years ago

Bones @miquelbofill , He estat fent varies proves fins que finalment m'he donat compte del següent: El problema és que cpu vs cpu utilitzar l'actual esquema d'algorisme que tinc és absurd perquè els dos jugaran intentant minimitzar el que poden perdre fins x nivell. Si per exemple tenen els dos una torra que estigui en aquesta situació: image sempre donarà un resultat de 0 i dona la casualitat que comença l'algorisme per les torres encara que hi hagi algun altre moviment que el resultat sigui 0 sino hi ha cap més gran l'algorisme escollirà aquest 0 primer de la torra. Llavors sempre escollirà aquest moviment en les dos maquines. En el nostre cas és bastant propens que passi això ja que el principi de la partida la torra es la primera peça a la llista , potser canviant-ho i que comences la llista per el final no passaria al principi però ho trobo una solució lletxa ja que pot passar més cops. Llavors havia pensat a potser guardar els dos ultimis moviments o tres escollits per la cpu i a l'hora de fer el minMax exclou-rels, també podria ser que al final d'una partida amb poques peçes i una peça acorralada dongues errors però crec que es podria controlar. Fer taules ho veig lletx, llavors el joc no jugaria cpu vs cpu. És difícil d'explicar si no m'he explicat bé podem fer una trucada ràpida quan et vagi bé. Gràcies!.

miquelbofill commented 4 years ago

Hola Joan,

Qualsevol de les solucions que proposes em sembla bé. Una alternativa interessant seria introduir algun factor d'aleatorietat.

De totes maneres no ens hem de preocupar gaire del joc de CPU contra CPU. El més habitual serà humà contra CPU.

joanplaja commented 4 years ago

Miquel acabo d'implementar l'aletoritat. En el primer nivell de l'arbre que és el en el cual s'escull el moviment guardo en una llista tots els moviments de la mateixa puntuació ( la buido si troba una millor i repteixo el procés), i al final a l'hora de escollir el moviment l'escollo aleatoriament de tots els possibles dins la llista. He fet poques proves peró ha millor molt la partida es desenvolupa molt bé i arriben al final molt igualats.

miquelbofill commented 4 years ago

Me n'alegro.