Sigildream Tech Blog

Come nasce un duello, secondo per secondo

Un giocatore preme «Entra nell'Arena». Nello stesso istante, a migliaia di chilometri di distanza, qualcun altro fa lo stesso gesto. Pochi secondi dopo sono faccia a faccia nello stesso duello dal vivo. In quei pochi secondi si gioca una partita invisibile: decidere chi affronta chi perché la sfida sia equilibrata, e dove nel mondo far girare lo scontro.

Cos'è Sigilwake. Un gioco di combattimento di ruolo a turni, dallo stile manga in bianco e nero, mobile-first, multipiattaforma (Web, Android, iOS, macOS, Windows), oggi in fase di validazione. Duelli uno contro uno: due combattenti, quattro abilità a testa, animazioni cinematiche, partite giocabili, seguibili in diretta e rivedibili in replay. Il roster conta 24 personaggi, tutti diversi tra loro.
#GameAI   #GameBalance   #DevLog
Dal ticket al match live — orbita del broker Una coda di ticket di matchmaking sulla sinistra viene attirata in un hub centrale accoppiamento. L'hub emette verso l'esterno token di match accoppiati a tre combat server regionali etichettati EU-WEST, US-EAST e APAC. Piccoli impulsi luminosi viaggiano lungo i percorsi di ingresso e uscita, indicando la direzione e la bassa latenza dell'hot path del broker. TICKET · CODA BROKER · ACCOPPIAMENTO COMBAT · REGIONI ticket · Varro μ 1502 φ 68 tier 3 · EU ticket · Nyx μ 1459 φ 72 tier 3 · EU ticket · Boreus μ 1611 φ 54 tier 4 · US accoppiamento 12 MiB · 0.4% CPU firma arena UE warm · 200 ms regione UE arena USA warm · 210 ms regione USA arena Asia cold · ~5 s regione Asia TAP → primo turno 3–5 s · 7 sistemi · 3 hand-off firmati
Ticket → Broker → Allocazione Combat, un unico percorso di richiesta. p50 ∼ 3,6 s

Atto 1 · I quattro secondi

Tre ruoli si passano il testimone per portarti nell'arena.

Dietro il gesto di premere «Entra nell'Arena», tre sistemi si passano il testimone come in una staffetta. Il primo tiene la fila: raccoglie la richiesta di giocare e la custodisce finché non trova un avversario. Il secondo è l'arbitro degli accoppiamenti: decide chi affronta chi perché la sfida sia equilibrata, e assegna un'arena. Il terzo accende quell'arena — un server dedicato, nell'angolo di mondo più vicino a entrambi. Sono ruoli separati per un motivo preciso: così ognuno fa una cosa sola, e quando qualcosa rallenta si sa subito quale dei tre guardare.

Il server principale

Chi tiene la fila

Tiene la coda di chi vuole giocare: custodisce ogni richiesta finché non trova un avversario. La controlla a ritmo regolare, con un tempo massimo di attesa oltre il quale scatta una via di riserva.

Il servizio di accoppiamento

L'arbitro degli accoppiamenti

Un servizio dedicato, interpellato con una chiamata interna firmata per ogni coppia proposta. Confronta il valore dei due giocatori, prepara le chiavi di partita usa-e-getta e sceglie la regione più vicina. Impronta a regime: 12 MiB di RAM e 0,4% di CPU su oltre 2 800 coppie.

Micro-arene geolocalizzate

Chi accende l'arena

Micro-istanze geolocalizzate accendono una piccola arena nella regione più vicina ai due giocatori, la ospitano e la spengono appena finisce. Se ce n'è già una libera, la consegna è sotto il secondo; altrimenti ne nasce una in circa 5 secondi.

Sotto il cofano. Un tempo erano un unico blocco dentro Nakama, il nostro server principale. Sotto sforzo — diecimila giocatori insieme nel caso peggiore — quel blocco divorava memoria e rallentava perfino l'accesso degli altri giocatori. L'abbiamo spezzato in tre servizi indipendenti, e la memoria occupata è scesa da 3,08 GiB a 1,59 GiB con lo stesso carico. Qui sopra, chi sono e quanto costano davvero.
un solo blocco Nakama → tre servizi · −1,5 GiB di RAM

Perché separare? Il server principale è bravissimo nei compiti che non hanno fretta: tenere le sessioni, conservare i dati, mandare le notifiche. Fare l'arbitro degli accoppiamenti sotto carico pesante, invece, non è il suo mestiere — e nella nostra misura si vedeva.

La prova di sforzo che ci ha convinti a separarlo racconta due vantaggi. Il primo è la memoria: da 3,08 GiB a 1,59 GiB, con lo stesso carico di lavoro. Il secondo è la libertà di far evolvere le regole degli accoppiamenti per conto loro, senza aspettare gli aggiornamenti del server principale.

