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 la collocazione di infrastrutture di gioco sensibili alla latenza vicino ai giocatori per migliorare le prestazioni

Il posizionamento separato per infrastrutture sensibili alla latenza come i server di gioco riduce al minimo l'impatto dei lunghi percorsi di rete. Le implementazioni ripetibili possono semplificare la gestione di più postazioni più performanti per i giocatori. Il ping è una metrica comune che compare nell'interfaccia utente di 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 al tuo gioco. Si tratta di una sfida comune e dovreste prepararvi a questo scenario progettando un'architettura che consenta di adattare rapidamente la vostra strategia di posizionamento dell'hosting per distribuire i server dove sono necessari più vicini ai giocatori. È normale che gli sviluppatori di giochi valutino regolarmente l'implementazione dell'infrastruttura di gioco come analisi periodica post-lancio per investire in modo incrementale in miglioramenti nel tempo con un approccio iterativo.

Una best practice consiste nell'utilizzare infrastructure-as-code modelli, come AWS CloudFormation o Terraform di Hashicorp, per la configurazione dell'infrastruttura VPCs, ad esempio le configurazioni di sottorete e le 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.

È inoltre necessario assicurarsi di comprendere in che modo la strategia di implementazione attuale potrebbe essere evoluta per consentire future espansioni. I modelli IaC sono ripetibili ma non sostituiscono la pianificazione della rete. IPAM gestisce il tuo. VPCs Dimensionamento della sottorete, selezione della zona di disponibilità, inventario IP e allineamento della zona di disponibilità tra account. La rete è importante da prendere in considerazione e può causare problemi ai giocatori quando viene modificata. I server di gioco distribuiti in più aree geografiche si collegheranno al backend di gioco, che è più comune se ospitati in una o più aree geografiche, 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 dei giochi man mano che i requisiti del gioco evolvono o cambiano le esigenze dei giocatori.

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

Ciascuna di queste considerazioni dovrebbe 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 inserire tra le tue priorità la monetizzazione dei giocatori, 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 hanno il potenziale di generare entrate incrementali se introduci miglioramenti delle prestazioni.

Oltre all'infrastruttura di hosting in Regioni AWS, puoi utilizzare Local Zones, 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 in Local Zones per migliorare l'esperienza dei tuoi team di sviluppo di giochi. Ad esempio, puoi utilizzare Local Zones 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 EC2 istanze Amazon, volumi EBS e FSx file system Amazon distribuiti in una o più Local Zones vicino ai tuoi studi di sviluppo senza richiedere l'hosting dell'infrastruttura in locale.

Gli Outposts sono un'ottima scelta quando le Regioni o le Local Zones non sono disponibili nella stessa area geografica. La connettività dal data center a AWS dovrebbe essere presa in considerazione per garantire l'affidabilità del server di gioco rispetto al sistema di backend. AWS Outposts e Outpost Servers sono progettati appositamente per funzionare AWS nel tuo datacenter utilizzando gli stessi servizi e APIs per contribuire a creare un modello di distribuzione coerente ovunque esegui il gioco. È possibile combinare più rack in un Outpost logico e condividere l'infrastruttura. Account AWS Il ciclo di vita dell'hardware è gestito da AWS e il lead time 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 nostre Local Zones. AWS Outposts Se offri hosting con Amazon GameLift, Amazon GameLift Anywhere può essere usato per far funzionare il tuo server su hardware locale, velocizzando il processo di sviluppo, consentendoti di utilizzare Local Zones o registrare il tuo metallo come parte del tuo parco macchine.

Passaggi dell’implementazione