the Diamondcrush Artificial Player, aka A.I.

[jappilas]

Dopo aver esposto alcune idee ad alcuni degli amici del team in privato, e aver mostrato ad alcuni di questi un prototipo di codice , mi decido ad aprire un thread apposito per discutere quella che rischia di essere un' aggunta importante per diamonds, al tempo stesso utile (per certe persone che non mi chiedono altro , "vitale") e di non banale implementazione
cioè un "agente" che generi le mosse al posto del secondo giocatore

ora, avrei buttato giù qualche idea nel file di testo allegato (in cui certe parti in effetti abbisognano di completamento e revisione . cosa che faro' asap), in cui è descritta, più che la vera e propria implementazione, una possibile "pipeline" delle operazioni che un "giocatore artificiale" potrebbe fare
e a seconda di tale strutturazione, quali parti e come si prestano ad espansioni e parametrizzazioni (i nomi dei possibili "profili" sono solo a titolo esemplificativo, come è esemplificativo il codice "c" di alcuni passaggi )
sostanzialmente la mia idea sarebbe :
impiegare un oggetto proxy MiniGrid/VirtualGrid, composto di un array statico di celle, con delle flag occupied e un id del tipo di droppable contenuta nella poszione omologa di Grid
quando l' agente ha il controllo sulla gempair, potrebbe o valutare le (4) mosse a disposizione e applicare quella "migliore" o controllare tutte le possibili posizioni target della gempair sulla griglia per poi cercare di "raggiungere" quella ottimale: queste sono le possibili "configurazioni" della pipeline di calcolo , una più semplice, l' altra più complessa e (forse) più "intelligente", ma con maggiore costo computazionale e di sviluppo
per trovare la mossa migliore si userebbe una funzione di valutazione ricorsiva che itererebbe sulla miniGrid/VirtualGrid e restituirebbe dei valori di "vantaggio" , questi verrebbero usati (opzionalmente pesati da coefficienti variabili a seconda dello stato del gioco) per calcolare il "punteggio" della mossa esaminata, tramite quella che è a tutti gli effetti una funzione di ottimalità (ricerca operativa rulez )

per chi volesse visionarlo l' accrocchio non testato e poco OO che al momento (NON) gira sulla mia macchina, verrà inviato sotto forma di file rar

aspetto commenti e idee

ps: ho iniziato a buttare giù del codice perchè avevo inizialmente l' intenzione di impegnarmi in uno spike apposito... ma non sono certo di avere suff tempo e risorse per dedicarmici nei prossimi giorni

[Bonfo]

Bellissima idea...
...ma non ci sarebbe prima altro??

Non so se ti, vi, ci siamo accorti che il progetto ha praticamente il tracciato piatto e che forse nemmeno le features di base saranno implementate?!?

[thebol]

Originariamente inviato da Bonfo

Bellissima idea...
...ma non ci sarebbe prima altro??

Non so se ti, vi, ci siamo accorti che il progetto ha praticamente il tracciato piatto e che forse nemmeno le features di base saranno implementate?!?

sono d'accordo.
Sono convinto che il progetto rimarrà in questo stato fino a settembre(ritorno delle vancanze, etc etc). In questo periodo, piu che scrivere codice o feature grosse(come ia e il multiplayer), sarebbe meglio fare il punto della situazione, contarci e vedere che fare, stabilire delle propietà.

La cosa che mi piacerebbe piu sapere, e se il game designer(aka jocchan) sia ancora disponibile a segurci. Perche il codice si puo anche scrivere in 2 mesi, o 4 mesi o un anno, ma le idee sul gioco, le feature da mettere, non si inventano su 2 piedi.


Anche perche altrimenti, serve qualcuno(o qualcuni) che prenda la responsabilita, l'onere e l'onore di prendere le decisioni.

sempre ovviamente se a qualcuno viene voglia di tornare...


ps.per l'ia...
se dovessi scegliere dove impiegare piu energie, fra ia e multiplayer, voterei la seconda tutta la vita.
Cio non toglie che non si possano sviluppare parallelamente, oppure prima una e poi l'altra.

[jappilas]

Originariamente inviato da Bonfo

Bellissima idea...
...ma non ci sarebbe prima altro??

Non so se ti, vi, ci siamo accorti che il progetto ha praticamente il tracciato piatto e che forse nemmeno le features di base saranno implementate?!?

hai esattamente ragione però c'è da considerare che, per quanto mi riguarda, mettere le mani nelle parti "calde" del codice di DC è una cosa che ultimamente non riesco a fare
non perchè non voglia, tutt' altro, ma perchè in mancanza di una precisa coordinazione ho paura di combinare disastri in codice su cui già sta lavorando qualcun altro , ed anche perchè da qualche tempo trovo molto più difficile di prima, raccapezzarmi in coidce scritto da altri

quindi il mio modo di rendermi utile al progetto ora come ora è studiare fattibilità, eventuali algoritmi, abbozzo di codice eccetera di una sezione del motore di gioco che ancora non è stata valutata

e visto che finora mancano critiche sul tema, continuo con il mio spike sulla funzione di valutazione ricorsiva

Originariamente inviato da thebol

ps.per l'ia...
se dovessi scegliere dove impiegare piu energie, fra ia e multiplayer, voterei la seconda tutta la vita.

sinceramente preferisco il singleplayer con l' Artificial player a occupersi della seconda griglia per un semplice motivo
tenendo due mani sulla tastiera e gli occhi su due griglie, non riesco a fare le prove giocando come vorrei, e finisco per non divertirmi assolutamente

Cio non toglie che non si possano sviluppare parallelamente, oppure prima una e poi l'altra.

è quello che spero

[thebol]

Originariamente inviato da jappilas

hai esattamente ragione però c'è da considerare che, per quanto mi riguarda, mettere le mani nelle parti "calde" del codice di DC è una cosa che ultimamente non riesco a fare
non perchè non voglia, tutt' altro, ma perchè in mancanza di una precisa coordinazione ho paura di combinare disastri in codice su cui già sta lavorando qualcun altro , ed anche perchè da qualche tempo trovo molto più difficile di prima, raccapezzarmi in coidce scritto da altri

quindi il mio modo di rendermi utile al progetto ora come ora è studiare fattibilità, eventuali algoritmi, abbozzo di codice eccetera di una sezione del motore di gioco che ancora non è stata valutata

e visto che finora mancano critiche sul tema, continuo con il mio spike sulla funzione di valutazione ricorsiva

sinceramente preferisco il singleplayer con l' Artificial player a occupersi della seconda griglia per un semplice motivo
tenendo due mani sulla tastiera e gli occhi su due griglie, non riesco a fare le prove giocando come vorrei, e finisco per non divertirmi assolutamente

è quello che spero

per il singleplayer avevo gia proposto di rendere il gioco come era prima. Cioè se una griglia va in game over, l'altra continua. In questa maniera si potrebbero fare piu prove(sarebbe ancora piu carina la possibilita di bloccare una griglia e continuare con l'altra, per testare anche le stone ).

