Atvirojo kodo žaidimai debesyje WebRTC: p2p, kelių žaidėjų režimas, nulinis delsos laikas

Programinė įranga kaip paslauga, infrastruktūra kaip paslauga, platforma kaip paslauga, komunikacijos platforma kaip paslauga, vaizdo konferencijos kaip paslauga, o kaip su debesų žaidimais kaip paslauga? Jau buvo keli bandymai sukurti žaidimus debesyje („Cloud Gaming“), pvz., „Stadia“, kurį neseniai pristatė „Google“. Stadia ne naujiena WebRTC, bet ar kiti gali naudoti WebRTC taip pat?

Thanh Nguyen nusprendė išbandyti šią galimybę savo atvirojo kodo projekte „CloudRetro“. „CloudRetro“ yra pagrįsta „Pion“, populiarus WebRTC biblioteka, pagrįsta Go (ačiū Parodyta iš Pion kūrimo komandos už pagalbą rengiant šį straipsnį). Šiame straipsnyje Thanhas apžvelgia savo projekto architektūrą, taip pat pasakoja, kokių naudingų dalykų išmoko ir su kokiais iššūkiais susidūrė dirbdamas.

Įrašas

Praėjusiais metais, kai „Google“ paskelbė apie „Stadia“, tai mane sukrėtė. Idėja yra tokia unikali ir naujoviška, kad nuolat galvojau, kaip tai įmanoma naudojant esamas technologijas. Noras geriau suprasti šią temą paskatino mane sukurti savo atvirojo kodo debesų žaidimo versiją. Rezultatas buvo tiesiog fantastiškas. Žemiau norėčiau pasidalinti savo metų darbo procesu projektą.

TLDR: trumpa skaidrių versija su akcentais

Kodėl debesų žaidimai yra ateitis

Tikiu, kad „Cloud Gaming“ greitai taps naujos kartos ne tik žaidimų, bet ir kitų informatikos sričių. Žaidimai debesyje yra kliento / serverio modelio viršūnė. Šis modelis maksimaliai padidina užpakalinės sistemos valdymą ir sumažina priekinės sistemos darbą, priglobdamas žaidimo logiką nuotoliniame serveryje ir srautiniu būdu perduodamas vaizdus / garsą klientui. Serveris atlieka sunkų apdorojimą, todėl klientas nebegali būti priklausomas nuo aparatinės įrangos apribojimų.

„Google Stadia“ iš esmės leidžia žaisti AAA žaidimai (t. y. aukščiausios klasės populiariausių žaidimų) sąsajoje, pvz., „YouTube“. Ta pati metodika gali būti taikoma ir kitoms sunkioms neprisijungus naudojamoms programoms, tokioms kaip operacinė sistema arba 2D/3D grafinis dizainas ir kt. kad galėtume juos nuosekliai paleisti žemos specifikacijos įrenginiuose keliose platformose.

Šios technologijos ateitis: įsivaizduokite, jei „Microsoft Windows 10“ veiktų „Chrome“ naršyklėje?

Žaidimas debesyje yra techniškai sudėtingas

Žaidimai yra viena iš tų retų sričių, kur reikalingas nuolatinis ir greitas vartotojo atsakas. Jei kartais spustelėdami puslapį susiduriame su 2 sekundžių delsa, tai priimtina. Tiesioginiai vaizdo įrašų srautai paprastai vėluoja kelias sekundes, bet vis tiek yra tinkami naudoti. Tačiau jei žaidimas dažnai vėluoja 500 ms, jo tiesiog negalima žaisti. Mūsų tikslas – pasiekti itin mažą delsą, kad tarpas tarp įvesties ir medijos būtų kuo mažesnis. Todėl tradicinis požiūris į vaizdo transliaciją čia netaikytinas.

Bendras debesies žaidimo šablonas

Atvirojo kodo projektas „CloudRetro“.

Nusprendžiau sukurti debesų žaidimo bandomąjį pavyzdį, kad pamatyčiau, ar visa tai įmanoma su tokiais griežtais tinklo apribojimais. Pasirinkau Golangą kaip koncepcijos įrodymą, nes tai buvo man labiausiai pažįstama kalba ir ji puikiai tiko šiam įgyvendinimui dėl daugelio kitų priežasčių, kaip vėliau atradau. Go yra paprastas ir labai greitai vystosi; „Go“ kanalai puikiai tinka kelių gijų tvarkymui.

