Perché alcuni giochi in rete usano l'interpolazione e alcuni usano l'individuazione del percorso per il movimento remoto?

Questa è una domanda un po 'aperta, ma mi piacerebbe vedere qualcuno contribuire con un buon ragionamento per entrambi.

Per un rapido esempio di entrambi:

Modello di interpolazione

Pensa al modello Valve in cui il client riceve frequentemente gli aggiornamenti di posizione e i telecomandi aggiornano le loro posizioni utilizzando l'interpolazione su questi dati.

Percorso-finding

In questo modello, pensa che l'utente invii una destinazione e tutti i pathfind su di essa.

Quali tipi di giochi sono adatti a ciascuno e quando uno dovrebbe usarli ciascuno?

Ho lavorato sul codice di rete per due giochi in rete AAA in tempo reale, uno per smartphone e uno per una console portatile.

Per rispondere direttamente alla tua domanda "perché", beh, alcuni giochi usano l'uno o l'altro perché è più adatto dell'altro. Ciò dipende non solo dal tipo di gioco, ma anche dal tipo di rete di cui stiamo parlando (i cabinet arcade collegati hanno condizioni diverse rispetto ai giochi che dovrebbero essere giocati su 3G) Alcuni giochi usano effettivamente entrambi, o addirittura completamente approcci diversi per sincronizzare i dati!

Vorrei generalizzare e prendere in considerazione non solo i dati posizionali, ma praticamente qualsiasi tipo di dati che è possibile sincronizzare tra due client collegati in rete.

Invece di due possibilità, vorrei proporre uno spettro tra aggiornamenti rigidi e soft.

