2011-09-16 18 views
10

Sto pensando di implementare uno HTML5 mmog in cui è coinvolto un oggetto in esecuzione rapida. I giocatori cambiano costantemente la direzione di quell'oggetto sparandogli sopra. Ho pensato a WebSockets ecc. (socket.io) e tel..Prestazioni WebSockets

Sono convinto che il calcolo del cambio di direzione deve essere eseguito client-AND serveride e quindi sincronizzato, con il server come master per evitare imbrogli.

Le mie preoccupazioni sono che a prescindere dalla velocità del server, la latenza causerà un ritardo e quindi interromperà la sincronizzazione.

C'è un buon modo per risolvere questo enigma? Come ottenere in tempo reale la sincronizzazione di questa quantità di dati in cui tutte le informazioni sono fondamentali per non perdere un cambio di direzione. Tutti i giocatori devono ottenere la nuova direzione dell'oggetto in movimento senza ritardi per non corrompere il gameplay.

Suppongo che questo problema sia stato risolto nei mmog esistenti.

Qualche idea?

+1

È possibile inviare un timestamp con ciascuna azione e quindi fare in modo che il server inserisca retroattivamente l'azione al momento opportuno. (Questo non risolve completamente il tuo problema, in quanto i giocatori potrebbero barare cambiando il timestamp e i giocatori non vedranno il cambiamento più tardi, ma ridurranno i problemi di lag e non sarai in grado di trasmettere i dati istantaneamente non importa cosa fai.) – someone

+1

timestamp basati su client non saranno mai precisi. Il mio orologio è a 2 minuti mentre scrivo il post. – Marc

+0

La domanda principale è se c'è un modo per sincronizzare una grande quantità di dati, aggregati da piccoli messaggi (un giocatore ha sparato/cambia direzione) con un gran numero di connessioni - in tempo reale. – Marc

risposta

7

La cosa migliore che si può fare in questo tipo di situazioni è cercare di prevedere il movimento lato client (calcolo stimato), e quindi correggere la posizione/velocità con i dati dal server se/quando necessario.

Ad esempio, supponiamo che il tuo oggetto in esecuzione veloce si muova da sinistra a destra attraverso lo schermo alla velocità di 5, e un giocatore gli spara e cambia direzione in modo che ora si muova verso l'alto sullo schermo a quella velocità di 5 (Giro di 90 gradi).

L'applicazione sul lato client verrà probabilmente aggiornata molto più frequentemente di quanto non ottenga i dati dal server (ad esempio 60 aggiornamenti al secondo lato client e 10 pacchetti al secondo ricevuti dal server). Diciamo che, in tempo reale, l'oggetto ha cambiato direzione con 5 fotogrammi rimasti prima dell'arrivo dell'aggiornamento del server. Sul lato client, l'oggetto continuerà a spostarsi lungo la sua traiettoria corrente finché non riceve l'aggiornamento dal server che ha cambiato direzione (cioè non si ferma solo quando non riceve dati dal server), a quel punto, il cliente correggerà la posizione e la velocità dell'oggetto.

In che modo la correzione determinerà quanto apparirà nervosa l'animazione. Potresti semplicemente fare lo zapping nella posizione corretta all'istante, causando così un piccolo salto ma dando istantaneamente la posizione corretta, oppure potresti cambiare la sua velocità in modo tale che si muova in una transizione morbida a quella posizione, senza causare alcun salto, ma avendo una posizione leggermente imprecisa durante il tempo medio della correzione.

Avrete sempre alcune situazioni in cui queste correzioni finiranno per essere piuttosto grandi (ad esempio qualcuno ha una connessione veramente brutta, pacchetti scartati, latenza altissima, ecc.). Questo è quando ottieni le anomalie folli che di solito le persone chiamano ritardo nei giochi online, come quando un oggetto salta grandi distanze o si muove velocemente per "recuperare" dove dovrebbe essere. Non c'è assolutamente modo di essere sincronizzati al 100% tutto il tempo. Tutto quello che puoi fare è fare davvero delle buone ipotesi su dove dovrebbero essere le cose.

Ecco alcuni articoli con maggiori dettagli, buona fortuna!

http://gmc.yoyogames.com/index.php?showtopic=415538 http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php

+1

C'è un ottimo video introduttivo di questa tecnica da Adobe MAX 2010 - http://tv.adobe.com/watch/max-2010-develop/building-p2p-multiplayer-games/ – c69

2

Il server è il posto giusto per sincronizzare tutti i tuoi eventi.Non vuoi che ogni giocatore invii i suoi dati di input agli altri giocatori "n" poiché crea troppi percorsi di comunicazione.

Il server acquisisce i dati del giocatore e determina la nuova traiettoria dell'oggetto in movimento e quindi invia aggiornamenti a ciascun giocatore. Questo può essere fatto in unità fisse di tempo di gioco virtuale, che chiamerò "tick".

Dal punto di server di vista questo ti dà un anello come la seguente:

  1. Ricevi input dai giocatori
  2. stato di aggiornamento del gioco
  3. Distribuire gioco i cambiamenti di stato ai giocatori

Avrai bisogno di trattare casi come quelli che non ricevono input dai giocatori entro un certo periodo di tempo (per esempio, forse ignorare quel giocatore per quel frame).

Sul lato client, mentre si attende l'aggiornamento del tick successivo del gioco dal server, è possibile continuare a spostare l'oggetto lungo la traiettoria precedente, rendendo i fotogrammi nel tempo.

Quando viene ricevuto un aggiornamento dal server per il tick corrente del gioco, deve essere applicato il nuovo stato del gioco.

Se la nuova posizione reale dell'oggetto è molto vicina alla posizione che hai estrapolato, puoi semplicemente impostare la nuova posizione e renderla il prossimo fotogramma.

Se la nuova posizione è "lontana" dalla posizione estrapolata, è necessario decidere se deformare l'oggetto immediatamente verso la destinazione o eseguire una sorta di movimento accelerato o lineare per spostarlo lì in un breve periodo di tempo .