Arenthar

allora....
cari ragaSSuoli siccome ho tanto da fare per l'associazione (scrivere sistemare rassettare cucire e chi più ne ha più ne metta) e pure io lavoro perchè se non non mangio visto che non ho il babbino e la mammina che mi mantengono, vi prego di evitate di continuare a ripetere le vostre idee... le avete già scritte e le ho già lette, riscriverle ancora mi fa perdere solo tempo che potrei dedicare a scrivere qualcosa di operativo per il live.
Se avete nuove idee (tipo quella che ha espresso emanuele) benvengano, se dovete ribadire ciò che è già stato detto... ANCHE BASTA. S'è capito.
Vorreimmo inoltre SOLUZIONI alternative e non punti di vista di cosa dal vostro punti di vista è giusto o sbagliato.

I vostri master stanno già pensando a una possibile soluzione avendo vagliato tutti i vostri punti di vista, la legislatura italiana e cosa (dal nostro punto di vista) sia meglio per l'associazione.

Altra idea giocatori nuovi: ad ogni live sono dedicati a giocatori nuovi (N° live giocati <= 3, ad esempio) solo un tot di posti (20% ad esempio).
Questo permette comunque a nuove persone di venire (garantendo un melting-pot fecondo), ma contemporaneamente fa sì che il livello di gioco non si abbassi arbitrariamente (sia perchè i giocatori "scafati" interagiscono meglio, sia perchè sono più "autonomi").

Algoritmo turnazioni plausibile:
Dati:

#PG = il numero di posti dedicati a PG per un dato live
#PNG = il numero di posti dedicati a PNG per un dato live
VP = il valore di precetto di ogni giocatore
k = determinatezza (1 = totalmente deterministico; 0 = totalmente casuale)

Algoritmo:

i master fissano #PG e #PNG e aprono le iscrizioni
i giocatori si iscrivono al live (senza specificare se da PG o da PNG)
i master, dopo un tot (1 settimana? 2?), chiudono le iscrizioni
i #PNG giocatori con VP maggiore, vengono al live come PNG
i k*#PG giocatori con VP minore, vengono al live come PG
dei restanti giocatori, (1-k)*#PG scelti a caso vengono al live come PG
i giocatori scelti pagano entro tot (1 settimana?), altrimenti vengono ripescati gli altri

Questo garantisce che:
- chi ha alto precetto (non può dare una mano extralive o non fa PNG da tanto), non resti a casa ad libitum
- chi ha basso precetto (da spesso una mano/fa png), giochi come PG
- chi è a una via di mezzo, abbia una discreta probabilità di venire comunque al live (come PG), anche senza scapicollarsi al tabacchino o sul sito

Corollari:
invece della casualità di cui al penultimo punto dell'algoritmo, usare una graduatoria di "punti escluso" che si guadagnano iscrivendosi ad un live ma restandone fuori.

Si accettano anche modifiche/aggiustamenti.

Riccardo ha messo nero su bianco la mia idea iniziale. Forse non è una buona soluzione, ma è una soluzione paritaria per tutti...

pietro tu hai capito tutto del mio post

scrivete SOLO idee nuove! (grazie ric)

MONSTERING: altra idea per """aumentare""" i partecipanti al live (con molte virgolette):

Si potrebbe aumentare il numero di partecipanti fermo restando che:

si trovino case più capienti oppure tali partecipanti aggiuntivi siano disponibili ad arrangiarsi in tende/strutture di pernotto "vicine"
la gente dia una mano in cucina (in loco o preparando a casa pietanze riscaldabili)

aggiungendo un certo numero di giocatori come MONSTERING (non PNG: solo monstering).

Date le premesse, questo non graverebbe sul lavoro dei master (punto di massima criticità, se ho capito bene) in nessun modo, dato che:

il cibo non mancherebbe;
il posto per dormire non mancherebbe;
obiettivi o trame nuove non servirebbero.

Ovviamente fare monstering per 2 giorni a qualcuno potrebbe non star bene.. nel qual caso può sempre restare a casa però intanto quelli disposti avrebbero un'occasione in più per poter venire.

Un po' di scienza:

A questo link http://poisson.phc.unipi.it/~bellucci/simulazione/risultati.txt.zip c'è una simulazione dell'algoritmo di Torq fatto su 1000 live (che non ci saranno mai ma serve per vedere il trend medio dell'algoritmo)
Se vi interessa andate quindi a vedere la fine del file.
Per i piu' nerd:
http://poisson.phc.unipi.it/~bellucci/simulazione/algoritmo_pg.bas
Il sorgente del programma usato per eseguire la simulazione
http://www.qb64.net/
Il compilatore per compilare il sorgente