• Gli aggiornamenti molto duri sono eventi discreti che cambiano immediatamente lo stato sull'altro client, senza alcun tipo di interpolazione, sia perché i dati sono di natura critica (un giocatore è morto), perché non è un tipo di dati a cui si applica l'interpolazione (un online partita a scacchi, messaggi di chat, ecc.) o perché la tua rete ti consente di farlo (pensa a gabinetti arcade collegati in cui l'invio affidabile dell'intero stato di gioco 60 volte al secondo rientra nell'ambito delle possibilità).

  Con questo metodo, i ritardi di rete appariranno invariabilmente come aggiornamenti ritardati e si manifesteranno come personaggi che saltano in giro.

• Hard con aggiornamenti inter / estrapolazione sono simili agli aggiornamenti molto hard, ma per i dati in costante cambiamento, per i quali non è praticamente possibile inviare i dati in modo affidabile ogni volta che cambiano. Pensa di inviare una posizione e un vettore di velocità; dovresti essere in grado di interpolare i dati tra due punti ed estrapolarli dopo di essi. Dovresti avere un piano di emergenza se i dati in arrivo non sono d'accordo con le tue estrapolazioni. Direi che la maggior parte dei giochi che richiedono aggiornamenti di posizione utilizzano questo metodo.

• Hard con gli aggiornamenti di sincronizzazione sono simili a hard con inter / estrapolazione, ma richiedono la sincronizzazione solo raramente. Dovresti usarlo per dati che sono davvero banali da interpolare / estrapolare, come l'orologio in un gioco di combattimento (una volta impostato su entrambi i lati, non è davvero necessario sincronizzare di nuovo in seguito)

• Gli aggiornamenti rigidi ritardati sono simili agli aggiornamenti rigidi, ma quelli che vedi sono dati in passato. Sospetto che in molti giochi arcade musicali in Giappone, dove puoi suonare una canzone contro qualcun altro, stai effettivamente giocando contro i dati dei giocatori registrati in passato, forse ore o addirittura giorni prima. Naturalmente, questo tipo di aggiornamenti è utilizzabile solo quando non interagisci realmente con l'altro giocatore.

• Gli aggiornamenti software consistono nell'invio di dati di pianificazione e nell'esecuzione del piano su tutti gli host. Questo è ciò che chiami "pathfinding". La quantità di dati richiesta per sincronizzare i dati in questo modo è molto più bassa; puoi utilizzare questi tipi di aggiornamenti quando riesci a far fronte a determinate discrepanze nel modo in cui i dati vengono presentati all'utente, ad esempio durante la sincronizzazione di centinaia di nemici.

  Gli aggiornamenti dei dati di pianificazione stessi possono anche essere duri / morbidi come desideri, ovviamente.

• Gli aggiornamenti molto soft vengono utilizzati quando il risultato di un'azione può essere calcolato in modo affidabile molto prima che accada. Devi solo inviare il risultato e l'altro client lo riproduce. Ad esempio, alcuni giochi per browser e smartphone ti consentono di combattere altre persone, ma la battaglia vera e propria richiede ore per risolversi (pensa ai giochi simili a Travian). È molto probabile che questi giochi calcolino il risultato nel momento stesso in cui la battaglia è iniziata, e tu vedi solo i risultati di quella battaglia.

  Un altro esempio non collegato in rete sarebbe in Civilization 4 con animazioni di battaglia abilitate. Quando attacchi qualcuno, il risultato della battaglia viene immediatamente calcolato, ma puoi vederne un'animazione in riproduzione. Posso assicurarti che la battaglia non viene calcolata in quanto animata.

Come puoi vedere, ci sono molti modi per sincronizzare i dati e sono sicuro che puoi immaginarne molti altri. Tutti, tranne i giochi online più semplici, molto probabilmente useranno una combinazione di questi metodi, a seconda del tipo di dati che stanno sincronizzando, del tipo di gioco e persino dello stato della rete (utilizzare gli aggiornamenti rigidi quando il ritardo è basso e andare aggiornamenti più morbidi quando il ritardo aumenta).

Non ho idea del processo di sviluppo di Valve, quindi questa è puramente la mia opinione, ma:

Interpolazione : direi che sarebbe meglio per i giochi frenetici, come ad esempio gli FPS, in cui è importante avere una posizione coerente per un nemico in tempo tra i giocatori. L'interpolazione significa che, anche se alcuni pacchetti vengono eliminati (AFAIK, la maggior parte degli FPS multiplayer utilizza UDP anziché TCP / IP, che garantisce né l'integrità né l'ordine in cui arrivano i pacchetti), si avrà un movimento regolare sullo schermo.

individuazione del percorso : se il tempo non è un elemento cruciale del tuo gameplay e il tuo algoritmo trova un percorso coerente quando viene eseguito nuovamente, l'individuazione del percorso potrebbe essere interessante perché non richiede che tu invii aggiornamenti frequenti e quindi pesanti con la posizione di ogni singolo entità. Direi che questo sembra adatto per un sistema a turni, ad esempio, in cui è quindi possibile limitare la quantità di richieste di rete (una all'inizio del turno, una al termine del turno per assicurarsi che tutti i client siano in condizioni "normali" "stato.

Ancora una volta, non ho mai lavorato su un gioco di rete o per un grande studio di gioco, ma da quello che ho letto a volte è così che lo farei :)

La risposta di Panda Pajama è piuttosto buona.

Fondamentalmente la domanda si riduce a quale sia la quantità minima di dati che è possibile inviare che metterà più clienti nella stessa consapevolezza di ciascuno degli altri stati, e come gestire il ritardo in cui durante tale ritardo i clienti potrebbero trovarsi in uno stato diverso.

Così generato proceduralmente, dove tutte le interazioni sono conosciute prima mano è più semplice, poiché se tutte le variabili sono note, allora il risultato è noto. Ad esempio, isolare qualcuno in una stanza, di cui conosci i metodi di elaborazione e dargli un insieme di dati, puoi prevedere con precisione i risultati. Pertanto, è possibile fornire a tutti gli altri client i risultati senza dover attendere che il client completi il ​​calcolo.

Tuttavia non ha menzionato un metodo. Risultati forzati.

Se il sistema prevede un'azione da parte di un'entità e altre azioni dipendono da quell'azione e altri calcoli tengono conto di quell'azione e sono già stati preelaborati con il risultato previsto. Quindi per mantenere la sincronizzazione, l'intero sistema viene arrestato mentre l'unica entità che non si trova nel posto giusto viene correttamente rimessa sul suo percorso.

Un esempio del mondo reale sono tutte le altre entità in un modello di supporto per assicurarsi che mi venga inviato il giusto compenso.