Necessità di un generatore casuale prevedibile

Sono uno sviluppatore di giochi Web e ho un problema con i numeri casuali. Diciamo che un giocatore ha il 20% di probabilità di ottenere un colpo critico con la sua spada. Ciò significa che 1 colpo su 5 dovrebbe essere critico. Il problema è che ho ottenuto risultati molto negativi nella vita reale - a volte i giocatori ottengono 3 punti critici in 5 colpi, a volte nessuno in 15 colpi. Le battaglie sono piuttosto brevi (3-10 colpi), quindi è importante ottenere una buona distribuzione casuale.

Attualmente uso PHP mt_rand(), ma stiamo semplicemente spostando il nostro codice in C ++, quindi voglio risolvere questo problema nel nuovo motore del nostro gioco.

Non so se la soluzione sia un generatore casuale uniforme, o forse ricordare i precedenti stati casuali per forzare una corretta distribuzione.

Concordo con le risposte precedenti che la casualità reale in piccole tirature di alcuni giochi è indesiderabile - sembra troppo ingiusta per alcuni casi d'uso.

Ho scritto una semplice Shuffle Bag come l'implementazione in Ruby e ho fatto alcuni test. L'implementazione ha fatto questo:

• Se sembra ancora giusto o non abbiamo raggiunto la soglia dei tiri minimi, restituisce un colpo giusto in base alla probabilità normale.
• Se la probabilità osservata dai lanci precedenti la fa sembrare ingiusta, restituisce un colpo "equo e solidale".

È ritenuto ingiusto in base alle probabilità al contorno. Ad esempio, per una probabilità del 20%, è possibile impostare il 10% come limite inferiore e il 40% come limite superiore.

Usando quei limiti, ho scoperto che con esecuzioni di 10 hit, il 14,2% delle volte la vera implementazione pseudocasuale ha prodotto risultati che erano fuori dai limiti . Circa l'11% delle volte, sono stati segnati 0 colpi critici in 10 tentativi. Il 3,3% delle volte, 5 o più colpi critici sono stati sbarcati su 10. Naturalmente, usando questo algoritmo (con un conteggio minimo dei tiri di 5), una quantità molto più piccola (0,03%) delle corse "Fairish" era fuori limite . Anche se l'implementazione di seguito non è adatta (si possono fare cose più intelligenti, certamente), vale la pena notare che, in particolare, gli utenti ritengono spesso che sia ingiusto con una vera soluzione pseudocasuale.

Ecco la mia carne FairishBagscritta in Ruby. L'intera implementazione e la rapida simulazione Monte Carlo sono disponibili qui (in sintesi) .

def fire!
  hit = if @rolls >= @min_rolls && observed_probability > @unfair_high
    false
  elsif @rolls >= @min_rolls && observed_probability < @unfair_low
    true
  else
    rand <= @probability
  end
  @hits += 1 if hit
  @rolls += 1
  return hit
end

def observed_probability
  @hits.to_f / @rolls
end

Aggiornamento: l' uso di questo metodo aumenta la probabilità complessiva di ottenere un colpo critico, a circa il 22% usando i limiti sopra. Puoi compensare impostando la sua probabilità "reale" un po 'più in basso. Una probabilità del 17,5% con la modifica equa produce una probabilità osservata a lungo termine di circa il 20% e mantiene le corse a breve termine corrette.

Ciò significa che 1 colpo su 5 dovrebbe essere critico. Il problema è che ho ottenuto risultati molto negativi nella vita reale - a volte i giocatori ottengono 3 punti critici in 5 colpi, a volte nessuno in 15 colpi.

Ciò di cui hai bisogno è una borsa shuffle . Risolve il problema del fatto che il vero casuale è troppo casuale per i giochi.

L'algoritmo è in questo modo: metti 1 colpi critici e 4 non critici in un sacchetto. Quindi randomizzi il loro ordine nella borsa e li prendi uno alla volta. Quando il sacchetto è vuoto, lo si riempie di nuovo con gli stessi valori e lo si randomizza. In questo modo otterrai in media 1 colpo critico per 5 colpi, e al massimo 2 colpi critici e 8 colpi non critici di fila. Aumenta il numero di oggetti nella borsa per una maggiore casualità.

Ecco un esempio di implementazione (in Java) e dei suoi casi di test che ho scritto qualche tempo fa.

