Koncepty a triky real-time her více hráčů

Koncepty a triky real-time her více hráčů

Letos včetně ručně malovaných SVG diagramů

Motivace

• Počítače jsou výkonné
• Internet je rychlý (Steam: průměr ČR 16.5 Mb/s)
• Latence je nízká
• Hráči hrají pro zábavu

Motivace

• Počítače jsou zavirované
• Internet je pomalý (Seznam: medián ČR 3.8 Mb/s)
• Latence je vysoká
• Hráči podvádí, kde můžou

Plán přednášky

• Způsoby řešení problémů (20 minut)
• JS knihovna
• Ukázky kódu
• Interaktivní dema
• Diskuze

#1: autoritativní server

• Prevence podvodů
• Hráčův počítač může zobrazovat cokoliv…
• …ale ostatní musí mít data čistá
• Zdrojem dat/pravdy je vždy server (tj. nikoliv peer-to-peer)

Autoritativní server

• Na serveru probíhá veškerá simulace (stav hry, fyzika)
• Server přijímá informace od hráče
• Po zpracování a/nebo validaci je distribuuje dál
• Distribuovat lze buď stav, nebo vstupy

Distribuce vstupů

• Při připojení dostane klient od serveru kompletní herní stav
• Dále už server distribuuje pouze informace o vstupních událostech
• Poměrně málo používaný model
• Hodí se tam, kde je stav neprakticky objemný (real-time strategies)
• Nutnost identicky fungujících chytrých klientů (viz dále)

Chytrý klient

Od chytrého klienta vyžadujeme:

• 100% spolehlivý transportní protokol
• implementace veškerého simulačního kódu
• fyzika
• numerika
• RNG

Distribuce stavu

• Server periodicky posílá klientům stav (optimalizace: rozdíl stavu)
• Klient může být hloupoučký
• Transportní protokol může být nespolehlivý
• Často používaný model
• Hodí se tam, kde je stav malý (first-person shooters)

Autoritativní server: je nutný?

• Pokud distribuujeme jen vstupy, odpadá nutnost autorizace dat
• Ale: P2P může přinášet další komplikace
  • Není možné přidat klienty za běhu
  • N2 spojení mezi klienty
  • Někdy nelze klienty spojit přímo (NAT, …)

#2: synchronizace času

• Ve všech případech je nutné mít stejně nařízené hodinky
• Předpokládáme, že hodiny jdou všem stejně rychle
• Stačí znát rozdíl času mezi klientem a serverem

Synchronizace času

Synchronizace času

O kolik se liší čas na serveru?

1. Klient pošle žádost o odpověď a poznamená si svůj T1
2. Server pošle odpověď a doplní ji o svůj čas T2
3. Klient přijme odpověď v čase T3
4. One-way latence je L = (T3−T1) / 2
5. V čase T3 bylo na serveru T2+L ⇒ známe rozdíl hodin

Synchronizace času

• Algoritmus předpokládá stejnou latenci k serveru i od něj
• Přesnějších výsledků docílíme pomocí statistických metod
• Na této metodě funguje i NTP

#3: zpoždění na klientu

• Klient dostává stav ze serveru
• Kvůli server→client latenci jsou to ale stará data
• Navíc nemusí přicházet pravidelně
• Nejsou okamžitě použitelná
• Řešení: extrapolace a interpolace

Extrapolace (dead reckoning)

• Jednoduché, ale ne příliš přesné řešení
• Technika převzatá z námořní navigace
• Ztracenou loď vystopujeme podle několika posledních známých pozic
• Klient obdržel data z času TN v čase TN+L
• Extrapolací dat z TN-1 a TN získáme odhad aktuálního stavu

Extrapolace

Interpolace

• Trik: klient zobrazuje data se zpožděním, tj. v minulosti
• Klient si drží zásobu několika herních stavů ze serveru
• V okamžiku T lze stav interpolovat z dat T−1 a T+1

Interpolace

Interpolace

• Typicky je klientovo zpoždění nízké (do 100ms), uživatel si nevšimne
• Přesnější výsledky, než u extrapolace
• Paměťově, výkonově i implementačně náročnější

#4: zpoždění na serveru

• Mezi klientem a serverem je zpoždění
• Události přicházející od klienta nelze aplikovat na aktuální herní stav
  • To by jinak nebylo možné trefit pohyblivý cíl
  • Poor man's solution: Aim leading

Lag compensation

• Server ovšem může znát stav ve chvíli vzniku klientské události
  • Interpolace/extrapolace do minulosti
• Server proto aplikuje klientskou událost na korespondující herní stav
• Poté zahodí, přepočítá (přesimuluje) a rozdistribuuje aktuální herní data

#5: okamžitý feedback

• Klient potřebuje od serveru potvrzení, že událost byla přijata a zpracována
• Co má do té doby dělat a/nebo ukazovat?
• Lze předpokládat, že v naprosté většině případů kladné potvrzení přijde

Client-side prediction

• Než se server vyjádří, klient může samostatně simulovat podmnožinu herního stavu
• Musí k tomu mít ale (identický) kód
• Sám simuluje jen data, ovlivněná vzniklou událostí
• Pokud server potvrdí, stačí jen převzít jeho nová data
• Pokud server zamítne, je to problém (nekonzistentní uživatelský zážitek)