View a markdown version of this page

Hosting di server di gioco basato sulla sessione con backend senza server - Games Industry Lens

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à.

Hosting di server di gioco basato sulla sessione con backend senza server

Quando sviluppi un'architettura per il tuo gioco, considera le caratteristiche e le capacità di cui hai bisogno e il livello di gestione operativa che sei disposto a gestire. Per offrire il miglior equilibrio tra facilità d'uso e flessibilità, puoi creare il tuo gioco utilizzando i servizi gestiti dei provider di cloud. I servizi gestiti ti offrono il controllo necessario per sviluppare e personalizzare le tue funzionalità di gioco personalizzate, riducendo al contempo il carico di implementazione e gestione dell'infrastruttura.

Per ospitare un gioco multiplayer basato su sessioni è necessario disporre di un'infrastruttura server per ospitare i processi del server di gioco e di un backend scalabile per il matchmaking e la gestione delle sessioni. La seguente architettura di riferimento mostra come utilizzare l'hosting GameLift gestito di Amazon e un backend serverless per gestire i giochi basati su sessioni.

Hosting GameLift gestito da Amazon per giochi basati su sessioni

Hosting GameLift gestito da Amazon per giochi basati su sessioni

Il diagramma descrive il processo per far sì che i giocatori accedano ai giochi in esecuzione su un hosting di giochi GameLift gestito. Include i seguenti passaggi:

  1. Il client di gioco richiede un'identità Amazon Cognito da un pool di identità Amazon Cognito. Questo può essere collegato facoltativamente a provider di identità esterni.

  2. Il client di gioco riceve credenziali di accesso temporanee e richiede una sessione di gioco tramite un Amazon API Gateway firmando la richiesta con le credenziali di Amazon Cognito.

  3. API Gateway richiama una AWS Lambda funzione.

  4. La funzione Lambda richiede i dati dei giocatori da una tabella Amazon DynamoDB. L'identità di Amazon Cognito viene utilizzata per richiedere in modo sicuro i dati corretti del giocatore perché l'identità autenticata viene fornita nei dati contestuali della richiesta.

  5. Utilizzando i dati corretti del giocatore per ulteriori informazioni (come il livello di abilità del giocatore), la funzione Lambda richiede una partita tramite GameLift FlexMatch matchmaking. Puoi definire una configurazione di FlexMatch matchmaking con documenti di configurazione basati su JSON. Il client di gioco può generare metriche di latenza eseguendo il ping degli endpoint del server in varie regioni, e i dati sulla latenza possono essere utilizzati per supportare il matchmaking basato sulla latenza.

  6. Dopo aver FlexMatch abbinato un gruppo adeguato di giocatori con una latenza adeguata in una regione, richiede che la sessione di gioco venga posizionata in coda. GameLift La coda contiene flotte con una o più sedi regionali registrate.

  7. Quando la sessione viene effettuata in una delle sedi della flotta, viene inviata una notifica di evento a un argomento di Amazon SNS.

  8. Una funzione Lambda riceverà l'evento Amazon SNS e lo elaborerà.

  9. Se il messaggio Amazon SNS è un MatchmakingSucceeded evento, la funzione Lambda scrive il risultato su DynamoDB con la porta del server e l'indirizzo IP. Un valore time-to-live (TTL) viene utilizzato per garantire che i ticket di matchmaking vengano eliminati da DynamoDB quando non sono più necessari.

  10. Il client di gioco invia una richiesta firmata ad API Gateway per verificare lo stato del ticket di matchmaking in un intervallo specifico.

  11. API Gateway richiama una funzione Lambda che verifica lo stato del ticket di matchmaking.

  12. La funzione Lambda controlla DynamoDB per determinare se il ticket ha avuto successo. Se ha avuto successo, la funzione Lambda invia l'indirizzo IP, la porta e l'ID della sessione del giocatore al client. Se il ticket non è riuscito, la funzione Lambda invia una risposta dichiarando che la partita non è pronta.

  13. Il client di gioco si connette al server di gioco tramite TCP o UDP utilizzando la porta e l'indirizzo IP forniti dal backend. Invia l'ID della sessione del giocatore al server di gioco e il server di gioco lo convalida utilizzando l'SDK Amazon GameLift Server.

In alternativa, puoi modificare l'architettura precedente per utilizzare API Gateway WebSockets con Amazon GameLift. In questo approccio, la comunicazione tra il client di gioco e il servizio di backend di gioco avviene tramite un'implementazione WebSocketbasata. Questa implementazione può essere utilizzata in modo che la funzione Lambda del backend del gioco invii un messaggio lato server al client di gioco utilizzando WebSocket un modello di polling anziché implementare.