[Bonfo]

Ok.
Vedo che non avete capito la forza con cui ho scritto quel che ho scritto.

Lo sviluppo del gioco è morto!
Ovvero lo sviluppo si è fermato.
Qui non è più questione di cosa ci piacerebbe fare, è questione di fare e nessuno (compreso il sottoscritto) sta facendo.

Ora come ora l'obiettivo è uno e uno solo: dimezzare il codice del gioco.
Ovvero finchè jappy non riuscirà con scioltezza a lavorare con codice altrui bisognerà continuare a semplificare.

Ecco come potresti essere utile jappy: dire sul forum i punti del codice che non capisci e poi, utilizzando il forum per coordinarci, cercare la soluzione più chiare e semplice per tutti.

Non so come altro dirlo: Fek, Joch, Ufo e altri sono spariti...totolamente spariti!!!
E non penso per menefreghismo, anzi spero che ogni tanto un salto per leggere lo facciano, ma perchè non vedevano più possibile andare avanti.
Bene...finchè non si riuscirà a far vedere che si può andare avanti...bhè...non si andrà avanti!!!
(Ostia...che bella frase marzulliana )

Ora torno ai mie BTB e TLB, per non parlare di GDT e LDT.

[jappilas]

tutto corretto, tranne che Ufo, AFAIK non se n'è andato definitivamente, ma è scappato in vacanza in Polonia