Una nuova regola sul punteggio, una difesa in più contro chi si crea un account nuovo per battere i principianti, un'altra via di riserva verso la partita contro il computer: si aggiorna quel solo servizio e lo si riavvia in pochi secondi. Il server principale, il database e l'app sul telefono restano intoccati.

Atto 1 · il flusso, secondo per secondo

Cosa succede dietro la rotellina di attesa.

Per chi gioca è solo un'attesa di pochi secondi. Dietro quella rotellina i tre ruoli si passano il testimone lungo una staffetta precisa: raccogliere il giocatore, trovare l'avversario, accendere l'arena, consegnare a entrambi la chiave per entrarci. La linea qui sotto mostra quella staffetta secondo per secondo, con il tempo che ogni passo può prendersi.

Sotto il cofano. L'app del giocatore manda una sola richiesta; tutto il resto avviene sui nostri server. Sette sistemi si coordinano lungo un percorso con tre passaggi firmati — così nessuno può fingersi un altro.

Timeline del flusso di matchmaking — dal tap client al primo turno Una timeline orizzontale a sette passi che rappresenta il percorso wall-clock dal tap sul client del giocatore al primo frame di combattimento. Passi: 1 tap client (~40 ms), 2 coda ticket (attesa fino a 15 s), 3 coppia proposta (~90 ms), 4 rating e verifica di identità (~30 ms), 5 creazione delle chiavi di partita (~2 ms), 6 allocazione server (~200 ms warm), 7 connessione client al combat (~120 ms). Un impulso in movimento viaggia lungo la timeline indicando la direzione della richiesta; una banda ombreggiata di attesa in coda evidenzia il passo 2 dove si accumula la maggior parte del tempo trascorso. WALL-CLOCK · budget p50 target · non impegnati come SLO END-TO-END target ≈ 3.6 s ATTESA IN CODA 1 tap client app ~40 ms in coda 2 coda ticket tick 1 s · 15 intervalli 0 – 15 s fino ad accoppiamento 3 coppia proposta firma → broker ~90 ms abbinamento 4 rating & identità lettura archivio ~30 ms chiave usa-e-getta 5 chiavi di partita chiave per posto ~2 ms a vita breve 6 allocazione server warm pool ~200 ms cold: ~5 s 7 primo turno app → combattimento ~120 ms verifica chiave server principale servizio di accoppiamento micro-arene geolocalizzate + combat
La banda di attesa in coda sul passo 2 è dove si accumula la maggior parte del tempo — gli altri sei passi messi insieme restano ben sotto il secondo quando in fila c'è abbastanza gente.
1

Tap del giocatore

L'app del giocatore

L'app apre un collegamento verso il server principale.

~40 ms

Se va storto: riprova aspettando via via un po' di più; il pulsante resta bloccato mentre la richiesta è in corso, per evitare doppi tocchi.

2

Coda d'attesa

Il server principale

La richiesta entra nella fila.

0–15 s fino all'accoppiamento

Se va storto: superato il tempo massimo di attesa, la stessa richiesta viene promossa a un match contro l'IA.

3

Coppia proposta

Il server principale

Una chiamata interna firmata verso il servizio di accoppiamento.

~90 ms

Se va storto: se il servizio non risponde, il percorso ricade da solo su una via di riserva, senza errori per chi gioca.

4

Punteggio & identità

Servizio di accoppiamento

Calcolo del punteggio e assegnazione esclusiva del match.

~30 ms

Se va storto: se l'archivio è lento si ricade sulla via di riserva; se il match risulta già assegnato, la coppia viene riproposta.

5

Chiave di partita

Servizio di accoppiamento

Una chiave firmata per ciascun giocatore.

~2 ms

Se va storto: le chiavi valgono pochi minuti e si consumano al primo ingresso nell'arena; un secondo tentativo con la stessa chiave viene respinto.

6

Allocazione

Micro-arene geolocalizzate

Si accende un'arena nella regione più vicina — o il gemello locale in sviluppo.

~200 ms a caldo · ~5 s a freddo

Se va storto: se una regione è in sofferenza, l'allocazione si sposta altrove senza che il nostro codice intervenga.

7

Ingresso nell'arena

App del giocatore → server di combattimento

L'app entra nell'arena con la sua chiave di partita.

~120 ms

Se va storto: il protocollo di riconnessione copre i cambi di server — vedi il capitolo sul combat.

Atto 2 · Avversari equilibrati, non casuali

Quanto vale un giocatore — e quanto ne siamo sicuri.

Un avversario preso a caso è un lancio di moneta: una noia per chi è forte, una punizione per chi è alle prime armi. Per questo non si accoppia a caso. Prima di mettere due persone una di fronte all'altra il sistema si pone due domande: quanto è brava ciascuna, e quanto ne siamo sicuri. Un giocatore appena iscritto e un veterano che rientra dopo un mese possono avere lo stesso punteggio sulla carta, ma del primo ne sappiamo molto meno — e trattarli come se ne sapessimo altrettanto produrrebbe partite sbilanciate. Misurare anche la nostra incertezza è ciò che trasforma l'accoppiamento in una vera sfida invece che in un tiro di dado.