Projektas CloudRetro.io yra atvirojo kodo debesies žaidimų paslauga, skirta retro žaidimams. Projekto tikslas – suteikti patogiausią žaidimų patirtį tradiciniams retro žaidimams ir įtraukti kelių žaidėjų režimą.
Daugiau apie projektą galite sužinoti čia: https://github.com/giongto35/cloud-game.

CloudRetro funkcionalumas

„CloudRetro“ naudoja retro žaidimus, kad parodytų debesų žaidimų galią. Tai leidžia jums įgyti daug unikalių žaidimų patirties.

• Žaidimo perkeliamumas
  • Momentinis atkūrimas atidarius puslapį; nereikia atsisiųsti ar įdiegti
  • Veikia mobiliojoje naršyklėje, todėl jai paleisti nereikia jokios programinės įrangos

• Žaidimų seansai gali būti bendrinami keliuose įrenginiuose ir saugomi debesyje, kad kitą kartą prisijungtumėte
• Žaidimas gali būti transliuojamas srautiniu būdu arba jį gali žaisti keli vartotojai vienu metu:
  • Crowdplay kaip „TwitchPlayPokemon“, tik daugiau skirtingų platformų ir daugiau realiojo laiko
  • Žaidimai neprisijungus internete. Daugelis vartotojų gali žaisti nenustatę tinklo. Samurai Shodown dabar gali žaisti 2 žaidėjai per CloudRetro tinklą

  
  Internetinio kelių žaidėjų žaidimo demonstracinė versija skirtinguose įrenginiuose

  Infrastruktūra

  Reikalavimai ir technologijų krūva

  Žemiau pateikiamas reikalavimų, kuriuos nustatau prieš pradėdamas projektą, sąrašas.

  1. Vienas žaidėjas
  Galbūt šis reikalavimas čia neatrodo per daug svarbus ar akivaizdus, ​​bet tai yra vienas iš mano pagrindinių dalykų, leidžiantis debesies žaidimams likti kuo toliau nuo tradicinių srautinio perdavimo paslaugų. Jei sutelksime dėmesį į vieno žaidėjo žaidimą, galime atsikratyti centralizuoto serverio arba CDN, nes mums nereikės srautinio perdavimo į mases. Užuot įkeliant srautus į kriauklės serverį arba perduodant paketus į centralizuotą „WebSocket“ serverį, paslaugų srautai pateikiami tiesiai vartotojui per „peer-to-peer WebRTC“ ryšį.

  2. Mažos delsos medijos srautas
  Skaitydamas apie „Stadia“, kai kuriuose straipsniuose dažnai matau paminėtą WebRTC. Supratau, kad „WebRTC“ yra puiki technologija ir puikiai tinka žaidimams debesyje. WebRTC yra projektas, teikiantis žiniatinklio naršyklėms ir mobiliosioms programoms ryšį realiuoju laiku per paprastą API. Jis suteikia lygiavertį ryšį, yra optimizuotas medijai ir turi įmontuotus standartinius kodekus, tokius kaip VP8 ir H264.

  Pirmenybę teikiau geriausios įmanomos vartotojo patirties užtikrinimui, o ne aukštos kokybės grafikos palaikymui. Kai kurie nuostoliai yra priimtini algoritme. „Google Stadia“ turi papildomą veiksmą, kad sumažintų vaizdo dydį serveryje, o kadrai padidinami iki aukštesnės kokybės prieš perduodant juos kolegoms.

  3. Paskirstyta infrastruktūra su geografiniu maršrutu
  Kad ir koks būtų optimizuotas glaudinimo algoritmas ir kodas, tinklas vis tiek yra lemiamas veiksnys, labiausiai prisidedantis prie delsos. Architektūra turi turėti mechanizmą, leidžiantį suporuoti arčiausiai vartotojo esantį serverį, kad sutrumpėtų kelionės į abi puses laikas (RTT). Architektūra turi turėti 1 koordinatorių ir kelis srautinio perdavimo serverius, paskirstytus visame pasaulyje: JAV vakaruose, JAV rytuose, Europoje, Singapūre, Kinijoje. Visi srautinio perdavimo serveriai turi būti visiškai izoliuoti. Sistema gali koreguoti savo paskirstymą, kai serveris prisijungia prie tinklo arba išeina iš jo. Taigi, esant dideliam srautui, papildomų serverių pridėjimas leidžia atlikti horizontalų mastelį.

  4. Naršyklės suderinamumas
  Žaidimai debesyje yra geriausi tada, kai iš vartotojų reikalaujama mažiausiai. Tai reiškia, kad galima paleisti naršyklėje. Naršyklės padeda vartotojams padaryti žaidimus kuo patogesne ir neleidžia jiems įdiegti programinės ir aparatinės įrangos. Naršyklės taip pat padeda teikti kelių platformų funkcijas tarp mobiliųjų ir stalinių kompiuterių versijų. Laimei, WebRTC yra gerai palaikomas įvairiose naršyklėse.

  5. Aiškus žaidimo sąsajos ir paslaugos atskyrimas
  Į debesies žaidimų paslaugą žiūriu kaip į platformą. Kiekvienas turėtų turėti galimybę bet ką prijungti prie platformos. Dabar aš integravau LibRetro su debesų žaidimų paslauga, nes „LibRetro“ siūlo gražią žaidimų emuliatoriaus sąsają retro žaidimams, tokiems kaip SNES, GBA, PS.

  6. Patalpos kelių žaidėjų žaidimui, minios žaidimui ir išoriniam susiejimui (giliajam ryšiui) su žaidimu
  „CloudRetro“ palaiko daugybę naujų žaidimų, tokių kaip „CrowdPlay“ ir „Online MultiPlayer“, skirta retro žaidimams. Jei keli vartotojai atidaro tą pačią giliąją nuorodą skirtinguose kompiuteriuose, jie matys tą patį veikiantį žaidimą ir netgi galės prie jo prisijungti.

  Be to, žaidimo būsenos saugomos debesies saugykloje. Tai leidžia vartotojams bet kada tęsti žaidimą bet kuriame kitame įrenginyje.

  7. Horizontalus mastelio keitimas
  Kaip ir bet kuris SAAS šiais laikais, debesų žaidimai turi būti suprojektuoti taip, kad juos būtų galima keisti horizontaliai. Koordinatoriaus ir darbuotojo dizainas leidžia pridėti daugiau darbuotojų, kad aptarnautumėte didesnį srautą.

  8. Nėra ryšio su vienu debesiu
  „CloudRetro“ infrastruktūra yra priglobta skirtinguose debesų paslaugų teikėjuose („Digital Ocean“, „Alibaba“, pasirinktinis teikėjas) skirtinguose regionuose. Įgalinu veikti infrastruktūros „Docker“ konteineryje ir konfigūruoju tinklo nustatymus naudodamas „bash“ scenarijų, kad nebūčiau užrakintas viename debesies teikėjo tinkle. Sujungę tai su NAT Traversal WebRTC, galime lanksčiai diegti CloudRetro bet kurioje debesies platformoje ir net bet kuriame vartotojo kompiuteryje.

  Architektūrinis dizainas

  Darbuotojas: (arba aukščiau paminėtas srautinio perdavimo serveris) padaugina žaidimų skaičių, paleidžia kodavimo vamzdyną ir perduoda užkoduotą mediją vartotojams. Darbuotojų egzemplioriai yra paskirstyti visame pasaulyje, ir kiekvienas darbuotojas vienu metu gali tvarkyti kelias vartotojo sesijas.

  Koordinatorius: yra atsakingas už naujo vartotojo susiejimą su tinkamiausiu darbuotojui srautiniam perdavimui. Koordinatorius bendrauja su darbuotojais per WebSocket.

  Žaidimo būsenos saugykla: centrinė nuotolinė saugykla visoms žaidimo būsenoms. Ši saugykla atlieka svarbias funkcijas, pvz., nuotolinį išsaugojimą / įkėlimą.

  
  Aukščiausio lygio „CloudRetro“ architektūra

  Pasirinktinis scenarijus

  Kai naujas vartotojas atidaro „CloudRetro“ atlikdamas 1 ir 2 veiksmus, parodytus toliau pateiktame paveikslėlyje, koordinatoriaus ir galimų darbuotojų sąrašo prašoma į pirmąjį puslapį. Po to 3 veiksme klientas apskaičiuoja visų kandidatų delsą naudodamas HTTP ping užklausą. Šis vėlavimų sąrašas siunčiamas atgal koordinatoriui, kad jis galėtų nustatyti tinkamiausią darbuotoją aptarnauti vartotoją. Žemiau atlikus 4 veiksmą sukuriamas žaidimas. Tarp vartotojo ir priskirto darbuotojo užmezgamas WebRTC srautinio perdavimo ryšys.
  
  Vartotojo scenarijus gavus prieigą

  Kas yra darbuotojo viduje

  Žaidimų ir srautinio perdavimo vamzdynai yra saugomi darbuotojo viduje ir keičiasi informacija per sąsają. Šiuo metu šis ryšys vykdomas perduodant duomenis atmintyje per Golango kanalai tame pačiame procese. Kitas tikslas – segregacija, t.y. nepriklausomas žaidimo paleidimas kitame procese.

  
  Darbuotojų komponentų sąveika

  Pagrindiniai komponentai:

  • „WebRTC“: kliento komponentas, kuris priima vartotojo įvestį ir iš serverio išveda užkoduotą laikmeną.
  • Žaidimo emuliatorius: žaidimo komponentas. Libretro bibliotekos dėka sistema gali paleisti žaidimą tame pačiame procese ir viduje perimti mediją bei įvesties srautą.
  • Žaidimo kadrai užfiksuojami ir siunčiami į kodavimo įrenginį.
  • Vaizdo / garso kodavimo įrenginys: kodavimo vamzdynas, kuris paima medijos kadrus, užkoduoja juos fone ir išveda užkoduotus vaizdus/garsą.

  Vykdymas

  „CloudRetro“ remiasi WebRTC kaip pagrindine technologija, todėl prieš pasinerdamas į „Golang“ diegimo detales, nusprendžiau pakalbėti apie patį WebRTC. Tai nuostabi technologija, kuri man labai padėjo pasiekti trumpesnį nei sekundės duomenų perdavimo delsą.

  WebRTC

  WebRTC sukurta siekiant teikti aukštos kokybės lygiaverčius ryšius vietinėse programose mobiliesiems ir naršyklėse naudojant paprastas API.

  NAT Traversal

  WebRTC yra žinomas dėl savo NAT Traversal funkcionalumo. „WebRTC“ sukurtas bendram ryšiui. Jo tikslas yra rasti tinkamiausią tiesioginį maršrutą, išvengiant NAT šliuzų ir ugniasienių tarpusavio ryšiui per procesą, vadinamą P. Vykdydami šį procesą, WebRTC API suranda jūsų viešąjį IP adresą naudodamos STUN serverius ir persiunčia jį į perdavimo serverį (SUKTI), kai negalima užmegzti tiesioginio ryšio.

  Tačiau „CloudRetro“ ne visiškai išnaudoja šios funkcijos. Jo lygiaverčiai ryšiai egzistuoja ne tarp vartotojų, o tarp vartotojų ir debesies serverių. Modelio serverio pusėje yra mažiau tiesioginio ryšio apribojimų nei įprastame vartotojo įrenginyje. Tai leidžia iš anksto atidaryti įeinančius prievadus arba tiesiogiai naudoti viešuosius IP adresus, nes serveris nėra už NAT.

  Anksčiau norėjau projektą paversti žaidimų platinimo platforma „Cloud Gaming“. Idėja buvo leisti žaidimų kūrėjams teikti žaidimus ir srautinio perdavimo išteklius. Ir vartotojai tiesiogiai bendrautų su paslaugų teikėjais. Šiuo decentralizuotu būdu „CloudRetro“ yra tik sistema, skirta trečiųjų šalių srautinio perdavimo ištekliams sujungti su vartotojais, todėl ji tampa labiau keičiama, kai ji nebepriglobiama. „WebRTC NAT Traversal“ vaidmuo čia yra labai svarbus siekiant palengvinti tarpusavio ryšio inicijavimą trečiosios šalies srautinio perdavimo ištekliais, todėl kūrėjui lengviau prisijungti prie tinklo.

  Vaizdo įrašo suspaudimas

  Vaizdo įrašų suspaudimas yra nepakeičiama dujotiekio dalis ir labai prisideda prie sklandaus srauto. Nors nebūtina žinoti kiekvienos VP8 / H264 vaizdo kodavimo detalės, supratę sąvokas galite suprasti srautinio vaizdo įrašo greičio parinktis, derinti netikėtą elgesį ir koreguoti delsą.

  Suspausti vaizdo įrašą srautinio perdavimo paslaugai yra sudėtinga, nes algoritmas turi užtikrinti, kad bendras kodavimo laikas + tinklo perdavimo laikas + dekodavimo laikas būtų kuo mažesnis. Be to, kodavimo procesas turi būti nuoseklus ir nenutrūkstamas. Kai kurie kodavimo kompromisai netaikomi, pavyzdžiui, negalime teikti pirmenybės ilgiems kodavimo laikams, o ne mažesniems failų dydžiams ir dekodavimo laikams, arba naudoti nenuoseklų glaudinimą.

  Vaizdo įrašų glaudinimo idėja yra pašalinti nereikalingas informacijos dalis, išlaikant vartotojams priimtiną tikslumo lygį. Be atskirų statinių vaizdo kadrų kodavimo, algoritmas daro išvadą apie esamą kadrą iš ankstesnio ir sekančio, todėl siunčiamas tik jų skirtumas. Kaip matyti iš Pacman pavyzdžio, perduodami tik diferencialiniai taškai.

  
  Vaizdo įrašų kadrų palyginimas naudojant Pacman kaip pavyzdį

  Garso suspaudimas

  Taip pat garso glaudinimo algoritmas praleidžia duomenis, kurių žmonės negali suvokti. „Opus“ šiuo metu yra geriausiai veikiantis garso kodekas. Jis skirtas perduoti garso bangas per užsakytą datagramos protokolą, pvz., RTP (Real Time Transport Protocol). Jo delsa yra mažesnė nei mp3 ir aac, o kokybė yra aukštesnė. Vėlavimas paprastai yra apie 5–66,5 ms.

  Pion, WebRTC Golange

  Pėstininkas yra atvirojo kodo projektas, atnešantis WebRTC į Golangą. Vietoj įprasto vietinių C++ WebRTC bibliotekų apipavidalinimo, „Pion“ yra vietinis „WebRTC“ diegimas „Golang“, pasižymintis geresniu našumu, „Go“ integracija ir versijos valdymu WebRTC protokoluose.

  Biblioteka taip pat įgalina srautinį perdavimą su daugybe puikių integruotų įtaisų su trumpesniu nei sekundės delsa. Jis turi savo STUN, DTLS, SCTP ir kt. ir kai kurie eksperimentai su QUIC ir WebAssembly. Pati ši atvirojo kodo biblioteka yra tikrai geras mokymosi šaltinis su puikia dokumentacija, tinklo protokolų įgyvendinimu ir šauniais pavyzdžiais.

  Pion bendruomenė, vadovaujama labai aistringo kūrėjo, yra gana gyva, vyksta daug kokybiškų diskusijų apie WebRTC. Jei jus domina ši technologija, prisijunkite http://pion.ly/slack – išmoksite daug naujų dalykų.

  „CloudRetro“ rašymas Golange

  
  Darbuotojo įgyvendinimas Go

  Eikite į veiksmą

  Dėl gražaus Go kanalo dizaino įvykių srautinio perdavimo ir lygiagretumo problemos yra labai supaprastintos. Kaip diagramoje, skirtingose ​​„GoRoutines“ yra keli komponentai, veikiantys lygiagrečiai. Kiekvienas komponentas valdo savo būseną ir bendrauja kanalais. Golango selektyvus tvirtinimas verčia kiekvieną kartą žaidime apdoroti vieną atominį įvykį (žaidimo varnelė). Tai reiškia, kad šiai konstrukcijai nereikia užrakinti. Pavyzdžiui, kai vartotojas išsaugo, reikalinga visa žaidimo būsenos momentinė nuotrauka. Ši būsena turėtų išlikti nenutrūkstama, prisijungiant, kol įrašymas bus baigtas. Kiekvieno žaidimo žymėjimo metu užpakalinė programa gali atlikti tik išsaugojimo arba įvesties operaciją, todėl proceso gija yra saugi.

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  Ventiliatorius / ventiliatorius

  Šis „Golang“ šablonas puikiai tinka mano „CrowdPlay“ ir „Multiple Player“ naudojimo atvejams. Remiantis šiuo modeliu, visi vartotojo įėjimai vienoje patalpoje yra įmontuoti į centrinį įėjimo kanalą. Tada žaidimų laikmena siunčiama visiems vartotojams toje pačioje patalpoje. Tokiu būdu pasiekiame žaidimo būsenos padalijimą tarp kelių skirtingų vartotojų žaidimų seansų.

  
  Sinchronizavimas tarp skirtingų seansų

  Golango trūkumai

  Golangas nėra tobulas. Kanalas lėtas. Palyginti su blokavimu, „Go“ kanalas yra paprasčiausiai paprastesnis būdas tvarkyti tuo pačiu metu vykstančius ir susietus įvykius, tačiau kanalas neužtikrina geriausio našumo. Po kanalu yra sudėtinga blokavimo logika. Taigi atlikau keletą diegimo pakeitimų, pakeitęs kanalus iš naujo pritaikau užraktus ir atomines vertes, kad optimizuočiau našumą.

  Be to, šiukšlių surinkėjas Golange yra netvarkomas, todėl kartais kyla įtartinai ilgos pauzės. Tai labai trukdo realaus laiko srautinio perdavimo programai.

  COG

  Projekte naudojama esama atvirojo kodo Golang VP8/H264 biblioteka medijos glaudinimui ir Libretro žaidimų emuliatoriams. Visos šios bibliotekos yra tiesiog „Go“ C bibliotekos paketai COG. Kai kurie trūkumai yra išvardyti šį Dave'o Cheney įrašą. Problemos, su kuriomis susidūriau:

  • nesugebėjimas pagauti CGO avarijos, net naudojant Golang RecoveryCrash;
  • nesugebėjimas nustatyti veiklos kliūčių, kai negalime aptikti išsamių CGO problemų.

  išvada

  Pasiekiau savo tikslą suprasti debesų žaidimų paslaugas ir sukurti platformą, kuri padėtų man žaisti nostalgiškus retro žaidimus su draugais internete. Šis projektas nebūtų įmanomas be Pion bibliotekos ir Pion bendruomenės paramos. Esu be galo dėkingas už intensyvų jos vystymąsi. Paprastos API, kurias teikia WebRTC ir Pion, užtikrino sklandžią integraciją. Mano pirmasis koncepcijos įrodymas buvo išleistas tą pačią savaitę, nors neturėjau išankstinių žinių apie tarpusavio ryšį (P2P).

  Nepaisant integracijos lengvumo, P2P srautinis perdavimas iš tiesų yra labai sudėtinga kompiuterių mokslo sritis. Ji turi susidoroti su sudėtingomis ilgalaikėmis tinklo architektūromis, tokiomis kaip IP ir NAT, kad sukurtų lygiaverčio seansą. Dirbdamas su šiuo projektu įgijau daug vertingų žinių apie tinklų kūrimą ir našumo optimizavimą, todėl raginu visus pabandyti kurti P2P produktus naudojant WebRTC.

  „CloudRetro“ atitinka visus naudojimo atvejus, kurių tikėjausi iš savo, kaip retro žaidėjo, perspektyvos. Tačiau manau, kad projekte yra daug sričių, kurias galiu patobulinti, pavyzdžiui, padaryti tinklą patikimesnį ir našesnį, teikti aukštesnės kokybės žaidimų grafiką ar galimybę dalytis žaidimais tarp vartotojų. Aš sunkiai dirbu. Prašome sekti projektą ir palaikykite, jei jums tai patinka.

Šaltinis: www.habr.com