Hai frainteso cosa significhi random.

Quale di questi è più casuale?

Mentre la seconda trama sembra distribuita in modo più uniforme, più casuale è in realtà la prima trama. La mente umana vede spesso schemi nella casualità, quindi vediamo i gruppi nella prima trama come schemi, ma non lo sono - fanno solo parte di un campione selezionato casualmente.

Dato il comportamento che stai chiedendo, penso che stai randomizzando la variabile sbagliata.

Piuttosto che randomizzare se questo colpo sarà critico, prova a randomizzare il numero di turni fino al prossimo colpo critico. Ad esempio, basta scegliere un numero compreso tra 2 e 9 ogni volta che il giocatore ottiene un critico, quindi dare loro il prossimo critico dopo che sono trascorsi molti round. Puoi anche usare i metodi dei dadi per avvicinarti a una distribuzione normale - per esempio, otterrai il tuo prossimo critico in turni 2D4.

Credo che questa tecnica venga utilizzata nei giochi di ruolo che hanno incontri casuali anche nell'overworld: randomizzi un contapassi e dopo tanti passaggi, verrai colpito di nuovo. Sembra molto più giusto perché non vieni quasi mai colpito da due incontri di fila - se ciò accade anche una volta, i giocatori diventano irritabili.

Innanzitutto, definire una distribuzione "corretta". I numeri casuali sono, beh, casuali: i risultati che stai vedendo sono del tutto coerenti con la (pseudo) casualità.

Espandendo su questo, suppongo che ciò che vuoi sia una sensazione di "correttezza", quindi l'utente non può fare 100 giri senza successo. In tal caso, terrei traccia del numero di guasti dall'ultimo successo e pondererei il risultato generato. Supponiamo che tu voglia 1 tiri su 5 per "riuscire". Quindi generi casualmente un numero da 1 a 5, e se è 5, ottimo.

In caso contrario, registra l'errore e la prossima volta genera un numero da 1 a 5, ma aggiungi, ad esempio, floor (numFailures / 2). Quindi, questa volta, hanno ancora una probabilità 1 su 5. Se falliscono, la prossima volta l'intervallo vincente è 4 e 5; una probabilità di successo 2 su 5. Con queste scelte, dopo 8 fallimenti, hanno sicuramente successo.

Che ne dici di sostituire mt_rand () con qualcosa del genere?

(RFC 1149.5 specifica 4 come numero casuale verificato IEEE standard.)

Da XKCD .

Speriamo che questo articolo ti possa aiutare: http://web.archive.org/web/20090103063439/http://www.gamedev.net:80/reference/design/features/randomness/

Questo metodo di generazione di "numeri casuali" è comune nei giochi rpg / mmorpg.

Il problema che risolve è questo (estratto):

Un ragno a lama è alla gola. Colpisce e ti manca. Colpisce di nuovo e ti manca di nuovo. E ancora e ancora, fino a quando non ti rimane più niente da colpire. Sei morto e c'è un aracnide di due tonnellate che gongola sul tuo cadavere. Impossibile? No. Improbabile? Sì. Ma dato abbastanza giocatori e abbastanza tempo, l'improbabile diventa quasi certo. Non era che il ragno della lama fosse duro, era solo sfortuna. Che frustrante. È abbastanza per far smettere un giocatore.

Quello che vuoi non sono numeri casuali, ma numeri che sembrano casuali a un essere umano. Altri hanno già suggerito singoli algoritmi, che possono aiutarti, come Shuffle Bad.

Per una buona analisi dettagliata ed estesa di questo dominio vedi AI Game Programming Wisdom 2 . Vale la pena leggere l'intero libro per qualsiasi sviluppatore di giochi, l'idea di "numeri apparentemente casuali" è trattata nel capitolo:

Casualità filtrata per decisioni AI e logica di gioco :

Riassunto: la saggezza convenzionale suggerisce che migliore è il generatore di numeri casuali, più imprevedibile sarà il tuo gioco. Tuttavia, secondo gli studi di psicologia, la vera casualità a breve termine spesso sembra decisamente non casuale per l'uomo. Questo articolo mostra come rendere le decisioni casuali sull'IA e la logica di gioco più casuali per i giocatori, pur mantenendo una forte casualità statistica.