Sotto il cofano. Un sistema di punteggio ingenuo tiene un solo numero per giocatore: quanto è bravo. Il nostro ne tiene tre: quanto pensiamo valga (μ), quanta incertezza c'è su quel valore (φ) e quanto quel valore è ballerino nel tempo (σ). Tutti e tre contano, per esempio, quando si mette di fronte un veterano che non gioca da un mese e un secondo account con cui un giocatore forte si nasconde tra i principianti, magari in piena serie di vittorie. Sopra questi tre numeri il nostro sistema aggiunge quattro correzioni pensate in casa, ognuna per chiudere uno dei quattro modi in cui, nei giochi competitivi a turni, si prova ad aggirare il punteggio.

Come cambia il punteggio di due giocatori nel tempo Un grafico di drift del rating. L'asse x è il numero di match giocati da 0 a 40. L'asse y è il rating mu sistema di punteggio da 1300 a 1700. Due giocatori sono tracciati: il giocatore A che parte da 1500 in oro, e il giocatore B, un veterano di ritorno, che parte da 1620 in viola. Una banda ombreggiata di rating deviation (phi) avvolge ogni linea per mostrare l'incertezza. Quattro punti di inflessione numerati annotano i quattro aggiustamenti del nostro sistema di punteggio: 1 normalizzazione del win-rate per personaggio al match 8, 2 gate anti-smurf per tier applicato al match 14, 3 smorzamento delle serie negative che entra intorno al match 22, e 4 pavimento del decadimento RD per inattività raggiunto al match 32. Una baseline tratteggiata a mu 1500 segna la mediana globale del rating. 1700 1600 1500 1400 1300 0 5 10 15 20 25 30 35 40 MATCH GIOCATI punteggio (μ) 1 normalizza WR char 2 gate anti-smurf 3 smorzamento sconfitte 4 pavimento RD giocatore A · nuovo account · φ che si restringe giocatore B · veterano di ritorno · φ ampio → pavimento baseline μ = 1500
Due giocatori, quaranta partite, le quattro correzioni del nostro sistema di punteggio. La banda d'incertezza del giocatore A si restringe man mano che il sistema diventa più sicuro di quanto vale; quella del giocatore B resta ampia finché il tempo di inattività non la ferma a un valore minimo. Ogni correzione è un punto numerato sulla curva.

1. Il personaggio non conta due volte

I 24 personaggi non vincono tutti con la stessa facilità: alcuni, nella fase attuale del gioco, sono più forti e altri più deboli. Il punteggio tiene conto di questo vantaggio o svantaggio di partenza, così chi sceglie un personaggio meno forte nella fase attuale non si ritrova penalizzato due volte. Il confronto tra i personaggi viene rifatto di tanto in tanto, in sottofondo; mentre si gioca, il valore già pronto viene recuperato in un attimo, senza rallentare la partita.

2. I forti travestiti da principianti

Se un giocatore molto più forte affronta di continuo persone ben più deboli di lui, dalle sue vittorie guadagna molto meno punteggio e dalle sconfitte ne perde molto di più. In più, gli account nati da meno di un'ora vengono tenuti in una fila separata, così un'ondata di questi profili non tocca chi gioca in modo leale.

3. Le sconfitte in fila non affondano

Diverse sconfitte di seguito fanno crescere la nostra incertezza (φ): vuol dire che non siamo più così sicuri di quanto valga davvero quel giocatore. Questo attutisce le sconfitte successive ed evita il crollo a valanga. È il minimo per non far scappare le persone: senza, una serataccia si trasformerebbe in un calo di 200 punti da recuperare in settimane.

4. Il ritorno dopo una lunga assenza

Se un giocatore sta via a lungo, la nostra sicurezza su quanto vale si allenta, ma solo fino a un certo limite — così un veterano che rientra dopo un mese non si ritrova subito contro uno dei migliori in assoluto alla sua prima domenica di gioco.

Atto 2 · le manopole che fanno muovere la fila

Quanto aspettare prima di allargare la ricerca.

Trovare un avversario equilibrato costa tempo: più a lungo la ricerca resta stretta, migliore è l'accoppiamento — ma nessuno ha voglia di fissare all'infinito una rotellina che gira. Tutta la messa a punto di questa parte vive dentro questa tensione: aspettare abbastanza da trovare la persona giusta, allargare la ricerca prima che l'attesa diventi fastidio, e far scorrere la fila anche quando migliaia di richieste arrivano nello stesso istante.

