{"id":37812,"date":"2019-10-31T22:19:55","date_gmt":"2019-10-31T19:19:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov\/"},"modified":"2019-10-31T22:19:55","modified_gmt":"2019-10-31T19:19:55","slug":"megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/megapaket-kak-razrabotchikam-factorio-udalos-reshit-problemu-s-multipleerom-na-200-igrokov","title":{"rendered":"MegaPacchetto: come gli sviluppatori di Factorio hanno risolto il problema del multiplayer per 200 giocatori","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MegaPacchetto:
\nA maggio di quest'anno ho partecipato come giocatore a KatherineOfSky, un evento MMO<\/a><\/noindex>. Ho notato che quando il numero di giocatori raggiunge un certo numero, ogni pochi minuti parte di essi \"scompare\". Fortunatamente per voi (ma non per me), ero uno di quei giocatori che si disconnettevano ogni volta<\/b>, anche con una buona connessione. L'ho considerato una sfida personale e ho iniziato a cercare le cause del problema. Dopo tre settimane di debug, test e correzioni, l'errore \u00e8 finalmente stato risolto, ma questo viaggio non \u00e8 stato affatto semplice.<\/p>\n

Le problematiche dei giochi multiplayer sono molto difficili da tracciare. Di solito si verificano in condizioni molto specifiche riguardo ai parametri delle reti e a stati di gioco molto particolari (in questo caso, la presenza di oltre 200 giocatori). E anche quando riesci a riprodurre il problema, non \u00e8 possibile fare un debug adeguato, perch\u00e9 l'inserimento di punti di controllo ferma il gioco, confonde i timer e di solito porta alla chiusura della connessione a causa del timeout. Ma grazie alla perseveranza e a un eccellente strumento chiamato clumsy<\/a><\/noindex> , sono riuscito a scoprire cosa stava succedendo.<\/p>\n

In breve: a causa di un errore e della realizzazione incompleta della simulazione dello stato di ritardo, il client si trovava a volte nella situazione di dover inviare in un solo ciclo un pacchetto di rete composto dalle azioni di input di circa 400 entit\u00e0 di gioco (noi lo chiamiamo \"megapacchetto\"). Dopodich\u00e9, il server non solo deve ricevere correttamente tutte queste azioni di input, ma deve anche inviarle a tutti gli altri client. Se hai 200 client, questo diventa rapidamente un problema. Il canale verso il server si riempie rapidamente, il che porta alla perdita di pacchetti e a un effetto a cascata di pacchetti richiesti nuovamente. Il ritardo nelle azioni di input porta poi a far s\u00ec che ancora pi\u00f9 client inizino a inviare megapacchetti, e la loro valanga diventa ancora pi\u00f9 forte. Ai client fortunati riesce di riprendersi, mentre tutti gli altri \"scompaiono\".
\n<\/a><\/noindex>
\n\"MegaPacchetto:
\nIl problema era abbastanza fondamentale e mi ci sono volute 2 settimane per risolverlo. \u00c8 piuttosto tecnico, quindi di seguito spiegher\u00f2 i dettagli tecnici succosi. Ma per cominciare, \u00e8 necessario sapere che dalla versione 0.17.54, rilasciata il 4 giugno, a causa di problemi temporanei di connessione, il multiplayer \u00e8 diventato molto pi\u00f9 stabile e la mascheratura dei ritardi \u00e8 molto meno glitchata (meno lag e teletrasporti). Inoltre, ho modificato il modo di mascherare i ritardi in combattimento e spero che, grazie a questo, siano un po' pi\u00f9 fluidi.<\/p>\n

Mega pacchetto multiplayer - dettagli tecnici<\/h3>\n

\nSe lo si spiega in modo semplificato, il multiplayer nel gioco funziona nel seguente modo: tutti i client simulano lo stato del gioco, ricevendo e inviando solo l'input del giocatore (chiamato \"azioni di input\", Input Actions<\/i>). L'obiettivo principale del server \u00e8 trasmettere Input Actions<\/i> e controllare che tutti i client eseguano le stesse azioni in un dato ciclo. Puoi leggere di pi\u00f9 in questo post FFF-149<\/a><\/noindex>.<\/p>\n

Poich\u00e9 il server deve prendere decisioni su quali azioni eseguire, le azioni del giocatore passano circa per questo percorso: azione del giocatore -> client di gioco -> rete -> server -> rete -> client di gioco. Questo significa che ogni azione del giocatore viene eseguita solo dopo aver completato un viaggio di andata e ritorno attraverso la rete. A causa di ci\u00f2, il gioco apparirebbe incredibilmente laggoso, dunque praticamente subito dopo l'introduzione del multiplayer nel gioco fu introdotto un meccanismo di mascheratura dei ritardi. La mascheratura dei ritardi simula l'input del giocatore senza considerare le azioni degli altri giocatori e le decisioni del server.<\/p>\n

\"MegaPacchetto:
\nIn Factorio c'\u00e8 uno stato di gioco Game State<\/i> che rappresenta lo stato completo della mappa, del giocatore, delle entit\u00e0 e di tutto il resto. Questo \u00e8 simulato in modo deterministico in tutti i client sulla base delle azioni ricevute dal server. Lo stato di gioco \u00e8 sacro e se mai inizia a differire da quello del server o di qualsiasi altro client, si verifica una desincronizzazione.<\/p>\n

Inoltre Game State<\/i> abbiamo uno stato di ritardo Latency State<\/i>. Questo contiene un piccolo sottoinsieme dello stato principale. Latency State<\/i> non \u00e8 sacro e rappresenta semplicemente un'immagine di come sar\u00e0 lo stato di gioco in futuro in base all'input dato dal giocatore. Input Actions<\/i>.<\/p>\n

Per fare ci\u00f2, conserviamo una copia delle azioni di input Input Actions<\/i> in coda dei ritardi.<\/p>\n

\"MegaPacchetto:
\nCio\u00e8, alla fine del processo, sul lato client, l'immagine appare pi\u00f9 o meno cos\u00ec:<\/p>\n

    \n
  1. Applichiamo Input Actions<\/i> tutti i giocatori a Game State<\/i> come se queste azioni di input fossero state ricevute dal server.<\/li>\n
  2. Rimuoviamo dalla coda dei ritardi tutti Input Actions<\/i>, che, secondo il server, sono gi\u00e0 stati applicati a Game State<\/i>.<\/li>\n
  3. Rimuoviamo Latency State<\/i> e lo ripristiniamo in modo che appaia esattamente come Game State<\/i>.<\/li>\n
  4. Applichiamo tutte le azioni dalla coda dei ritardi a Latency State<\/i>.<\/li>\n
  5. Sulla base dei dati Game State<\/i> e Latency State<\/i> renderizziamo il gioco per il giocatore.<\/li>\n<\/ol>\n

    \nTutto ci\u00f2 si ripete in ogni ciclo.<\/p>\n

    Troppo complicato? Non rilassatevi, non \u00e8 tutto. Per compensare l'instabilit\u00e0 delle connessioni Internet, abbiamo creato due meccanismi:<\/p>\n