Domanda

Sto programmando un gioco da tavolo in cui c'è un sacco di possibili pezzi. Ad ogni turno, i giocatori rimuovono pezzi selezionati casualmente dalla borsa in base a determinate regole.

Per la mia implementazione, potrebbe essere più semplice dividere la borsa inizialmente in pool per uno o più giocatori. Questi pool sarebbero stati scelti in modo casuale, ma ora diversi giocatori avrebbero scelto da diversi sacchetti. È diverso?

Se la borsa di un giocatore si esaurisse, ne verrebbero mescolate altre casualmente dalla scorta generale.

È stato utile?

Soluzione

Finché:

  • la partizione in " pool " bag è casuale
  • l'assegnazione dei giocatori a una determinata sacca da biliardo è casuale
  • il gioco è tale che gli oggetti estratti dai giocatori vengono effettivamente rimossi dalla borsa (mai restituiti alla borsa, o qualsiasi altra borsa, per la durata della partita corrente)
  • i giocatori non sono a conoscenza del contenuto di qualsiasi delle borse

I due approcci ("originale" con un grande sacco comune, "modificato" con un sacco di biliardo per giocatore sono equivalenti per quanto riguarda le probabilità.

Diventa solo un po 'complicato verso la fine del gioco, quando alcune borse dei giocatori sono vuote. Il più giusto per scegliere dal 100% degli oggetti ancora in gioco, quindi, entrambi dovrebbero scegliere da quale borsa scegliere e [ciecamente, ovviamente] scegliere un oggetto da detta borsa.

Questo problema illustra un'interessante caratteristica delle probabilità che è che le probabilità sono relative alla quantità di conoscenza che si ha sulla situazione . Ad esempio, l'host del gioco potrebbe sapere che il "pool" la borsa assegnata per dire che il giocatore X non include alcuna lettera "A". (pensando a scrabble), ma fino a quando nessuno dei giocatori lo sa (e fintanto che le partizioni nella sacca da biliardo erano completamente casuali), il gioco rimane giusto e il giocatore "X". deve ancora supporre che il suo / la sua probabilmente di colpire un "A" la prossima volta che viene disegnata una lettera, è come se tutte le lettere rimanenti fossero disponibili per lui / lei.

Modifica:
Nonostante la validità matematica dell'asserzione secondo cui entrambe le procedure sono pienamente equivalenti, percezione è un fattore importante nei giochi che includono una componente casuale (in particolare se il gioco include anche un componente pecuniario). Per evitare l'ira dei giocatori che non comprendono questa equità, è possibile attenersi alla procedura originale ...

Altri suggerimenti

A seconda delle regole del gioco, @mjv ha ragione, la divisione casuale iniziale non influenza le probabilità. Questo è analogo a un gioco in cui n giocatori pescano carte a turno da un mazzo a faccia in giù: lo shuffle iniziale del mazzo è la divisione casuale in "borse". di carte per ciascun giocatore.

Ma se sostituisci gli oggetti dopo ogni estrazione, è importante che ci siano una o più borse. Con una borsa qualsiasi oggetto particolare verrà eventualmente estratto da qualsiasi giocatore con la stessa probabilità. Con molte borse, quell'oggetto può essere estratto solo dal giocatore in cui è stata inizialmente messa la borsa.

Passando al livello software, se il gioco richiede un singolo bag, ti consiglio di programmarlo in quel modo: non dovrebbe essere più difficile di n bag, e non devi provare il nuovo gioco equivalente al vecchio.

La mia intuizione mi dice che dividere una raccolta casuale di cose in sottoinsiemi casuali più piccoli rimarrebbe ugualmente casuale ... non importa se un giocatore sceglie da un grande pool o uno più piccolo (che a sua volta, si alimenta nel grande)

Per un gioco è abbastanza IMHO casuale!

A seconda di quanto sia importante la sicurezza, potrebbe andare bene (se è coinvolto denaro (tu o loro) NON FARLO). Non sono del tutto sicuro che sarebbe meno casuale dal punto di vista di un giocatore ignorante.

a) Non contare sul fatto che siano ignoranti, il tuo programma potrebbe essere decifrato e quindi saprebbero quali pezzi stanno arrivando

b) Sarebbe molto complicato riempire i sacchetti in modo da non introdurre vulnerabilità. Ad esempio, prendiamo l'algoritmo ingenuo di sceglierne uno a caso e metterlo in un primo bucket, estrarlo e quindi fare lo stesso per il secondo bucket e così via. Hai appena assicurato che se ci sono N pezzi, il primo giocatore aveva una probabilità di 1 / N di scegliere un determinato pezzo, il secondo giocatore aveva un 1 / (N-1), il terzo aveva 1 / (N-3) e presto. I giocatori possono quindi analizzare i pezzi già giocati al fine di capire le probabilità che altri giocatori abbiano determinati pezzi.

I PENSA il seguente algoritmo potrebbe funzionare meglio, ma quasi tutte le persone sbagliano probabilità la prima volta che escono con un nuovo algoritmo. NON UTILIZZARE QUESTO, basta capire che potrebbe coprire la vulnerabilità di sicurezza di cui ho parlato:

  1. Crea un elenco di N oggetti ordinati e crea un'istanza di giocatori P
  2. Segna 1 / P degli oggetti in modo casuale (con sostituzione) per ciascun giocatore
  3. Ripeti ripetutamente fino a quando tutti gli N elementi sono contrassegnati e non ci sono uguali numero di oggetti segnati per ogni giocatore (NOTA: può richiedere molto più tempo di quanto potresti vivere a seconda di N e P)
  4. Posiziona gli oggetti appropriati nel bucket del giocatore e riorganizza in modo casuale (NON utilizzare un algoritmo di scambio di posto)

Anche dopo tutto ciò, potresti ancora avere una vulnerabilità a qualcuno che capisce cosa c'è nel suo secchio da un exploit. Stick con un pool combinato, è ancora difficile scegliere in modo casuale, ma ti renderà la vita più facile.

Modifica: so che il tono sembra un po 'a scatti. Per lo più ho incluso tutto quel grassetto per le persone che potrebbero leggerlo fuori dal contesto e provare alcuni di questi algoritmi. Ti auguro davvero bene :-)

Modifica 2: A ulteriore considerazione, penso che il problema con il picking in ordine potrebbe ridursi ad avere i giocatori a turno in primo luogo. Se questo è già nelle regole potrebbe non avere importanza.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top