Sotto il cofano. A governare quel ritmo è una manciata di numeri sul nostro server principale — ogni quanto guardare la fila, quanto tenere in vita una richiesta, quante reggerne insieme. Le impostazioni predefinite erano silenziosamente troppo timide per lo scenario peggiore, decine di migliaia di giocatori in coda nello stesso momento. I valori qui sotto sono quelli che tengono la fila in movimento invece di accumulare ritardo.

Ogni quanto guardare la fila

1 secondo

Più spesso pesa troppo sul calcolo; più di rado sfora i 3–5 s promessi a chi gioca.

Quanto tenere viva una richiesta

~15 secondi

Oltre questa soglia si passa a un match contro l'IA: il punto di equilibrio tra aspettare e sembrare fermo.

Quante richieste reggere insieme

20 000

Il doppio dello scenario da 10.000 giocatori, margine per il picco «tutti insieme».

Quanti processi interni tenere pronti

da 32 a 64

L'impostazione di fabbrica si intasava in un secondo sotto 10.000 giocatori; questi valori hanno retto ogni prova di stress.

Atto 2 · l'arbitro, aperto

L'arbitro degli accoppiamenti, e le due promesse che non infrange.

Il pezzo che decide davvero chi affronta chi è un piccolo servizio a sé: l'arbitro. A ogni coppia proposta calcola se lo scontro sarà equilibrato, assegna un'arena e consegna a ciascuno la chiave per entrarci. È veloce ed economico da tenere acceso, e in questa parte lo si apre pezzo per pezzo.

Sotto il cofano. È un piccolo servizio dedicato, con una manciata di funzioni e un modello di stato ridotto all'osso. Sotto la superficie, le «due promesse» sono due garanzie tecniche: che l'identità di un match sia spendibile una sola volta, e che vincitore e perdente restino vincolati esattamente ai due giocatori accoppiati. Ecco la superficie del servizio e le due invarianti.

L'arbitro degli accoppiamenti e le due promesse che non infrange In alto una coppia proposta — due giocatori — entra in un nodo centrale, l'arbitro, che verifica l'equità dello scontro, assegna un'arena e consegna a ciascuno una chiave. In basso, due riquadri mostrano le due promesse. Il primo: l'identità di un match passa da aperta a consumata in un solo passo, e ogni tentativo ripetuto rimbalza via, respinto. Il secondo: all'arena entrano solo i due giocatori accoppiati, mentre un estraneo viene respinto. ATTO 2 · L'ARBITRO due promesse · mai infrante COPPIA PROPOSTA L'ARBITRO ARENA · CHIAVI giocatore A in cerca di sfida giocatore B in cerca di sfida arbitro equità · arena · chiavi arena assegnata una chiave per giocatore chiave A chiave B LE DUE PROMESSE CHE L'ARBITRO NON INFRANGE 1 L'identità del match si spende una sola volta aperta identità libera un passo solo consumata riproporre · riusare una chiave · recupero dopo un crash rimbalza — respinto niente monete, niente punteggio 2 Vincitore e perdente legati ai due giocatori accoppiati ARENA stesso match ammessi giocatore A A giocatore B B estraneo ? nessuno si infila al loro posto
L'arbitro verifica l'equità, assegna l'arena e consegna le chiavi — senza mai infrangere le due promesse. un match, un'identità, due giocatori

Cosa fa il servizio

La sua superficie è una manciata di funzioni interne, non esposte al pubblico: i controlli di salute per il monitoraggio, gli accoppiamenti richiesti dal server principale, i match contro l'IA e l'aggiornamento dei punteggi a fine partita. Sono tutte chiamate tra i nostri servizi, ognuna firmata e verificata.

Due promesse che il servizio non infrange

  1. L'identità di un match si spende una volta sola, su tutta la piattaforma. Ogni match ha un'identità unica che passa da «aperta» a «consumata» in un'unica operazione indivisibile. Ogni tentativo successivo — riproporre la coppia, riusare una chiave, un ciclo di recupero dopo un crash — viene respinto all'istante: nessuna moneta toccata, nessun punteggio scritto, nessuna sessione aperta.
  2. Vincitore e perdente restano legati ai due giocatori accoppiati. Chi si presenta all'arena deve essere uno dei due originariamente accoppiati per quel match, e la stessa verifica vale su ogni aggiornamento di punteggio. Nessun altro può infilarsi al loro posto.

Un solo passaggio per accoppiare e assegnare

Le due operazioni — trovare la coppia e accenderle un'arena — sono state unite in un unico passaggio, per dimezzare i tempi e per non lasciare mai un match a metà: o si fa tutto, o non si fa nulla.

La risposta consegna tutto il necessario per entrare nell'arena: dove si combatte, una chiave di partita usa-e-getta per ciascun giocatore, e qualche numero sulla qualità dell'accoppiamento (quanto sono vicini i due punteggi).

Atto 3 · A prova di imbroglio

Come un servizio dimostra di essere davvero sé stesso.

