-
+1
.L'idea è questa: ho un team incompleto e non ho sbatti di finirlo. Come posso completarlo in maniera automatica? Detto fatto. 8)
Nel linguaggio della teoria che si è sviluppata negli anni, un team corrisponde ad una risorsa che si può scegliere, diciamo z. ("risorsa" è un termine generale che ho scelto per indicare qualunque cosa che si possa scegliere o modificare prima delle partite nei vari giochi, quindi i team, ma anche i personaggi dei picchiaduro, o i mazzi di magic...) Lo stato del metagame è composto da una sovrapposizione quantistica di risorse, che più o meno significa descrivere quanto è probabile che in-battle ci si trovi davanti un certo team. Diciamo che lo stato del metagame in un dato istante temporale è y; la cosa figa è che y è calcolabile. Oddio, i calcoli da fare sono immondi, ma si può fare.
A questo punto è possibile estendere la funzione di countering "a%b" che manda due risorse in un numero positivo ad un countering sulle sovrapposizioni quantistiche di risorse, in modo abbastanza intuitivo, ovvero sommando i contributi di ogni risorsa nella sovrapposizione pesata con la probabilità che venga trovata.
Ora, se z rappresenta un team, un team incompleto va scritto in una forma del tipo z=(z*,x), dove z* è noto ed è il pezzo del team che abbiamo messo insieme, ed x è una variabile che percorre i possibili completamenti del team. Se noi scriviamo la funzione che manda x nel numero positivo
f(x) := (z*,x)%y
la x ideale è quella che massimizza f(x). Ora, diciamo che nelle circostanze date (ovvero: c'è solo un numero finito di risorse, seppure altissimo), se guardiamo i dettagli della matematica che sta in gioco esiste un teorema (il teorema di Weierstrass) che ci assicura l'esistenza di questo massimo, quindi esiste almeno un completamento x* che massimizza quel valore lì. E quindi scegliamo quello. Chiaramente se ce n'è più di uno ne scegliamo uno con altri criteri, magari anche di preferenza personale.
Il problema che sussiste è nascosto nelle mie prime righe: lo stato del metagame y è una roba indicibile da calcolare... ma si può fare qualcos'altro. Al posto di prendere il "vero" stato del metagame, prendiamo il nostro team incompleto z* e completiamolo con "nulla", scrivendo (z*,0). A questo punto possiamo prendere l'insieme L(z*) delle risorse che pwnano il nostro team, ovvero contro le quali il team ha un matchup al più neutro:
L(z*) := {x in X : (z*,0)%x =< 1}
quindi prendiamo y come una distribuzione piatta su L(z*), ovvero diciamo che è probabile, con eguale probabilità, incontrare qualunque risorsa di L(z*) ma è impossibile incontrare qualunque risorsa che non stia in L(z*). Chiamiamo y(z*) questa stima dello stato del metagame. A questo punto la funzione
f(x) := (z*,x)%y(z*)
ammette ancora un massimo per un certo completamento x* (non necessariamente unico).
Già scrivendo mi vengono in mente altri modi di dare una stima meno grossolana di y, pesando in modo diverso le risorse a seconda di z*, ma si tratta pur sempre di un metodo costruito esclusivamente con il buonsenso, quindi lungi dall'essere perfetto.
. -
¬Kaos .
User deleted
Però prendere in considerazione L(z*) equivale a finire di buildare il team nella maniera tradizionale, cioè inserendo quegli ultimi uno o due pokè rimasti prestando attenzione alla combinazione fra andamento del meta, usages e major threats, che sarebbe y(z*). Dico questo anche basandomi sul fatto che raramente gli ultimi pokèmon sono inseriti a completamento della propria strategia, che dovrebbe essere imperniata grossomodo sui primi quattro pokè, e, anzi, spesso si limitano ad 'arginare' il meta (motivo per cui ci si ritrova a mettere sempre gli stessi pokè nella parte finale della building phase). La funzione non prende poi in considerazione un parametro a mio parere fra i più importanti (nel senso che, dovendo scegliere fra più candidati agli ultimi slots del proprio team, è il principale parametro di riferimento), cioè la sinergia con il resto del team, sia essa un typing, un U-Turn, un Healing Wish e così via. Pur essendo meno pratiche dei metodi tradizionali, e perciò non avendo una vera utilità pratica, quelle che hai postato sono considerazioni molto affascinanti a livello concettuale, e anche se non ho le conoscenze necessarie per comprendere formule e tecnicità varie ho letto con interesse, gj . -
.
sì è esattamente così, infatti come ho detto y(z*) è solo una stima dello stato del metagame fatta secondo un particolare criterio. il motivo per cui la funzione non considera quelle cose che hai detto è che questo metodo (così come lo stesso metodo applicato ad una qualsiasi stima dello stato del metagame) è valido semplicemente per ogni gioco a risorse, dove i parametri "interni" delle risorse possono essere completamente diversi da quelli che hai descritto.
Se volessimo specializzare il tutto a pkmn non dovrebbe essere troppo difficile inventarsi qualche criterio più ragionato, fine ecc. che prenda più roba in considerazione.. -
¬Kaos .
User deleted
I calcoli sarebbero improponibili però . -
.
non necessariamente. Tu come faresti? Anche se non ci hai pensato basterebbe anche qualche schizzo per costruire qualcosa tutti insieme, la sezione serve a questo e mi fa molto piacere che un nuovo utente fico stia partecipando *_* . -
¬Kaos .
User deleted
Per prima cosa si dovrebbe determinare il parametro della sinergia: la premessa necessaria è che tutti i valori che andrebbero a formare questo parametro sono individuati e ponderati secondo la discrezione di ognuno. Pur non pretendendo di fare un calcolo rigoroso per questo motivo, si potrebbe, in maniera molto grezza, fare la media dei valori di hp, def, sdef dei pokèmon che abbiamo (intendo la statistica finale, non la bs), chiamandola w, e porre un valore k sotto il quale il team è offensivo, sopra difensivo. Da qui mi manca un elemento per andare avanti; non ho la più pallida idea di come mettere sotto forma di formula, in modo da poterla considerare, la tabella di debolezze e resistenze fatta con i pokè da cui siamo partiti, in poche parole questa. Avendo k e questa ipotetica formula (che non sò neanche se possa essere fatta tbh), potremmo fare in modo che i typing individuati come pericolosi siano gestiti in maniera offensiva per k>w, e difensiva all' inverso.
Edit: noto ora che hai già pensato a definire matematicamente il typing in topic precedenti, quindi una funzione del genere potrebbe essere realizzabile. Ciononostante, ci sono molti altri fattori da quantificare, come le coverage o le possibili spread. In tal senso, una formula come quella che ho proposto, fermandosi solo al typing, è veramente irrisoria xD
Edited by ¬Kaos - 22/7/2013, 23:03. -
.
http://pastebin.com/y0bCXwG1 . -
¬Kaos .
User deleted
Non è stato semplice seguire ò.ò
Secondo me, nella parte del fixing del team, andrebbe considerata la pressione che un membro riceve nel suo ruolo di counter, perchè oltre un certo livello collassa chiunque. Per esempio un tom-w che deve entrare su mamo, keldeo, e landorus (che ora è uber ma non mi veniva in mente altro) sostiene troppi ruoli di countering, e se aggiungiamo la mancanza di una recovery affidabile ci rendiamo conto che sarebbe meglio inserire altri check per uno dei tre (o più) mons in modo da allegerire il compito di tom. Mi rendo però conto che si parla di valori di countering basso, vale a dire, per rifarmi a voi, un fearow vs ttar, allora si possono mettere in conto decine, e anche centinaia, di threat, in quanto un valore di countering basso corrisponde, ingame, a scenari contingenti. Quindi per farla breve sarebbe meglio distinguere i pokè del propio team, rispetto a un dato threat, in counters (se possiedono un valore di countering sufficientemente alto), e in checks (valore basso). Cosi si possono denotare situzioni scomode dove ad esempio un pokè è il solo counter di troppi threat, o dove per un threat le risorse di countering sono talmente distribuite fra i teammates che in un qualsiasi 1vs1 al threat basta piazzare un sub o setuppare, portando in negativo le risorse di countering del pokè che gli stà davanti e dei rimanenti, in gergo gg.
Per prevenire scenari del genere basterebbe porre che almeno un pokè in squadra deve possedere una capacità di countering rispetto a un dato threat di x>y, dove y è un tetto che stabiliamo arbitrariamente, e ancora, che un dato pokè nel nostro team dovendo sostenere più di z countering (il valore cambia a seconda che il nostro pokè abbia forme di recovery più o meno buone) nei quali è il solo a offrire una capacità di countering di c>y, deve essere affiancato da teammates che devono offrire capacità di countering di c>y per n counters, dove n-z = un altro tetto stabilito arbitrariamente.
Un' ultima cosa: andrebbe inserita la definizione di rkiller e stabiliti dei valori di rkilling, perchè il discorso del countering interessa principalmente i balanced, stall ecc mentre tipi di team più offensivi non ne traggono più di tanto giovamento. Credo comunque che le considerazioni da fare in proposito siano analoghe a quelle fatte in precedenza per il countering, e quindi non dovrebbe essere troppo difficile scriverci su qualche funzione (anche se io non sono assolutamente capace).
Spero di avervi dato qualche spunto su cui pensare, purtroppo è il massimo che posso fare anche se mi piacerebbe collaborare attivamente
. -
Cinzu .
User deleted
interessante, ma mi sfuggono un paio di cose
esattamente come quantifichi valori come y, y(z*), o anche solo a%b? E in ogni caso in base a cosa determini lo dtato di un metagame?. -
.
y e y(z*) non sono valori numerici, sono "vettori di uno spazio di hilbert", che sono degli oggetti matematici che servono a descrivere robe del genere appunto XD
a%b è un numero che si calcola a seconda del gioco in esame. Proprio la definizione di "%" è intrinseca. Nel caso dei pkmn abbiamo pensato di definire a%b come
a%b := u(a,b)/u(b,a)
dove u(a,b) è il numero di turni che a sopravvive contro b supponendo che b sia immortale.
L'ultima domanda è la più interessante. Lo stato del metagame lo si calcola, date certe condizioni iniziali, tramite un framework fisico/matematico detto teoria quantistica dei campi. E' una roba abbastanza incasinata, ma sostanzialmente pensi alle usage del metagame come delle particelle che si muovono nello spazio delle risorse, e grazie al countering % puoi scrivere delle equazioni che ti permettono di descrivere come queste particelle si muovono ed interagiscono, e con quale probabilità. Esce fuori una formulaccia per calcolare lo stato del metagame, ma almeno è una sola! Solitamente in questo genere di teorie per calcolare le probabilità che avvengano certe interazioni fra particelle ti devi sbattere a studiare il caso particolare, ma le tecniche per farlo sono sempre le stesse.
Le particelle di usage, nella mia teoria, interagiscono in modo molto particolare ma anche molto semplice. Ti faccio un esempio classico; considera elettroni e fotoni. La teoria che ne descrive le interazioni prevede (ed è stato verificato) che ci sono interazioni possibili parecchio varie, basate sull'interazione basilare dove un elettrone emette un fotone (o equivalentemente, un elettrone ed un positrone collidono emettendo un fotone).
Nel caso delle usage questa cosa non succede: le usage passano attraverso altre usage senza collidere o roba del genere. La cosa che rende tutto interessante è che le probabilità di transizione in vari posti dello spazio (= usage poste su risorse diverse) dipende dal luogo dello spazio in cui stai! E' come se tu fossi più massivo a parigi rispetto che qui.
Usando questa proprietà sono riuscito a scrivere una formula esplicita per il calcolo di quello che qua ho chiamato y. y(z*) è definito in modo molto più semplice invece.. -
Cinzu .
User deleted
più o meno credo di aver capito... . -
.
qualsiasi dubbio esprimilo, a me fa piacere spiegare le cose 
. -
Cinzu .
User deleted
no più che altro è tutto molto bello, ma in questi termini rimane più o meno inaccessibile a livello pratico; per chi come me non ha conoscenze abbastanza avanzate da capire quelle forumle cui fai più volte riferimento, intendo. . -
.
ma come, più pratico di così... è un'applicazione diretta della teoria per ricavare un algoritmo di ottimizzazione. di formule ce ne sono poche ma ti spiego volentieri ogni dettaglio, il topic è fatto per questo o.o . -
Cinzu .
User deleted
scusa sono stato assente per un po'...
intendevo che l'algoritmo di ottimizzazione mi sembra una cosa difficile da ricavare; nel senso che il contributo mio (o di chi per me) in questo senso mi pare irrisorio in questa fase, non so se capisci cosa intendo.
Completamento automatico dei teamringraziamo ctw xd |
Web