però questo thread non voleva essere una copia di quello "Chiusura del Progetto", che ho già letto, e un ripetere le considerazioni già fatte sullo stato del progetto, che già conosco...

avrei potuto non aprirlo e tenere riservata ogni mia considerazione e riga di codice e pseudocodice fino al momento in cui avrei fatto trovare direttamente nel repository il package finito funzionante e testato al 100%...

ho aperto il thread come "cantiere" dedicato a una funzione che probabilmente si dovrà implementare in ogni caso prima della release di dicembre (mancano 5 mesi, può ancora succedere di tutto) e a cui quindi qualcuno avrebbe dovuto mettere mano

quindi pregherei di rispondere a questo thread solo per quanto riguarda l' argomento ...
critiche costruttive al mio algoritmo e alla mia concezione di "generatore di mosse" sono ben accette,
suggerimenti su come semplificare la funzione di valutazione, sulla struttura delle entità coinvolte, pseudo codice, condizioni che l' AP e la sua classe compagna devono soddisfare (su cui modellare est per il TDD) eccetera, ancora meglio
anzi, esorto esplicitamente chiunque legga e abbia delle idee brillanti in proposito, a esporle: tral' altro per come è inteso ora l' AP ha pochi punti di dipendenza dal resto del codice (*)

(*)
una simbiosi tra un oggetto "agente" e un' oggetto MiniGrid, che lo disaccoppia dal resto
l' acoppiata emette coppie <muovi/ruota, sinistra/destra> che verranno solo in seguito convertite in eventi effettivi
quindi non serve una conoscenza approfondita della code base di DC per contribuire idee e algoritmi qui

[cdimauro]