Un telefono è uno schermo, non un arbitro. Non lo si può credere sulla parola quando dichiara un punteggio, reclama una vittoria o afferma chi è. Da qui nasce l'intera impalcatura di questa parte: ogni messaggio porta una firma, ogni match consegna chiavi usa-e-getta, e ogni risultato viene ri-verificato sui nostri server prima che una moneta o una posizione in classifica si muovano. Si comincia dalla firma — il modo in cui, persino tra i nostri stessi server, uno dimostra di essere davvero sé stesso e non un impostore, come un sigillo di ceralacca che nessun altro sa rifare.

Sotto il cofano. Ogni chiamata interna verso il servizio di accoppiamento è una richiesta firmata: la firma viaggia insieme al messaggio, e chi la riceve verifica che sia autentica prima di dare retta a una sola parola. Ecco l'idea, senza la ricetta.

La stretta di mano firmata — un messaggio che nessun impostore può falsificare Due nodi affiancati: a sinistra il server di combattimento, a destra il nostro server. Un messaggio, rappresentato come una busta, viaggia lungo un connettore tratteggiato da sinistra verso destra; a metà percorso compare sulla busta un sigillo, cioè la firma. All'arrivo il ricevente mostra una spunta a indicare che la firma è stata verificata. Più in basso un messaggio impostore, disegnato in tono tenue e di colore diverso, tenta di avvicinarsi ma viene respinto con una croce prima di raggiungere il ricevente. ATTO 3 · LA FIRMA nessun impostore può falsificarla server di combattimento genera e firma il messaggio il nostro server verifica la firma prima di fidarsi messaggio firma chi la vede non può rifarla verificato impostore respinto
Il server di combattimento appone una firma sul messaggio; il nostro server la controlla all'arrivo e si fida solo se combacia. Un messaggio senza firma valida — un impostore — viene respinto prima di essere creduto.

In pratica, ogni messaggio interno porta con sé una firma crittografica che ne certifica insieme il mittente e il contenuto: se anche un solo carattere del messaggio cambia, la firma non torna e la richiesta viene respinta. La firma vale per pochissimo tempo e non può essere riusata, così nemmeno chi riuscisse a intercettarla potrebbe rigiocarla.

Atto 3 · la chiave del match

La chiave usa-e-getta che apre la porta giusta ai due giocatori giusti.

Trovata la coppia, ciascuno dei due giocatori riceve una chiave — non una qualsiasi, ma una che apre esattamente una porta, una volta sola, e che si smagnetizza da sé dopo pochi minuti. È la stessa idea della tessera di un albergo: nella stanza giusta entra il solo ospite giusto, e passato il soggiorno non serve più a nulla. Così i due avversari accoppiati — e nessun altro — finiscono nella stessa arena, e quella chiave non può essere riusata per intrufolarsi una seconda volta.

Sotto il cofano. Le chiavi sono due gettoni firmati, uno per posto, validi pochi minuti e senza rinnovo. Ciò che li rende sicuri, e non solo presenti, è il modo in cui vengono «consumati»: la prima volta che uno dei due entra nell'arena, la chiave viene marcata come spesa in un'unica operazione indivisibile, e ogni tentativo successivo viene respinto. Ecco l'idea.

La chiave usa-e-getta — una porta, una volta sola Uno schema con un nucleo del match al centro-sinistra che emette due chiavi di partita, una per ogni giocatore. La chiave dorata viaggia verso la porta dell'arena del giocatore A, quella viola verso la porta del giocatore B. Quando una chiave entra nella sua porta, la porta si illumina di verde e si apre. Ogni chiave apre la porta una volta sola: a un secondo tentativo la stessa chiave risulta già usata e scaduta, ingrigita e barrata. Due impulsi in movimento mostrano il verso dell'emissione; il resto dello schema resta leggibile anche con le animazioni disattivate. ATTO 3 · LA CHIAVE DEL MATCH usa-e-getta · una porta, una volta chiave di partita il match emette una chiave per giocatore giocatore A ARENA aperta giocatore B ARENA aperta 2º tentativo 2º tentativo già usata chiave scaduta già usata chiave scaduta chiave giocatore A chiave giocatore B porta aperta chiave usata / scaduta
Ogni match consegna una chiave usa-e-getta per giocatore: apre la porta della propria arena una volta sola, poi scade. Riproporre la stessa chiave non apre più nulla — risulta già usata.

Ogni chiave dice l'essenziale e nulla di più: chi è il suo proprietario, per quale match vale e con quale personaggio. La distinzione tra i due posti, e l'identità dell'avversario, non vivono dentro la chiave. Quando un giocatore si presenta all'arena, il server di combattimento verifica la firma e poi «spende» la chiave in un'unica operazione indivisibile: da quel momento è bruciata, e chiunque ripresenti la stessa chiave viene respinto. È esattamente ciò che impedisce di rigiocare due volte lo stesso match per raddoppiare la ricompensa.

Atto 3 · il risultato, e i buchi che abbiamo chiuso