Potresti anche trovare interessante un altro capitolo:

Le statistiche dei numeri casuali

Riassunto: i numeri casuali sono utilizzati principalmente dall'intelligenza artificiale e dai giochi in generale. Ignorare il loro potenziale è rendere il gioco prevedibile e noioso. Usarli in modo errato può essere altrettanto grave che ignorarli apertamente. Comprendere come vengono generati i numeri casuali, i loro limiti e le loro capacità, può rimuovere molte difficoltà nell'utilizzarli nel gioco. Questo articolo offre informazioni su numeri casuali, la loro generazione e metodi per separare quelli buoni da quelli cattivi.

Sicuramente qualsiasi generazione di numeri casuali ha la possibilità di produrre tali tiri? Non otterrai un set di campioni abbastanza grande in 3-10 rotoli per vedere le percentuali appropriate.

Forse quello che vuoi è una soglia di misericordia ... ricorda gli ultimi 10 tiri, e se non hanno avuto un colpo critico, dai loro un omaggio. Appianare le imbragature e le frecce della casualità.

La tua soluzione migliore potrebbe essere testare il gioco con più schemi diversi non casuali e scegliere quello che rende i giocatori più felici.

Puoi anche provare una politica di back-off per lo stesso numero in un dato incontro, ad esempio, se un giocatore lancia un 1al primo turno, accettalo. Per ottenerne un altro 1devono tirare 2 1s di fila. Per ottenere un terzo 1hanno bisogno di 3 di fila, all'infinito.

Sfortunatamente quello che stai chiedendo è effettivamente un generatore di numeri non casuale, perché vuoi che i risultati precedenti siano presi in considerazione quando determini il numero successivo. Temo che non sia così che funzionano i generatori di numeri casuali.

Se vuoi che 1 colpo su 5 sia critico, scegli semplicemente un numero compreso tra 1 e 5 e dì che quel colpo sarà critico.

mt_rand () si basa su un'implementazione di Mersenne Twister , il che significa che produce una delle migliori distribuzioni casuali che puoi ottenere.

Apparentemente ciò che vuoi non è affatto casualità, quindi dovresti iniziare specificando esattamente cosa vuoi. Probabilmente ti renderai conto di avere aspettative contrastanti - che i risultati dovrebbero essere davvero casuali e non prevedibili, ma allo stesso tempo non dovrebbero mostrare variazioni locali rispetto alla probabilità dichiarata - ma poi diventerà prevedibile. Se imposti un massimo di 10 non-crits di seguito, allora hai appena detto ai giocatori "se hai avuto 9 non-crits di seguito, il prossimo sarà critico con certezza al 100%" - potresti beh, non preoccuparti affatto della casualità.

Su un numero così piccolo di test dovresti aspettarti risultati del genere:

La vera casualità è prevedibile solo su dimensioni enormi, in modo tale che è possibile lanciare una moneta e ottenere teste 3 volte di fila per la prima volta, tuttavia oltre qualche milione di lanci si arriva a circa 50-50.

Vedo molte risposte che suggeriscono di tenere traccia dei numeri precedentemente generati o di mescolare tutti i possibili valori.

Personalmente, non sono d'accordo, il fatto che 3 crits di seguito siano cattivi. Né sono d'accordo sul fatto che 15 non-crits di fila siano cattivi.

