the Diamondcrush Artificial Player, aka A.I.

[jappilas]

Originariamente inviato da Bonfo

Ora mi guardo il codice e vedo cosa posso suggerire.

per adesso sto rifattorizzando l' accrocchio dalla prima versione che Cesare notava essere una lunga catena di if, e la funzione di valutazione e' ora incapsulata in un' interfaccia
quindi l' oggetto EvaluationIteration corrente, o meglio il suo metodo doEvaluation() , se trova le condizioni per alterare la griglia, esegue MiniGrid newGrid = miniGrid.replicate()
applica le modifiche alla nuova istanza (ad es newGrid.remove(originalMiniGrid.getColorRegion(xPosition, yPosition)) )
istanzia nextEvaluationInteration = new DefaultEvaluationIteration(newGrid, xPosition, yPosition.... )
e si chiama nextEvaluationIteration.doEvaluation()
altrimenti chiama this.doEvaluation passando la stessa miniGrid originale e le coordinate del vicino da visitare
...
e' inoltre in fase di scrittura un "subagente" che fornisca la mossa successiva (<move/quarter rotation>, <left/right>) da valutare a seconda dello stato interno
se vuoi ti mando il package in un rar quando torno a casa

In ogni caso, essendo un gioco tra 2 persone a "carte scoperte", direi che si potrebbe usare l'algoritmo MinMax per determinare la mossa migliore
(finalmente l'esame di Intelligenza artificiale viene utile )

mumble mumble, posto che per adesso l' AP valuta "solo" l' effetto della sua mossa sulla propria griglia, come si potrebbe introdurre la valutazione della mossa dell' avversario sulla sua ?

[Bonfo]

Originariamente inviato da jappilas

mumble mumble, posto che per adesso l' AP valuta "solo" l' effetto della sua mossa sulla propria griglia, come si potrebbe introdurre la valutazione della mossa dell' avversario sulla sua ?

Il problema di MinMax è definire lo stato della griglia e valutarlo.
Direi che già una valutazione potrebbe essere la media delle altezze delle colonne della griglia.

Infatti in questo modo:
- se la media è alta -> si sta per perdere
- se la media è bassa -> posso giocare ancora per un po'.

In questo modo si va a valutare lo stato ottenuto applicando le modfiche.
A questo punto vdendo come varia il mio punteggio e il suo cercerò la mossa che minimizza il mio stato e massimizza quello avversario.
Ovvero la mia griglia è vutoa quella dell'avversario è piena

Ovviamente la qualità dell'AI dipende da come si valuta lo stato. Infatti con la valutazione che ho appena proposto l'avversario viene considerato spacciato anche se ha la griglia piena di dimananti e sta per arrivare un chest_diamond ( )

P.S.: ora che ci penso però il gioco non è a turni...quindi non so se Min Max funzia.

[jappilas]

Originariamente inviato da Bonfo

Il problema di MinMax è definire lo stato della griglia e valutarlo. Direi che già una valutazione potrebbe essere la media delle altezze delle colonne della griglia.
Infatti in questo modo:
- se la media è alta -> si sta per perdere
- se la media è bassa -> posso giocare ancora per un po'.

interessante, anche perchè non sarebbe di difficile implementazione, una volta che l' implementazione base è finita: infatti per ora uso un array int[8] per memorizzare le altezze delle prime celle libere, mi serve per "proiettare" sulla griglia la pivot e la gem della pair in arrivo
In questo modo si va a valutare lo stato ottenuto applicando le modifiche - per adesso solo sulla propria griglia però.

A questo punto vedendo come varia il mio punteggio e il suo cercerò la mossa che minimizza il mio stato e massimizza quello avversario.
Ovvero la mia griglia è vuoto quella dell'avversario è piena

tieni anche conto di come calcolo il punteggio: ho una classe per il risultato delle valutazioni

public class EvaluationResult
{
    public int flashCrushChainValue = 0;
    public int chestCrushChainValue = 0;
    public int uncrushedDroppablesValue = 0;
    public int retardedDamageValue = 0;
}

in cui ad ogni iterazione aumento il campo corrispondente al caso esaminato (e qui gli if, mi spiace ma credo che non si potranno togliere in quanto fisiologici a questo livello...), e una struttura di altrettanti pesi corrispondenti, per ottenere il costo finale
Alla fine, se ne potrebbe aggiungere uno, per correlare (in modo pesato a seconda del "profilo" o dello stato dell' AI) l' altezza media della griglia avversaria

P.S.: ora che ci penso però il gioco non è a turni...quindi non so se Min Max funzia.

il gioco non è a turni, ma l' AI / AP "ragiona" a turni
Considera turno il ritorno a un nuovo GemsPairOnControlState, l' immissione di una nuova gemspair da controllare e,
nel caso dell' "advanced agent" la conseguente iterazione per trovare la migliore posizione target e la generazione delle mosse necessarie per ottenerla,
nel caso del naive agent un loop di generazione di mosse che via via migliorino il "valore" della gemspair unita alla griglia, finchè non se ne perde il controllo

Si potrebbe considerare il "turno asincrono" campionando la grid E la pair dell' avversario al momento dell' inizio del turno dell' AP

EDIT: dopo aver letto sul problema del minmax , ho capito che prob ti riferivi al fatto che, tranne che all' inizio, non si ha la certezza di poter giocare a "turni sincronizzati" : cioè applicare uno stesso range di mosse su delle gempair uguali per ambo i giocatori

tra l'altro avevo iniziato a implementare in quel modo l' AP pensando al fatto che in effetti, ogni giocatore gioca per sè al proprio ritmo, e considerando che le uniche interazioni tra le due griglie avvengono quando uno invia o subisce dele stone... da qui l' idea di isolare l' AI il più possibile
non sarebbe impossibile valutare, invece dell' effetto della mossa attuale sulla propria grid e basta, l' effetto della mossa attuale sulla grid correlata all' effetto dell' ultima mossa dell' avversario sulla sua griglia
... ma per ora tengo da parte per una versione advanced agent v2 o Uber Agent

PS: notare che per adesso nulla di quel che riguarda l' interazione concreta con il resto del gioco è implementato,
Per ora l' idea è di focalizzarmi sulla funzione di valutazione cercando di farla funzionare

e al tempo stesso strutturando l' AP il più possibile come una "scatola nera" a cui basterà fornire una Grid, e dire come trasformare le "mosse" generate ad ogni "turno" in KeyEvent, per incastonarla nel gioco
Già tale incastonamento però verrà in seguito e magari non sarò nemmeno io a farlo (per ora il mio obiettivo è il motore di generazione delle mosse, e quando già i suoi componenti saranno dotati di test esaustivi sarò felice, integrarlo in DC a quel punto dovrebbe essere semplice), espansioni all 'AP stesso verranno ancora dopo

[jappilas]

il package "ap" contiene ora codice sia per il naive agent, sia per un advanced agent realizzato come da documento preliminare
cioè con un "move tree" implementato come "array di fattiblità" delle <posizioni target della slave rispetto alla pivot>, che può essere selezionato al volo da tre possibili, e con una funzione di aggiornamento dei "pesi" della funzione di guadagno

quindi, quel che rimane TODO è:
- i test finora lasciati da parte per lo spike, ma cmq fondamentali (urgenti)
- rivedere il code path per la valutazione normale (correggere NormalEvaluationStep.doEvaluation()) (ASAP)
- integrazione con l' environment, con il gridController e la Grid (sostituire i commenti con comandi effettivi per generare KeyEvent) (meno urgente)
- aggiunta di valutazioni più sofisticate, ad es sulla griglia avversaria (in futuro)

per chi volesse vedere in che forma ho accrocchiato le idee che mi giravano in testa, c'è un archivio allegato... fustigatemi pure