Come un match finito diventa ricompensa, classifica e dati d'addestramento — senza che nessuno possa falsarlo.

A match finito, chi ha giocato non può essere creduto sulla parola sul risultato: il verdetto viene ricostruito e ri-verificato sui nostri server prima che una singola moneta cambi tasca o che una posizione in classifica si sposti. Solo allora lo stesso risultato diventa tre cose insieme — la ricompensa per chi ha vinto, l'aggiornamento della classifica e una riga di dati con cui alleniamo l'intelligenza artificiale che un giorno giocherà da campione.

Sotto il cofano. Quando un match finisce, il server di combattimento non crea da sé le ricompense: non tocca mai né il portafogli né la classifica. Firma il verdetto e lo manda, con due messaggi firmati separati, ai due servizi che hanno l'autorità di renderlo effettivo — uno accredita le monete e aggiorna la classifica, l'altro aggiorna i punteggi. Ognuno rifa i propri controlli prima di muovere qualcosa.

Solo se tutti questi controlli passano — insieme all'esito positivo di un ulteriore livello di sicurezza, che resta riservato e serve a verificare il flusso dei messaggi — il risultato viene reso effettivo.

Riconciliazione del risultato — da combattimento al server principale e all'accoppiamento Un flusso di riconciliazione a tre nodi. A sinistra, un container di combattimento termina un match ed emette due messaggi firmati in parallelo: uno verso il nostro server principale, nel ramo superiore, che assegna le ricompense e aggiorna le classifiche, e uno verso l'arbitro degli accoppiamenti, nel ramo inferiore, che aggiorna in modo sicuro il punteggio dei giocatori. Entrambi i percorsi convergono su un record di match condiviso e persistente. Lungo ogni percorso, un'icona indica che il passaggio è firmato e verificato sui nostri server. COMBAT · match terminato SERVER PRINCIPALE · ricompense + classifica ACCOPPIAMENTO · aggiorna punteggio DATABASE · record durevole combat-server fine match · autoritativo firma 2 buste firma messaggio firmato 4 GATE verifiche di validità controllo anti-replay server principale verdetto firmato monete + classifica una sola volta per match 3 GATE controlli sull’esito chiave usa-e-getta accoppiamento aggiorna punteggio aggiorna punteggio a lotti · Fase B database rating + wallet solo aggiunta aggiornamenti a lotti CONTROLLI DI SICUREZZA SU QUESTO PERCORSO esito verificato chiave usa-e-getta limiti di dimensione anti-replay accesso protetto limiti di frequenza
Il server di combattimento firma due messaggi in parallelo — uno verso il servizio che accredita le monete, uno verso quello che aggiorna i punteggi. Ogni ramo ha i propri controlli, e il combattimento non tocca mai direttamente portafogli o classifica.

Dal server di combattimento al resto della piattaforma

Il verdetto di fine match viaggia come un messaggio firmato, e chi lo riceve non si fida sulla parola: controlla che la firma sia autentica, che arrivi da un server di combattimento autorizzato, che sia recente e che non sia già stato visto prima. Solo se tutti questi controlli passano, il risultato viene reso effettivo.

Atto 4 · Il combattimento gira vicino a chi gioca

Micro-arene che nascono accanto ai due giocatori, ovunque nel mondo.

Uno scontro non gira in un unico grande centro di calcolo dall'altra parte del pianeta: gira in una piccola arena a sé stante, che nasce nella regione più vicina ai due giocatori, ospita la partita e sparisce non appena finisce. È un sistema avanzato di micro-istanze di combattimento geolocalizzate — tante piccole arene indipendenti che compaiono dove servono, quando servono. Così il duello è reattivo e leale ovunque si trovino gli sfidanti, a Milano come a Tokyo.

Sotto il cofano. È un'architettura distribuita che costruiamo e gestiamo noi, su infrastruttura cloud di produzione vera, con quattro vantaggi concreti.

  • Latenza l'arena si accende nella regione più vicina a entrambi, quindi i comandi viaggiano poco e lo scontro risponde all'istante.
  • Resilienza se una regione ha un problema, lo scontro viene dirottato da solo su una regione vicina — nessuna partita persa, nessun fermo.
  • Adattamento elastico la capacità segue la domanda in tempo reale in tutto il mondo, migliaia di arene ai picchi e quasi nessuna nei momenti calmi, senza sprechi.
  • Integrazione il tutto è intrecciato a fondo con il resto della piattaforma, non appoggiato di lato — un sistema distribuito serio, non una slide.

Il carico di combattimento è la parte più imprevedibile della nostra infrastruttura: nell'ora di punta la richiesta in Europa può valere quattro volte quella dell'Asia nelle sue ore morte, nello stesso arco di 24 ore. Un sistema di micro-arene che si accendono e si spengono da sole, regione per regione, segue quest'onda senza tenere accesa a vuoto una flotta dimensionata sul picco.