Se Marco non si sente per adesso di partecipare al progetto buttandosi in mezzo a rifattorizzazioni & co. per semplificare il codice (lo sappiamo tutti che è parecchio incasinato, e c'è gente che non vuole cimentarsi proprio per questo motivo), non vedo nulla di male se si dedica a qualcosa di utile per Diamonds: servirà a lui per "farsi le ossa" con Diamonds e la TDD (altrimenti ti spIezziamo le ditine ) e al progetto che guadagnerà qualche utile funzionalità.

Ne ho già avuto modo di discutere con lui in forma privata, per cui non mi dilungo. I punti chiave, IMHO, sono:
- sviluppo in TDD (più si utilizza questo modello, più si entra nell'ottica di scrivere codice in un certo modo; ed è quello che vogliamo / pretendiamo per il codice di Diamonds);
- utilizzo di OOP per eliminare catene di if e quindi codice "getType like" (Alberto, tu che odii visceralmente if & switch, potresti dargli qualche utile consiglio ).

Per il resto, direi di partire da un'IA molto semplice (quella che nel documento viene chiamata "Naive"), che non faccia quindi uso della simulazione dell'evolversi dello stato della griglia, perché diventerebbe troppo oneroso computazionalmente, ma soprattutto complicherebbe il codice (specialmente a questo stadio, senza test che possano evidenziare l'introduzione di eventuali bug nel codice a causa di qualche modifica).

Consiglio a chi può di leggersi il documento ed esprimere, eventualmente, le proprie idee: facciamo diventare questo thread un cantiere in cui scambiare informazioni utili a far proseguire Marco nella stesura del codice, aiutandolo nel prendere maggior confidenza col modello TDD.

Il codice direi di tenerlo separato dal progetto, in assenza di test. Introdurre nuove funzionalità nel codice è possibile e non sono contrario, purché nel pieno rispetto e rigore che ci siamo imposti, che ci consente di tenere sotto controllo il comportamento del codice.

P.S. Forse al momento si potrebbe usare la Grid anziché la miniGrid, non essendo necessaria una simulazione dell'evolversi dello stato della griglia, ma è da valutare: se serve aggiungere altre informazioni oltre a quelle contenute nella griglia, è meglio usarne un "duplicato" per il momento. Non si sa mai.

[VICIUS]

Le idee sono molto buone. Personalmente vorrei vedere implementata la versione avanzata che sia anche in grado di "vedere" griglia, gems pair e altre info dell'avversario. In questo modo si potrebbero implementare altri modificatori un po' più aggressivi.

Ad esempio sapendo che la griglia dell'avevrsario è quasi piena potrebbe decidere di finirlo con una crush... "fatality" . Oppure se le stone stanno per trasformarsi in gemme e nel box della prossima gemspair ci sono dei chest di quel colore decidere di fare un crush per mandare stone e ostacolare l'avversario.

Inoltre non mi pare di aver visto cenni al fatto che le stone dovranno cadere seguendo un pattern prestabilito. L'agente dovrebbe conoscere questo pattern per decidere meglio come disporre le varie gemme in caso di caduta di stone mandate dall'avevrsario.

ciao

[cdimauro]

Via e-mail avevo già parlato con Marco della possibilità di leggere la griglia dell'avversario, quindi considerando il suo stato per valutare le azioni dell'IA.

Buona l'idea di considerare le stone.

Comunque di idee da mettere in cantiere per l'IA ce ne sono tante, ma IMHO sarebbe meglio procedere per piccoli passi, cominciando dall'implementazione più semplice, per poi estendere man mano il modello aggiungendo altri requisiti / funzionalità.

Specialmente nell'ottica di uno sviluppo TD, che dovrebbe seguire Marco, penso che sia la soluzione migliore.

[jappilas]

Originariamente inviato da cdimauro

servirà a lui per "farsi le ossa" con Diamonds e la TDD (altrimenti ti spIezziamo le ditine ) e al progetto che guadagnerà qualche utile funzionalità.

tranqui, ci tengo alle mie ditine

- sviluppo in TDD (più si utilizza questo modello, più si entra nell'ottica di scrivere codice in un certo modo; ed è quello che vogliamo / pretendiamo per il codice di Diamonds);

stanotte ( ) mi sono balenate delle possibili test list , perlomeno riguardanti la minigrid e i passi di valutazione ...

- utilizzo di OOP per eliminare catene di if e quindi codice "getType like" (Alberto, tu che odii visceralmente if & switch, potresti dargli qualche utile consiglio ).

... insieme a un' idea su come ridurre il numero di if attraverso interfaccie MoveSupplier e EvaluateIteration
appena ho tempo, provo a implementarle

Per il resto, direi di partire da un'IA molto semplice (quella che nel documento viene chiamata "Naive"), che non faccia quindi uso della simulazione dell'evolversi dello stato della griglia, perché diventerebbe troppo oneroso computazionalmente, ma soprattutto complicherebbe il codice (specialmente a questo stadio, senza test che possano evidenziare l'introduzione di eventuali bug nel codice a causa di qualche modifica).

ehm, sto scoprendo che il naive agent non e' poi cosi' naive
si' che esplora un subset delle posizioni target e la sua pipeline e' un po' meno versatile mancando il disaccoppiamento tra mossa valutata e mossa da eseguire, ma le problematiche in fase di valutazione (dare un "punteggio" alla mossa, in base a possibilita' di crush , vicinanza tra gemme di stesso colore ecc) sono piu' o meno le stesse
certo, per ora posso prendere in esame solo un subset dei possibili casi e ad es non effettuare simulazione delle crush (posso pero' vedere se il piu' prossimo "vicino" superiore e' tale da innescare una crush, cioe' chest contro chest o gem contro chest)

l' alternativa davvero piu' naive (e anche la meno prevedibile ) esarebbe un generatore casuale di mosse

Consiglio a chi può di leggersi il documento ed esprimere, eventualmente, le proprie idee: facciamo diventare questo thread un cantiere in cui scambiare informazioni utili a far proseguire Marco nella stesura del codice, aiutandolo nel prendere maggior confidenza col modello TDD.

la mia difficolta' era essenzialmente capire come modellare dei test formali per qualcosa che all' esterno apparirebbe come una scatola nera euristica
ma mi sono reso conto che si dovrebbe poter fare strutturando il piu' possibile l' accrocchio per "mattoncini" ciascuno testabile e controllabile per conto suo

Il codice direi di tenerlo separato dal progetto, in assenza di test. Introdurre nuove funzionalità nel codice è possibile e non sono contrario, purché nel pieno rispetto e rigore che ci siamo imposti, che ci consente di tenere sotto controllo il comportamento del codice.

I test comunque arriveranno asap , appena usciro' dallo spike mode (e dagli esami ) per entrare in official mode

P.S. Forse al momento si potrebbe usare la Grid anziché la miniGrid, non essendo necessaria una simulazione dell'evolversi dello stato della griglia, ma è da valutare: se serve aggiungere altre informazioni oltre a quelle contenute nella griglia, è meglio usarne un "duplicato" per il momento. Non si sa mai.

piu' che altro, l' oggetto proxy mi viene bene perche' posso dotarlo di metodi di utilita' che Grid non ha, come getNearestAboveNeighBour(MiniGridCell visitedCell) e getNeighbourTriad(MiniGridCell visitedCell) e, usando un array statico di elelemti <type, isOccupied> mantenere al tempo stesso basso il costo computazionale rispetto a quello che si avrebbe se dovessi iterare la DroppableList di Grid per ad es trovare i vicini di una cella...
per me e' piu' semplice lavorare in qs modo, (anche perche' si riducono i punti di contatto tra l' agente e il codice attuale) ma capisco per un altro possa essere diverso...

[jappilas]

Originariamente inviato da VICIUS

Ad esempio sapendo che la griglia dell'avevrsario è quasi piena potrebbe decidere di finirlo con una crush... "fatality" .

griglia avversaria quasi piena = desperation move available (per l' avversario)
quando ci saranno le desperation move, basta notificare al player /agent avversario che la DP e' attiva, questo potra' reagire con un priority shift tipo "max_damage + acceleratedDrop"

Oppure se le stone stanno per trasformarsi in gemme e nel box della prossima gemspair ci sono dei chest di quel colore decidere di fare un crush per mandare stone e ostacolare l'avversario.

per adesso prendo in esame stone contro chest e aumento il sub parametro MoveScore.retardedDamageScore... per fare una cosa raffinata si puo' aumentare questo parametro di un valore non fisso ma variabile in base allo stone turn

Inoltre non mi pare di aver visto cenni al fatto che le stone dovranno cadere seguendo un pattern prestabilito. L'agente dovrebbe conoscere questo pattern per decidere meglio come disporre le varie gemme in caso di caduta di stone mandate dall'avevrsario.

forse non e' indispensabile, basta avere un priority shift quando si attiva la "danger box" .. tieni conto che tanto le stones verranno "ricampionate" nella MiniGrid al turno successivo la loro caduta

[VICIUS]

Originariamente inviato da jappilas

griglia avversaria quasi piena = desperation move available (per l' avversario)
quando ci saranno le desperation move, basta notificare al player /agent avversario che la DP e' attiva, questo potra' reagire con un priority shift tipo "max_damage + acceleratedDrop"

Non sono del tutto convinto. Demandare all'avversario la notifica richiede l'implementazione di un qualche algoritmo nella grid normale che decida quando un giocatore umano è in difficolta, perché non possiamo pretedendere che il giocatore spinga un tasto per inviare il messaggio. Inoltre non vorrei vedere del codice che riguarda l'ai all'interno di Grid, non è il suo posto.
Se invece è l'ia a stimare quando il suo avevrsario è in difficolta e puo finirlo possiamo avere il controllo sulla precisione con cui riesce a uccidere il nemico in base al livello di difficolta.

Originariamente inviato da jappilas

forse non e' indispensabile, basta avere un priority shift quando si attiva la "danger box" .. tieni conto che tanto le stones verranno "ricampionate" nella MiniGrid al turno successivo la loro caduta

La mia era solo un idea per far replicare una mia abitudine. Sia con spf2t che con dc mi sono imparato i vari pattern con cui cadono le stone. Quando dispongo le gemme normali e i chest tengo in considerazione i colori che cadranno in futuro cosi da avvantaggiarmi anche delle stone quando si trasformeranno in gemme.

ciao

[thebol]

Originariamente inviato da VICIUS

Sia con spf2t che con dc mi sono imparato i vari pattern con cui cadono le stone. Quando dispongo le gemme normali e i chest tengo in considerazione i colori che cadranno in futuro cosi da avvantaggiarmi anche delle stone quando si trasformeranno in gemme.

ciao

OT
non sarebbe carino far resettare il pattern se non ci sono stone nella griglia?
Anche se il ricordarsi il pattern potrebbe essere considerata una skill

[Bonfo]

Scusate.
Non volevo assolutamente offenedere o attacare nessuno.

Quoto semplicemente me stesso:

Originariamente inviato da Bonfo

Bellissima idea...
...ma non ci sarebbe prima altro??

Ovvero: la cose è BELLISSIMA e mi ci vorrei buttare a capo fitto pure io se non fossi sotto esami.
Ma purtroppo ora come ora il progetto ha delle priorità e non so quanto sia saggio "consumare" energie per attività a bassa priorità.

Quindi, ottimo spike ma se ho tempo di codare su Diamonds lavoro sulle parti che bloccano il progetto.
Tutto qui...
Non mi picchiate

P.S.: ripeto...non voglio offendere nessuno

[jappilas]

Originariamente inviato da Bonfo

P.S.: ripeto...non voglio offendere nessuno

tranquillo nessuno si offende
dicevo solo che per quanto mi riguarda preferivo tenere questo thread più pulito possibile per tenerlo come punto di riferimento per lo sviluppo di questo "sottosistema" del gioco
e che, poichè ora come ora, non riesco a imbarcarmi nei refactoring necessari di cui gli altri si stanno occupando (mi occorrerebbe ristudiarmi le parti di test e codice relative, cosa che non riesco a fare) aggiungere quando posso idee e righe di codice a questa parte di programma, per "fissarle" prima di dimenticarmene, è il mio modo di essere utile a diamonds... mal che vada, quando il progetto tornerà a regime e l' AI sarà implementata in pompa magna , non si dovrà partire da "zero"...
per quello dicevo, chi ha idee, test, pseudocodice, specifiche, algoritmi, whatever, esponga qui... appena ho un momento prima di essere teletrasportato via, provo ad aggungere

cmq per ora sono alla funzione di esplorazione ricorsiva, prima si finisce quella poi è tutta discesa

[jappilas]

Originariamente inviato da VICIUS

Non sono del tutto convinto. Demandare all'avversario la notifica richiede l'implementazione di un qualche algoritmo nella grid normale
....

ciao

ti g' ha rason, non l' avevo considerato
forse si potrebbe agguingere una seconda minigrid e valutare l' array delle "altezze delle prime celle disponibili" anche su quella dell' avversario a ogni turno

[cdimauro]

Originariamente inviato da jappilas

ehm, sto scoprendo che il naive agent non e' poi cosi' naive
si' che esplora un subset delle posizioni target e la sua pipeline e' un po' meno versatile mancando il disaccoppiamento tra mossa valutata e mossa da eseguire, ma le problematiche in fase di valutazione (dare un "punteggio" alla mossa, in base a possibilita' di crush , vicinanza tra gemme di stesso colore ecc) sono piu' o meno le stesse
certo, per ora posso prendere in esame solo un subset dei possibili casi e ad es non effettuare simulazione delle crush (posso pero' vedere se il piu' prossimo "vicino" superiore e' tale da innescare una crush, cioe' chest contro chest o gem contro chest)

E' una buona soluzione.

l' alternativa davvero piu' naive (e anche la meno prevedibile ) esarebbe un generatore casuale di mosse

Meglio di no: non cambierebbe poi tanto dalla situazione attuale.

la mia difficolta' era essenzialmente capire come modellare dei test formali per qualcosa che all' esterno apparirebbe come una scatola nera euristica ma mi sono reso conto che si dovrebbe poter fare strutturando il piu' possibile l' accrocchio per "mattoncini" ciascuno testabile e controllabile per conto suo

Se per "mattoncini" intendi dei pezzi di codice / funzionalità, va benissimo.

I test comunque arriveranno asap , appena usciro' dallo spike mode (e dagli esami ) per entrare in official mode

Anche perché l'official mode prevede l'introduzione di codice testato (anzi, prima i test e poi il codice ), pena la fustigazione.

piu' che altro, l' oggetto proxy mi viene bene perche' posso dotarlo di metodi di utilita' che Grid non ha, come getNearestAboveNeighBour(MiniGridCell visitedCell) e getNeighbourTriad(MiniGridCell visitedCell) e, usando un array statico di elelemti <type, isOccupied> mantenere al tempo stesso basso il costo computazionale rispetto a quello che si avrebbe se dovessi iterare la DroppableList di Grid per ad es trovare i vicini di una cella...
per me e' piu' semplice lavorare in qs modo, (anche perche' si riducono i punti di contatto tra l' agente e il codice attuale) ma capisco per un altro possa essere diverso...

No guarda, non c'è problema: di estendere la griglia al momento non se ne parla, per cui se ritieni che ti servano degli strumenti migliori, la soluzione della miniGrid AI-oriented è ottima.

[cdimauro]

Originariamente inviato da Bonfo

Ovvero: la cose è BELLISSIMA e mi ci vorrei buttare a capo fitto pure io se non fossi sotto esami.
Ma purtroppo ora come ora il progetto ha delle priorità e non so quanto sia saggio "consumare" energie per attività a bassa priorità.

Quindi, ottimo spike ma se ho tempo di codare su Diamonds lavoro sulle parti che bloccano il progetto.

Tranquillo Valerio: nessuno ti ha chiesto di partecipare attivamente alla stesura del codice dell'IA.

Questo thread è nato per dare semplicemente dei suggerimenti a Marco per implementare una prima forma di IA per Diamonds.

Le uniche energie richieste sono quelle della lettura del thread ed eventuali indicazioni che possono essere utili ai fini dell'implementazione del codice.

So bene che per adesso abbiamo altre priorità, ma Marco può procedere anche da solo.
Anche perché, come lui stesso ha affermato, per il momento non si sente di partecipare a rifattorizzazioni et similia, ma visto che tiene al progetto e vuol partecipare in qualche modo, lasciamolo lavorare a qualcosa che per lui è più abbordabile, e che gli permetterà di "farsi le ossa" con TDD & co.
Così più avanti potrà partecipare ai task come tutti gli altri.

[Bonfo]

Originariamente inviato da cdimauro

Tranquillo Valerio: nessuno ti ha chiesto di partecipare attivamente alla stesura del codice dell'IA.

Questo thread è nato per dare semplicemente dei suggerimenti a Marco per implementare una prima forma di IA per Diamonds.

Le uniche energie richieste sono quelle della lettura del thread ed eventuali indicazioni che possono essere utili ai fini dell'implementazione del codice.

So bene che per adesso abbiamo altre priorità, ma Marco può procedere anche da solo.
Anche perché, come lui stesso ha affermato, per il momento non si sente di partecipare a rifattorizzazioni et similia, ma visto che tiene al progetto e vuol partecipare in qualche modo, lasciamolo lavorare a qualcosa che per lui è più abbordabile, e che gli permetterà di "farsi le ossa" con TDD & co.
Così più avanti potrà partecipare ai task come tutti gli altri.

L'io era nel senso di voi
In ogni caso hia ragion e...Marco può e deve fare tutto quello che3 ritiene utile per diamonds in tutti i modi che può.

Ora mi guardo il codice e vedo cosa posso suggerire.
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 )