Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

GAMEPERF02-BP02 Progetta un approccio che supporti il posizionamento dell'infrastruttura di gioco sensibile alla latenza vicino ai giocatori per migliorare le prestazioni

Il posizionamento separato per le infrastrutture sensibili alla latenza, come i server di gioco, riduce al minimo l'impatto delle lunghe rotte di rete. Le implementazioni ripetibili possono semplificare la gestione di più sedi con prestazioni più elevate per i giocatori. Il ping è una metrica comune che compare nell'interfaccia utente del gioco e un ping basso può essere una caratteristica distintiva.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all’implementazione

Quando avvii un gioco per la prima volta, potresti non disporre ancora di informazioni sufficienti sulla tua base di giocatori per sapere in modo adeguato dove implementare l'infrastruttura più vicina ai giocatori più interessati a giocare. Si tratta di una sfida comune e dovreste prepararvi a questo scenario progettando un'architettura che consenta di adattare rapidamente la strategia di collocamento degli host in modo da distribuire i server laddove necessario più vicini ai giocatori. È normale che gli sviluppatori di giochi valutino regolarmente l'implementazione dell'infrastruttura di gioco come analisi ricorrente post-lancio per investire in modo incrementale nei miglioramenti nel tempo con un approccio iterativo.

Una buona pratica consiste nell'utilizzare modelli infrastructure-as-code, come AWS CloudFormation Terraform di Hashicorp, per la configurazione dell'infrastruttura come VPC, configurazioni di sottorete e dipendenze necessarie per avviare servizi di gioco critici in modo da poter fare riferimento a questi modelli, personalizzarli rapidamente se necessario e distribuirli in luoghi in cui è necessaria un'infrastruttura aggiuntiva per supportare i giocatori.

Dovresti anche assicurarti di capire come la tua attuale strategia di distribuzione potrebbe essere evoluta per consentire un'espansione futura. I modelli IaC sono ripetibili ma non sostituiscono la pianificazione della rete. IPAM gestisce i tuoi VPC. Dimensionamento della sottorete, selezione della zona di disponibilità e allineamento dell'inventario IP e della zona di disponibilità tra account. La rete è importante da tenere in considerazione e può essere dannosa per i giocatori quando viene modificata. I server di gioco distribuiti in più posizioni geografiche si connetteranno al backend di gioco, che è più comune essere ospitati in una o più regioni domestiche e che possono richiedere una configurazione aggiuntiva per supportare la connettività privata. Queste considerazioni devono essere valutate continuamente nel tempo in modo da poter apportare modifiche alla strategia di hosting del gioco man mano che i requisiti del gioco evolvono o i requisiti dei giocatori.

Nel determinare il numero di sedi di hosting da utilizzare per il gioco, considera i seguenti fattori:

Ognuna di queste considerazioni deve essere valutata nel determinare dove aggiungere o rimuovere le sedi di hosting dei giochi. Ad esempio, puoi scegliere di dare priorità al miglioramento dell'esperienza per i giocatori in aree geografiche con l'esperienza di gioco meno performante o per i giocatori che esprimono il feedback pubblico più esplicito. Puoi anche scegliere di includere la monetizzazione dei giocatori tra le tue priorità, ad esempio concentrando l'attenzione sul miglioramento dell'esperienza dei giocatori in aree geografiche che generano una fonte significativa di entrate per il tuo gioco o che potrebbero generare entrate incrementali se introduci miglioramenti delle prestazioni.

Oltre all'infrastruttura di hosting in Regioni AWS, puoi utilizzare le zone locali, che sono un'estensione di un Regione AWS, per ospitare i tuoi server di gioco e altre applicazioni sensibili alla latenza, come i server di chat vocale, più vicini ai tuoi giocatori. Puoi anche scegliere di gestire l'infrastruttura di sviluppo dei giochi nelle zone locali per migliorare l'esperienza dei tuoi team di sviluppo dei giochi. Ad esempio, puoi utilizzare le zone locali per risolvere casi d'uso come l'hosting di repliche dei tuoi server di controllo del codice sorgente autogestiti più vicino agli sviluppatori di giochi e per offrire workstation virtuali per lo sviluppo di giochi e storage di contenuti agli utenti che utilizzano istanze Amazon EC2, volumi EBS e file system Amazon FSx distribuiti in una o più zone locali vicine ai tuoi studi di sviluppo senza dover ospitare l'infrastruttura in locale.

Gli avamposti sono una buona scelta quando le regioni o le zone locali non sono disponibili nella stessa area geografica. È AWS necessario prendere in considerazione la connettività dal data center al server di gioco per consentire l'affidabilità del sistema di backend dal server di gioco. AWS Outposts e i server Outpost sono progettati appositamente per funzionare AWS nel tuo datacenter utilizzando gli stessi servizi e le stesse API per contribuire a creare un modello di distribuzione coerente ovunque tu giochi. È possibile combinare più rack in un Outpost logico e l'infrastruttura può essere condivisa tra loro. Account AWS Il ciclo di vita dell'hardware è gestito da AWS e il tempo di consegna può essere di soli 3 mesi.

Se stai creando giochi utilizzando contenitori e desideri la flessibilità necessaria per adottare un'architettura di distribuzione ibrida utilizzando software open source che può essere distribuito sulla tua infrastruttura locale, puoi utilizzare ECS Anywhere o EKS Anywhere come alternativa alle zone locali. AWS Outposts Se esegui l'hosting con Amazon GameLift, Amazon GameLift Anywhere può essere utilizzato per eseguire il tuo server costruito su hardware locale che può accelerare il processo di sviluppo, consentendoti di utilizzare le zone locali o registrare il tuo metallo come parte della tua flotta.

Passaggi dell’implementazione