Presenza globale — arene effimere vicino ai giocatori Una mappa astratta del mondo con tre regioni generiche: Americhe, Europa, Asia. In ciascuna regione una coppia di giocatori è affiancata da un'arena che si accende accanto a loro, illustrata da un nodo dorato pulsante; poco distante un nodo grigio spento rappresenta un'arena già dismessa al termine di una partita. In basso una fascia mostra un piccolo insieme di arene già pronte. Gli impulsi luminosi indicano le arene attive e il collegamento con i giocatori; ogni animazione si disattiva con le preferenze di riduzione del movimento. PRESENZA GLOBALE · l'arena nasce vicino ai giocatori nessun datacenter di proprietà Americhe giocatori arena vicina attiva dismessa Europa giocatori arena vicina attiva dismessa Asia giocatori arena vicina attiva dismessa POOL CALDO arene già pronte, mai spente pronta pronta pronta arena vicina dismessa pronta giocatori
Ogni arena nasce nella regione più vicina ai due giocatori, ospita lo scontro e si dismette a partita finita; un piccolo insieme di arene resta sempre pronto per ridurre l'attesa.

Perché farlo girare distribuito

Vicino a chi gioca. L'arena si accende nella regione più vicina a entrambi i giocatori, non in un unico punto del globo: i comandi percorrono meno strada e il duello resta reattivo e leale anche fra continenti diversi.

Non si ferma. Se una regione va in difficoltà, lo scontro viene spostato da solo su una regione vicina, senza che nessuno se ne accorga e senza perdere la partita in corso.

Cresce e cala da solo. Il numero di arene segue la domanda minuto per minuto in tutto il mondo: migliaia quando tutti giocano, quasi nessuna nelle ore vuote, nessuna capacità tenuta accesa a vuoto.

Parte del sistema, non un accessorio. Gira su infrastruttura cloud di produzione vera ed è intrecciato a fondo con il resto della piattaforma: la decisione di chi affronta chi, lo svolgimento del match e il resoconto finale restano sempre nelle nostre mani.

Ciclo di vita di un'arena, in un respiro

In ogni regione un piccolo gruppo di arene resta già acceso e pronto; il nostro sistema ne sceglie una e riceve l'indirizzo dove mandare i due giocatori; l'arena accoglie gli sfidanti e ospita la partita; a partita finita firma il verdetto, il servizio delle ricompense accredita le monete e aggiorna le classifiche, e l'arena torna nel gruppo di quelle pronte — quelle di troppo si spengono.

Un gemello locale identico alla produzione

In sviluppo lo stesso sistema di micro-arene gira in un gemello locale: parla esattamente la stessa lingua e accende arene di combattimento quando il server principale è troppo carico. Percorrere lo stesso codice in sviluppo e in produzione significa che i problemi di scala emergono sul portatile, non di domenica sera. Anche questo gemello è stato passato al vaglio di un audit di sicurezza prima di essere usato, ed è racchiuso nella superficie più piccola possibile.

Atto 4 · i numeri, misurati sul campo

Cosa regge davvero, misurato con dati reali.

Ogni cifra di questa parte viene da una rilevazione empirica sotto carico, non da una stima. L'obiettivo è dire con precisione cosa regge lo stack quando lo si spinge, e dove comincia a incrinarsi — anche quando la risposta è scomoda: solo numeri agganciati a prove di carico realmente eseguite, mai una cifra «a milioni» dove le misure dicono migliaia.

Sotto il cofano. Ecco i limiti misurati, riga per riga — carico continuo, scenario peggiore, guadagni dopo aver separato l'arbitro degli accoppiamenti dal server principale — con accanto la fonte di ogni cifra e, dove un numero è un obiettivo di progetto e non una misura già presa, lo si dice apertamente.

Ogni affermazione sulla capacità in questo capitolo è agganciata a una prova di carico registrata nei nostri documenti interni. I numeri qui sotto vengono da rilevazioni empiriche sotto carico, non da stime.

1.000 giocatori simulati insieme, senza sosta

Server di combattimento ~60 MiB, server principale ~3 GiB, tutti gli accoppiamenti fra umani. Stabile e già in uso.

Prova di carico interna di base

10.000 giocatori simulati, caso peggiore (tutti collegati nello stesso istante)

Il database e il servizio di accoppiamento si intasano all'istante. Il rapporto del 23 aprile registra ~2.000 partite andate a buon fine con ~4.500 tentativi di accoppiamento falliti e subito ritentati; la ripartizione a regime «8.000 in coda + 2.000 avviate» citata nelle bozze precedenti è una stima di progetto, non una misura di quel rapporto.

Rapporto di carico interno, 23-04-2026 (Fase A)

Fase A′ parziale, 9 minuti, dopo la separazione dei servizi