Vorrei risolvere il problema, modificando la possibilità critica stessa, dopo ogni numero. Esempio (per dimostrare l'idea):

int base_chance = 20;
int current_chance = base_chance;

int hit = generate_random_number(0, 100) + 1; // anything from 1 to 100
if(hit < current_chance)//Or whatever method you use to check
{
    //crit!
    if(current_chance > base_chance)
        current_chance = base_chance; // reset the chance.
    else
        current_chance *= 0.8; // decrease the crit chance for the NEXT hit.
}
else
{
    //no crit.
    if(current_chance < base_chance)
        current_chance = base_chance; // reset the chance.
    else
        current_chance *= 1.1; // increase the crit chance for the NEXT hit.
    //raise the current_chance
}

Più a lungo non ottieni un critico, maggiori sono le possibilità che hai per la tua prossima azione. Il ripristino che ho incluso è del tutto facoltativo e avrebbe bisogno di essere testato per capire se è necessario o meno. Può essere o meno desiderabile dare una maggiore probabilità di un critico per più di un'azione di seguito, dopo una lunga catena di azioni non critiche.

Sto solo gettando i miei 2 centesimi ...

Le prime poche risposte sono grandi spiegazioni, quindi mi concentrerò solo su un algoritmo che ti dà il controllo sulla probabilità di "serie errate" senza diventare mai deterministico. Ecco cosa penso che dovresti fare:

Invece di specificare p , il parametro di una distribuzione di Bernoulli, che è la vostra probabilità di un colpo critico, specificare un e b , i parametri della distribuzione beta, il "coniugato prima" della distribuzione di Bernoulli. Devi tenere traccia di A e B , il numero di colpi critici e non critici finora.

Ora, per specificare un e b , in modo che a / (a + b) = p, la probabilità di un colpo critico. La cosa bella è che (a + b) quantifica quanto vuoi che A / (A + B) sia p in generale.

Fai il tuo campionamento in questo modo:

lascia che p(x)sia la funzione di densità di probabilità della distribuzione beta. È disponibile in molti luoghi, ma puoi trovarlo nella GSL come gsl_ran_beta_pdf.

S = A+B+1
p_1 = p((A+1)/S)
p_2 = p(A/S)

Scegli un colpo critico campionando da una distribuzione di bernoulli con probabilità p_1 / (p_1 + p_2)

Se si scopre che i numeri casuali hanno troppi "cattivi striature", scalare una e B , ma al limite, come un e b andare all'infinito, si avrà l'approccio sacchetto casuale descritto in precedenza.

Se lo implementate, per favore fatemi sapere come va!

Se si desidera una distribuzione che scoraggi i valori di ripetizione, è possibile utilizzare un semplice algoritmo di rifiuto della ripetizione.

per esempio

int GetRand(int nSize)
{
    return 1 + (::rand() % nSize);
}
int GetDice()
{
    static int nPrevious=-1;
    while (1) {
        int nValue = GetRand(6);
        // only allow repeat 5% of the time
        if (nValue==nPrevious && GetRand(100)<95)
            continue;
        nPrevious = nValue;
        return nValue;
    }
}

Questo codice rifiuta i valori di ripetizione il 95% delle volte, rendendo le ripetizioni improbabili ma non impossibili. Statisticamente è un po 'brutto, ma probabilmente produrrà i risultati desiderati. Naturalmente, non impedirà una distribuzione come "5 4 5 4 5". Potresti diventare più fantasioso e rifiutare il secondo ultimo (diciamo) il 60% delle volte e il terzo ultimo (diciamo) il 30%.

Non sto raccomandando questo come un buon design del gioco. Semplicemente suggerendo come ottenere ciò che vuoi.

Non è davvero chiaro quello che vuoi. È possibile creare una funzione in modo tale che le prime 5 volte che la si chiama, restituisca i numeri 1-5 in un ordine casuale.

Ma non è davvero casuale. Il giocatore saprà che otterrà esattamente un 5 nei prossimi 5 attacchi. Potrebbe essere quello che vuoi, e in quel caso, devi semplicemente codificarlo da solo. (crea un array contenente i numeri e poi mescolali)

In alternativa, puoi continuare a utilizzare il tuo approccio attuale e supporre che i tuoi risultati attuali siano dovuti a un cattivo generatore casuale. Nota che nulla può essere sbagliato con i tuoi numeri attuali. I valori casuali sono casuali. a volte ottieni 2, 3 o 8 dello stesso valore in una riga. Perché sono casuali. Un buon generatore casuale garantisce che in media tutti i numeri verranno restituiti allo stesso modo spesso.

Naturalmente, se hai utilizzato un generatore casuale errato, ciò potrebbe aver distorto i risultati e, in tal caso, il semplice passaggio a un generatore casuale migliore dovrebbe risolvere il problema. (Controlla la libreria Boost.Random per generatori migliori)

In alternativa, potresti ricordare gli ultimi N valori restituiti dalla tua funzione casuale e pesare il risultato con quelli. (un semplice esempio potrebbe essere "per ogni occorrenza del nuovo risultato, c'è una probabilità del 50% di scartare il valore e ottenerne uno nuovo"

Se dovessi indovinare, direi che restare nella casualità "reale" è la soluzione migliore. Assicurati di utilizzare un buon generatore casuale, quindi continua nel modo in cui lo stai facendo ora.

È possibile creare un elenco contenente i numeri da 1 a 5 e ordinarli per casualità. Quindi basta scorrere l'elenco che hai creato. Hai la garanzia di incontrare ogni numero almeno una volta ... Quando hai finito con i primi 5, basta creare altri 5 numeri ...

Consiglio un sistema di percentuale progressivo come Blizzard utilizza: http://www.shacknews.com/onearticle.x/57886

Generalmente si lancia un RNG quindi lo si confronta con un valore per determinare se ha esito positivo o meno. Potrebbe apparire come:

if ( randNumber <= .2 ) {
   //Critical
} else {
   //Normal
}

Tutto quello che devi fare è aggiungere un aumento progressivo delle probabilità di base ...

if (randNumber <= .2 + progressiveChance ) {
   progressiveChance = 0;
   //Critical
} else {
   progressiveChance += CHANCE_MODIFIER;
   //Normal hit
}

Se ne hai bisogno per essere più fantasioso è abbastanza facile aggiungerne di più. Puoi limitare la quantità che progressiveChance può ottenere per evitare una probabilità critica del 100% o ripristinarla su determinati eventi. Puoi anche avere un aumento progressivo dihance in quantità minori ogni incremento con qualcosa come progressiveChance + = (1 - progressiveChance) * SCALE dove SCALE <1.

Bene, se sei un po 'in matematica, probabilmente puoi provare la distribuzione esponenziale

Ad esempio, se lambda = 0,5, il valore atteso è 2 (vai a leggere l'articolo!), Significa che molto probabilmente colpirai / crit / qualunque sia il 2 ° turno (come 50%, eh?). Ma con una tale distribuzione di probabilità, ti perderai sicuramente (o farai l'opposto di qualsiasi cosa) al 0 ° turno (quello, in cui l'evento si era già verificato e il turno_contro era stato resettato), ha circa il 40% di probabilità di colpire il turno successivo, circa il 65% possibilità di farlo 2 ° (successivo dopo successivo) turno, circa l'80% per colpire 3 ° e così via.

Lo scopo di quella distribuzione è se uno ha il 50% di probabilità di colpo e perde 3 volte di seguito, otterrà un colpo sicuro (beh, oltre l'80% di probabilità e aumenta ogni turno successivo). Porta a risultati più "equi", mantenendo invariata la probabilità del 50% in eccesso.

Prendendo la tua probabilità del 20% di crit, hai

• 17% al primo turno critico
• 32% al 2 ° turno critico, se non si verifica alcun critico in tutti i precedenti.
• 45% al ​​terzo turno del critico, se non si verifica alcun critico in tutti i precedenti.
• 54% al 4 ° turno critico, se non si verifica alcun critico in tutti i precedenti.
• ...
• 80% all'ottava volta del critico, se non si verifica alcun critico in tutti i precedenti.

È ancora circa lo 0,2% (contro quei 5%) possibilità di 3 crits + 2 non-crits in 5 turni conseguenti. E c'è una probabilità del 14% di 4 non-crits conseguenti, 5% di 5, 1,5% per 6, 0,3% per 7, 0,07% per 8 non-crits conseguenti. Scommetto che è "più equo" del 41%, 32%, 26%, 21% e 16%.

Spero che non ti annoi ancora a morte.

Che ne dici di fare in modo che la possibilità di critico dipenda dagli ultimi attacchi N. Uno schema semplice è una specie di catena markov: http://en.wikipedia.org/wiki/Markov_chain ma il codice è comunque molto semplice.

IF turns_since_last_critical < M THEN 
   critial = false
   turns_since_last_critical++;
ELSE
   critial = IsCritical(chance);
   IF Critial THEN
       turns_since_last_critica = 0;
   ELSE
       turns_since_last_critica++;
   END IF;
END IF;

Ovviamente devi fare i tuoi calcoli perché la possibilità di un critico è inferiore alla possibilità di un critico una volta che sai che è stato abbastanza turni dall'ultimo

OPERAZIONE,

Praticamente, se vuoi che sia giusto, non sarà casuale.

Il problema del tuo gioco è l'effettiva durata della partita. Più lunga è la partita, minore sarà la casualità che vedrai (i crits tenderanno ad essere del 20%) e si avvicinerà ai tuoi valori previsti.

Hai due opzioni, pre-calcola gli attacchi in base ai tiri precedenti. Il che ti farà ottenere un critico ogni 5 attacchi (basato sul tuo 20%), ma puoi fare l'ordine in modo casuale.

listOfFollowingAttacks = {Hit, Hit, Hit, Miss, Crit};

Questo è lo schema che desideri. Quindi fatelo scegliere casualmente da quell'elenco, fino a quando è vuoto, lo ricreano.

Questo è uno schema che ho creato per il mio gioco, funziona abbastanza bene, per quello che voglio che faccia.

la tua seconda opzione, sarebbe, aumentare la possibilità di crit, probabilmente vedrai un numero più pari alla fine di tutti gli attacchi (supponendo che le tue partite finiscano piuttosto rapidamente). Meno probabilità%, più RNG hai.

Stai osservando una distribuzione lineare, quando probabilmente desideri una distribuzione normale.

Se ricordi di aver giocato a D&D in gioventù, ti è stato chiesto di tirare più dadi n, quindi sommare i risultati.

Ad esempio, tirare 4 dadi a 6 facce è diverso dal tirare 1 dado a 24 facce.

City of Heroes ha in realtà un meccanico chiamato "streakbreaker" che risolve esattamente questo problema. Il modo in cui funziona è che dopo una serie di miss di una lunghezza correlata alla probabilità di colpire più bassa nella stringa, il prossimo attacco è garantito per essere un colpo. Ad esempio, se perdi un attacco con oltre il 90% per colpire il caso, il tuo prossimo attacco colpirà automaticamente, ma se la tua probabilità di colpire è inferiore come il 60%, dovrai avere più missioni consecutive per innescare lo "streakbreaker" (I non conosco i numeri esatti)

questo è davvero prevedibile ... ma non puoi mai esserne sicuro.

Che ne dici di ponderare il valore?

Ad esempio, se hai una probabilità del 20% di un colpo critico, genera un numero compreso tra 1 e 5 con un numero che rappresenta un colpo critico o un numero compreso tra 1 e 100 con 20 numeri che sono un colpo critico.

Ma finché lavori con numeri casuali o pseudocasuali, non c'è modo di evitare potenzialmente i risultati che stai vedendo. È la natura della casualità.

Reazione su: "Il problema è che ho ottenuto risultati molto negativi nella vita reale - a volte i giocatori ottengono 3 punti critici in 5 colpi, a volte nessuno in 15 colpi".

Hai una possibilità tra il 3 e il 4% di non ottenere nulla in 15 colpi ...

Proporrei il seguente "die rimandato a caso":

• Mantenere due array, uno ( in-array) inizialmente riempito con i valori da 0 a n-1, l'altro ( out-array) vuoto
• Quando viene richiesto un risultato:
  • restituisce un valore casuale da tutti i valori definiti inin-array
  • sposta questo valore da in-arrayaout-array
  • spostare uno casuali (oltre tutti gli elementi, tra cui l'! indefinita) da elemento out-arraynuovo inin-array

Questa ha la proprietà che sarà "reagire" più lentamente il grande n è. Ad esempio, se vuoi una probabilità del 20%, impostare n su 5 e colpire su uno 0 è "meno casuale" rispetto all'impostazione n su 10 e colpire su uno 0 o 1 e renderlo da 0 a 199 su 1000 sarà quasi indistinguibile dalla vera casualità su un piccolo campione. Dovrai adattare n alle dimensioni del tuo campione.

Pre-calcola un colpo critico casuale per ogni giocatore.

// OBJECT
//...
// OnAttack()
//...
c_h = c_h -1;
if ( c_h == 0 ) {
 // Yes, critical hit!
 c_h = random(5) + 1 // for the next time
 // ...
}

Penso che forse stai usando la funzione di distribuzione casuale sbagliata. Probabilmente non vuoi una distribuzione uniforme sui numeri. Prova invece una distribuzione normale in modo che i colpi critici diventino più rari rispetto ai colpi "normali".

Lavoro con Java, quindi non sono sicuro di dove puoi trovare qualcosa per C ++ che ti dia numeri casuali con una distribuzione normale, ma ci deve essere qualcosa là fuori.