Glenn nel suo articolo e nei suoi commenti fornisce un caso molto valido per l'utilizzo di UDP su TCP, ma SC2 ovviamente usa TCP.
Glenn parla principalmente di giochi basati sulla fisica, ad es. sparatutto in prima persona e giochi di guida. Questi hanno requisiti diversi per i giochi di strategia in tempo reale in cui sono importanti posizioni precise delle unità in ogni fase della logica. Quindi le strategie di comunicazione sono necessariamente diverse.
"Tempo reale" significa cose diverse in contesti diversi. I giochi non sono in tempo reale "difficili" in quanto se un messaggio è in ritardo, il tutto si rompe. (Almeno, non c'è una buona ragione per cui un gioco sia così impegnativo, poiché un sistema solo software dovrebbe essere in grado di recuperare dai ritardi di elaborazione, a differenza di una centrale nucleare o di un pezzo di attrezzatura medica per esempio.) I giochi sono davvero tempo reale "morbido" o "solido". ( Definizioni su Wikipedia come al solito .) Il tipo di gioco fa la differenza sulla velocità con cui hai bisogno delle informazioni, se puoi perdere informazioni e cavartela, ecc. Basti dire che TCP è abbastanza buono per molti giochi, ma per altri giochi, è preferibile UDP.
Immagino che il suo approccio sia quello di inviare lo stato di gioco completo di ogni unità su ogni frame.
Manderebbe abbastanza informazioni per ricostruire lo stato di gioco rilevante di qualsiasi unità che è cambiata.
- Non è necessario inviare alcuna informazione su qualcosa che non è cambiato.
- Non è necessario inviare lo stato completo se è possibile inviare informazioni sufficienti per consentire al destinatario di costruire il nuovo stato dal vecchio stato. (ad esempio, basta inviare un valore delta relativo a un vecchio stato. O semplicemente inviare le parti dello stato che sono cambiate e non il resto.)
- Se due giochi eseguono esattamente lo stesso algoritmo e hanno esattamente gli stessi dati, puoi semplicemente inviare input e il destinatario resimula gli effetti localmente per ricavare il nuovo stato.
La maggior parte dei giochi non soddisfa i criteri per 3, quindi usa 1 e 2. Tuttavia, molti giochi RTS possono e fanno uso di 3.
Inoltre, non deve necessariamente essere "ogni frame". Anche il concetto di cornice è nebuloso. È una cornice di rendering? È un lotto di logica? È un frame di dati di rete inviati? I tre si allineano sempre uno a uno o si ottiene una frequenza grafica variabile con velocità logiche fisse? Alcuni giochi, in particolare giochi di strategia in tempo reale come Starcraft 2, o giochi con capacità di rigiocabilità (quando lo tocchi) gradiscono mantenere tutto in perfetto stato grazie a regolari aggiornamenti di rete (che possono o meno corrispondere a "frame" in altri sensi) ma questo non è un requisito per tutti i giochi. Molti giochi inviano semplicemente aggiornamenti su base semi-regolare, a seconda di quanto sono disposti a lasciare correre i clienti.
L'input del giocatore è importante e la sequenza di input è ancora più importante. Non credo sia fattibile l'invio di SC2 a 200 unità e più a 30-60 FPS.
Molti giochi non considerano necessariamente un frame di rendering come un frame logico. Potrebbero avere 60FPS in grafica ma solo 10 aggiornamenti logici al secondo e inviare 1 aggiornamento di rete per ognuno. Ma anche 30 aggiornamenti di rete al secondo sono ragionevoli se si utilizza il metodo "invia input", certamente.
Ho tentato di identificare 2 possibili tipi di dati. Quali sono altre tecniche? Sarà bello ripetere il gioco se lo desideri.
Non è tanto che esistono tecniche distinte, ma diversi vincoli sui sistemi e l'importanza di ogni vincolo varierà da gioco a gioco. Quindi devi solo scegliere un sistema che funzioni per te.
- Poche unità, che si muovono rapidamente e in modo irregolare tramite l'input dell'utente, la latenza è sensibile, la sincronizzazione esatta tra i sistemi non è importante: trasmettere le posizioni tramite un protocollo inaffidabile (ad es. UDP) per ottenere la massima velocità, e i messaggi persi non contano come uno nuovo vieni presto. Simula la fisica a livello locale per migliorare la qualità di rendering, ma correggi le posizioni quando arrivano nuove informazioni. Ottimo per tiratori e giochi di guida.
- Molte unità, ma la maggior parte sono irrilevanti e si muovono lentamente: inviano solo aggiornamenti per le unità vicino al destinatario, inviandole come modifiche anziché come stati completi, inviandole relativamente di rado e inviando un protocollo affidabile (ad es. TCP) per evitare di avere preoccuparsi di come gestire gli aggiornamenti persi. Buono per gli MMO.
- Molte unità, spostate dall'intelligenza artificiale in base all'input dell'utente precedente, la sincronizzazione esatta tra i sistemi è molto importante: inviare un input utente con indicazione del tempo su un protocollo affidabile e risimulare localmente per mantenere sincronizzato lo stato degli algoritmi di gioco. Buono per RTS e giochi a turni.