Questa Guida aiuta gli sviluppatori a testare, visualizzare e ottimizzare i loro giochi multigiocatore utilizzando il kit di strumenti per l'esecuzione di test di Amazon GameLift. Grazie al kit di strumenti, gli sviluppatori possono risolvere i problemi, eseguire il debug e ottimizzare l'infrastruttura Amazon GameLift. Questa Guida offre la possibilità facoltativa di utilizzare giocatori virtuali che eseguono lo stesso codice dei giocatori reali, consentendo agli sviluppatori di poter testare il successo del gioco prima di avviarne la produzione.
Diagramma di architettura
Fase 1
Amazon CloudFront fornisce l'accesso alla console web del kit di strumenti, archiviata su Amazon Simple Storage Service (Amazon S3). Gli utenti della console del kit di strumenti si autenticano con i pool di utenti di Amazon Cognito.
Fase 2
La console web si connette a un'API WebSocket di Gateway Amazon API, che esegue la chiamata di una funzione AWS Lambda per elaborare le richieste e archiviare i dati in Amazon DynamoDB.
Fase 3
La funzione Lambda può eseguire query e aggiornare direttamente l'infrastruttura di Amazon GameLift.
Fase 4
L'ascoltatore del gioco riceve gli eventi GameLift tramite Amazon EventBridge e utilizza AWS Step Functions per eseguire il polling e ricevere aggiornamenti dell'infrastruttura da GameLift e Amazon CloudWatch.
Fase 5
L'ascoltatore del gioco invia dati aggregati relativi agli eventi tramite un router di eventi EventBridge personalizzato. La ricezione degli eventi avviene tramite una funzione Lambda che archivia i dati in DynamoDB ed esegue chiamate al Gateway API per inviare dati agli utenti della console Web connessi per la visualizzazione.
Fase 6
L'utente della console Web può anche avviare attività dei giocatori virtuali su AWS Fargate per simulare client di gioco reali.
Fase 7
Ogni attività dei giocatori virtuali richiede un'identità ospite di Amazon Cognito e si connette a Gateway API dei servizi client di gioco per richiedere il matchmaking.
Fase 8
Le funzioni Lambda eseguono chiamate al GameLift FlexMatch per avviare il processo di matchmaking e inserire le partite riuscite in un parco utilizzando le code delle sessioni di gioco.
Fase 9
Le attività dei giocatori virtuali si connettono alle istanze del parco di GameLift per avviare le sessioni di gioco.
Fase 1
Amazon CloudFront fornisce l'accesso alla console web del kit di strumenti, archiviata su Amazon Simple Storage Service (Amazon S3). Gli utenti della console del kit di strumenti si autenticano con i pool di utenti di Amazon Cognito.
Fase 2
La console web si connette a un'API WebSocket di Gateway Amazon API, che esegue la chiamata di una funzione AWS Lambda per elaborare le richieste e archiviare i dati in Amazon DynamoDB.
Fase 3
La funzione Lambda può eseguire query e aggiornare direttamente l'infrastruttura di Amazon GameLift.
Fase 4
L'ascoltatore del gioco riceve gli eventi GameLift tramite Amazon EventBridge e utilizza AWS Step Functions per eseguire il polling e ricevere aggiornamenti dell'infrastruttura da GameLift e Amazon CloudWatch.
Fase 5
L'ascoltatore del gioco invia dati aggregati relativi agli eventi tramite un router di eventi EventBridge personalizzato. La ricezione degli eventi avviene tramite una funzione Lambda che archivia i dati in DynamoDB ed esegue chiamate al Gateway API per inviare dati agli utenti della console Web connessi per la visualizzazione.
Fase 6
L'utente della console Web può anche avviare attività dei giocatori virtuali su AWS Fargate per simulare client di gioco reali.
Fase 7
Ogni attività dei giocatori virtuali richiede un'identità ospite di Amazon Cognito e si connette a Gateway API dei servizi client di gioco per richiedere il matchmaking.
Fase 8
Le funzioni Lambda eseguono chiamate al GameLift FlexMatch per avviare il processo di matchmaking e inserire le partite riuscite in un parco utilizzando le code delle sessioni di gioco.
Fase 9
Le attività dei giocatori virtuali si connettono alle istanze del parco di GameLift per avviare le sessioni di gioco.
Principi di Well-Architected
Il framework AWS Well-Architected consente di valutare i pro e i contro delle decisioni prese durante il processo di creazione di sistemi nel cloud. I sei principi del framework consentono di apprendere le best practice architetturali per la progettazione e il funzionamento di sistemi affidabili, sicuri, efficienti, convenienti e sostenibili. Grazie allo strumento AWS Well-Architected, disponibile gratuitamente nella Console di gestione AWS, puoi rivedere i tuoi carichi di lavoro rispetto a queste best practice rispondendo a una serie di domande per ciascun principio.
Il diagramma dell'architettura sopra riportato è un esempio di una soluzione creata tenendo conto delle best practice Well-Architected. Per essere completamente Well-Architected, dovresti seguire il maggior numero possibile di best practice.
-
Eccellenza operativaLeggi il whitepaper sull'eccellenza operativa
Sia il kit di strumenti che l'esempio di gioco sono completamente implementati con l'infrastructure as code, il che riduce errori causati da processi manuali e riduce lo sforzo di implementazione delle modifiche.
-
SicurezzaLeggi il whitepaper sulla sicurezza
L'API della console Web serverless su Gateway API è protetta tramite l'autenticazione basata su AWS Identity and Access Management (IAM) contro un pool di utenti Amazon Cognito.
Il back-end serverless dell'esempio di gioco su Gateway API è protetto tramite un'autenticazione basata su IAMper la convalida sicura dell'identità ospite del giocatore.
I server di gioco su GameLift consentono l'accesso esclusivamente alle porte utilizzate per la comunicazione client-server. Le funzioni di back-end Lambda hanno accesso solo ai servizi necessari.
-
AffidabilitàLeggi il whitepaper sull'affidabilità
I dati vengono archiviati in tabelle DynamoDB, utilizzando l'allocazione della capacità on-demand per scalare automaticamente in base alle variazioni della domanda.
I servizi di back-end per soluzioni utilizzano Lambda che scala automaticamente le istanze.
Il back-end dell'esempio di gioco supporta il dimensionamento automatico basato su target GameLift per gestire le variazioni della domanda.
-
Efficienza delle prestazioniLeggi il whitepaper sull'efficienza delle prestazioni
Utilizzando tecnologie gestite e serverless tra cui Gateway API, Lambda, DynamoDB e Fargate, sono a pagamento esclusivamente le risorse utilizzate ed è possibile ridurre lo sforzo operativo necessario per il mantenimento della soluzione.
La soluzione può essere implementata in una regione a scelta e utilizza CloudFront per ridurre la latenza per l'utente finale della console Web.
-
Ottimizzazione dei costiLeggi il whitepaper sull'ottimizzazione dei costi
Le attività dei giocatori virtuali possono essere avviate con Fargate Spot per ridurre i costi dei test.
La console Web e i back-end degli esempi di gioco utilizzano tecnologie serverless così che i prezzi vengano calcolati esclusivamente sulle risorse configurate.
Il back-end della console Web utilizza le funzionalità di dimensionamento native di Lambda e Gateway API, con le tabelle DynamoDB che utilizzano l'allocazione della capacità on-demand per garantire che le risorse corrispondano alla domanda.
Il back-end dell'esempio di gioco supporta il dimensionamento automatico basato su target GameLift per ridurre al minimo le risorse richieste.
-
SostenibilitàLeggi il whitepaper sulla sostenibilità
La Guida utilizza ampiamente i servizi gestiti, il che trasferisce la responsabilità di garantire un utilizzo medio-elevato ad AWS.
Il back-end dell'esempio di gioco supporta il dimensionamento automatico basato su target GameLift per ridurre al minimo le risorse richieste. Impacchettando le sessioni di gioco nel numero minimo di istanze del server, l'utilizzo delle risorse viene mantenuto costantemente elevato.
Grazie all'ampio utilizzo dei servizi gestiti, la Guida riduce l'impatto individuale sull'ambiente.
È possibile ridurre ulteriormente l'impatto sulla sostenibilità delle risorse inutilizzate avviando i server di gioco sul parco istanze spot e avviando le attività dei giocatori virtuali su Fargate Spot.
Risorse per l'implementazione
Il codice di esempio è un punto di partenza. È convalidato dal settore, prescrittivo ma non definitivo, ed è il punto di partenza per iniziare a lavorare.
Contenuti correlati
Titolo
Titolo
Avvertenza
Il codice di esempio, le librerie software, gli strumenti della linea di comando, le proof of concept, i modelli e le altre tecnologie correlate (comprese tutte le tecnologie di cui sopra fornite dal nostro personale) vengono forniti all'utente sotto forma di contenuto AWS ai sensi dell'Accordo cliente AWS o del relativo accordo scritto stipulato tra l'utente e AWS (a seconda dei casi). Non bisogna utilizzare il contenuto AWS in questione negli account di produzione o sui dati di produzione o altri dati fondamentali. L'utente è responsabile dei test, della sicurezza e dell'ottimizzazione del contenuto AWS, come il codice di esempio, in modo appropriato per l'utilizzo in produzione sulla base delle pratiche e degli standard di qualità specifici. L'implementazione del contenuto AWS può comportare costi AWS per la creazione o l'utilizzo di risorse AWS addebitabili, quali le istanze Amazon EC2 in esecuzione o l'archiviazione Amazon S3.