Memoria del server principale 1,59 GiB contro 3,08 GiB di partenza (−48%). Servizio di accoppiamento 12 MiB e 0,4% di CPU. Oltre 2.800 coppie. Zero errori di firma.

Rapporto di carico interno, 24-04-2026 (Fase A′)

Processi interni del server principale

Da 32 a 64 processi pronti. L'impostazione di fabbrica si intasava sulla raffica di partite contro istanze locali durante il picco da 10.000 giocatori.

Configurazione del server principale, dopo l'audit

Ritmo di scrittura dei punteggi

Scritture dirette, una alla volta, oggi; la variante a lotti che regge volumi molto più alti è un obiettivo della prossima fase, non ancora rilasciata.

Archivio dei punteggi

Come arriviamo a 10.000 nella prova

Lo strumento che simula il carico su un solo Mac si ferma attorno ai 2.800 giocatori finti, per i limiti della macchina. Per arrivare a 10.000 senza sbattere contro quel tetto teniamo una seconda macchina, con una copia del progetto, che spinge altri giocatori finti verso il Mac sulla rete locale. È così che abbiamo davvero verificato lo scenario da «10.000 giocatori»: ogni numero da 10.000 nelle tabelle qui sopra viene da una prova spinta da quella seconda macchina.

Atto 4 · quando la fila si ferma

Cosa facciamo quando qualcosa si inceppa.

Prima o poi ogni sistema si inceppa. Ciò che distingue un servizio maturo da uno fragile non è non guastarsi mai: è sapere in anticipo come si guasta, e avere già pronto il gesto che lo rimette in moto.

Sotto il cofano. La cosa che conta davvero non è l'elenco dei guasti possibili, ma quello che succede quando uno si presenta: nella maggior parte dei casi il sistema si rimette in sesto da solo, e in nessun caso un guasto lascia dietro di sé un punteggio sbagliato.

Recupero e messa in sicurezza — si rimette in moto da solo e non scrive mai un punteggio sbagliato Due corsie. In alto, la corsia di recupero: da una richiesta, il percorso principale verso una regione in sofferenza si interrompe, segnato da una croce; una via di riserva verde si accende e riprende, portando comunque all'avvio del match. In basso, la corsia del verdetto: il server di combattimento può solo firmare e proporre un esito, che diventa reale solo dopo la ri-verifica dei servizi con autorità. In caso di guasto il verdetto viene scartato in modo pulito e non succede nulla: il punteggio resta invariato, mai sbagliato. ATTO 4 · QUANDO LA FILA SI FERMA resilienza per costruzione 1 · SI RIMETTE IN MOTO DA SOLO richiesta di gioco coppia proposta percorso principale regione A in sofferenza ricade sulla riserva via di riserva regione vicina il match parte non un errore scontro dirottato → regione vicina ricerca vuota → partita contro l'IA coppia rifiutata → riproposta 2 · UN GUASTO NON SCRIVE MAI UN PUNTEGGIO SBAGLIATO server di combattimento può solo firmare e proporre verdetto firmato ri-verifica servizi con autorità tutti i controlli passano punteggio aggiornato reso effettivo, una volta sola crash o messaggio perso → verdetto scartato, pulito non succede nulla punteggio invariato, mai sbagliato
Se un pezzo cede, il percorso ricade su una via di riserva e il match parte lo stesso; e un verdetto conta solo dopo la ri-verifica — nel dubbio, non succede nulla. l'esito peggiore è una fermata pulita

Si rimette in moto da solo

Quasi tutti gli intoppi previsti non hanno bisogno di un intervento a mano. Se una regione o un pezzo va in difficoltà, il percorso ricade da solo su una via di riserva e riprende: lo scontro viene dirottato su una regione vicina, una ricerca che non trova nessuno ripiega su una partita contro l'IA, una coppia rifiutata viene riproposta. Per chi gioca, il risultato è una partita che parte lo stesso, non un errore.

Un guasto non scrive mai un punteggio sbagliato

È la garanzia più importante di tutte. Il server che ospita lo scontro non ha alcun potere di toccare punteggi o monete: può soltanto firmare un verdetto e proporlo. Quel verdetto diventa reale solo dopo che i servizi che ne hanno l'autorità lo ri-verificano per conto proprio. Così, se un server cade a metà partita o un messaggio si perde per strada, l'effetto è sempre «non succede nulla», mai «viene scritto un punteggio sbagliato»: attraverso i guasti, il punteggio resta coerente e affidabile.

È resilienza per costruzione: l'esito peggiore di un guasto è una fermata pulita, dalla quale si riparte, non un dato corrotto da rimettere a posto a mano.

Regola d'oro. Il percorso di matchmaking è disegnato per cedere in sicurezza: a ogni passaggio, se qualcosa non risponde, ricade su una via di riserva senza mai bloccare chi gioca. Per questo, quando qualcosa sembra rotto, la prima domanda non è «quale pezzo è caduto?» ma «perché la via di riserva non è scattata?».