Hapchwarae cwmwl ffynhonnell agored ar WebRTC: p2p, aml-chwaraewr, dim hwyrni

Meddalwedd fel Gwasanaeth, Isadeiledd fel Gwasanaeth, Llwyfan fel Gwasanaeth, Llwyfan Cyfathrebu fel Gwasanaeth, Fideo-gynadledda fel Gwasanaeth, a beth am Cloud Gaming fel Gwasanaeth? Bu sawl ymgais eisoes i greu hapchwarae cwmwl (Cloud Gaming), fel Stadia, a lansiwyd yn ddiweddar gan Google. Stadia ddim yn newydd i WebRTC, ond a all eraill ddefnyddio WebRTC yn yr un modd?

Penderfynodd Thanh Nguyen brofi'r posibilrwydd hwn ar ei brosiect ffynhonnell agored CloudRetro. Mae CloudRetro yn seiliedig ar Pion, poblogaidd Llyfrgell WebRTC yn seiliedig ar Go (diolch Shownu gan dîm datblygu Pion am eu cymorth gyda'r erthygl hon). Yn yr erthygl hon, mae Thanh yn rhoi trosolwg o bensaernïaeth ei brosiect, a hefyd yn siarad am yr hyn a ddysgodd yn ddefnyddiol a pha heriau a ddaeth ar eu traws wrth weithio.

Mynediad

Y llynedd, pan gyhoeddodd Google Stadia, cefais fy synnu. Mae'r syniad mor unigryw ac arloesol nes i mi feddwl yn gyson sut mae hyn hyd yn oed yn bosibl gyda thechnolegau presennol. Roedd yr awydd i ddeall y pwnc hwn yn well wedi fy ysgogi i greu fy fersiwn fy hun o gêm cwmwl ffynhonnell agored. Roedd y canlyniad yn wych. Isod hoffwn rannu'r broses o weithio ar fy mlwyddyn prosiect.

TLDR: fersiwn sleidiau byr gydag uchafbwyntiau

Pam mai hapchwarae cwmwl yw'r dyfodol

Credaf y bydd Cloud Gaming yn fuan yn dod yn genhedlaeth newydd o nid yn unig gemau, ond hefyd feysydd eraill o wyddoniaeth gyfrifiadurol. Hapchwarae cwmwl yw uchafbwynt y model cleient/gweinydd. Mae'r model hwn yn gwneud y mwyaf o reolaeth backend ac yn lleihau gwaith pen blaen trwy gynnal rhesymeg gêm ar weinydd o bell a ffrydio delweddau / sain i'r cleient. Mae'r gweinydd yn gwneud y prosesu trwm felly nid yw'r cleient bellach yn destun cyfyngiadau caledwedd.

Yn y bôn, mae Google Stadia yn gadael ichi chwarae Gemau AAA (h.y. gemau ysgubol pen uchel) ar ryngwyneb fel YouTube. Gellir cymhwyso'r un fethodoleg i gymwysiadau all-lein trwm eraill fel system weithredu neu ddylunio graffeg 2D/3D ac ati. fel y gallwn eu rhedeg yn sefydlog ar ddyfeisiadau manyleb isel ar draws llwyfannau.

Dyfodol y dechnoleg hon: dychmygwch a oedd Microsoft Windows 10 yn rhedeg yn y porwr Chrome?

Mae hapchwarae cwmwl yn dechnegol anodd

Mae hapchwarae yn un o'r meysydd prin hynny lle mae angen ymateb cyflym cyson gan y defnyddiwr. Os byddwn yn dod ar draws oedi o 2 eiliad yn achlysurol wrth glicio ar dudalen, mae hyn yn dderbyniol. Mae ffrydiau fideo byw yn tueddu i fod ychydig eiliadau ar ei hôl hi, ond yn dal i gynnig cryn dipyn o ddefnyddioldeb. Fodd bynnag, os yw'r gêm yn aml yn cael ei gohirio gan 500ms, yn syml, nid yw'n bosibl chwarae. Ein nod yw cyrraedd lefel hwyrni eithriadol o isel fel bod y bwlch rhwng mewnbwn a chyfryngau mor fach â phosibl. Felly, nid yw'r dull traddodiadol o ffrydio fideo yn berthnasol yma.

Templed gêm cwmwl cyffredinol

Prosiect ffynhonnell agored CloudRetro

Penderfynais greu sampl prawf o gêm cwmwl i weld a yw hyn i gyd yn bosibl gyda chyfyngiadau rhwydwaith mor ddifrifol. Dewisais Golang ar gyfer prawf cysyniad oherwydd dyma'r iaith rwy'n fwyaf cyfarwydd â hi ac mae'n ffit dda ar gyfer y gweithrediad hwn am lawer o resymau eraill, fel y darganfyddais yn ddiweddarach. Mae Go yn syml ac yn datblygu'n gyflym iawn; Mae sianeli yn Go yn wych ar gyfer rheoli aml-edau.

Prosiect CloudRetro.io yn wasanaeth hapchwarae cwmwl ffynhonnell agored ar gyfer hapchwarae retro. Nod y prosiect yw dod â'r profiad hapchwarae mwyaf cyfforddus i gemau retro traddodiadol ac ychwanegu aml-chwaraewr.
Gallwch ddarganfod mwy am y prosiect yma: https://github.com/giongto35/cloud-game.

Ymarferoldeb CloudRetro

Mae CloudRetro yn defnyddio gemau retro i arddangos pŵer hapchwarae cwmwl. Mae hynny'n caniatáu ichi gael llawer o brofiadau hapchwarae unigryw.

• Hygludedd Gêm
  • Chwarae ar unwaith wrth agor tudalen; dim angen llwytho i lawr a gosod
  • Yn rhedeg ar borwr symudol felly nid oes angen meddalwedd i redeg

• Gellir rhannu sesiynau gêm ar draws dyfeisiau lluosog a'u storio yn y cwmwl ar gyfer mewngofnodi nesaf
• Gellir ffrydio'r gêm, neu gallwch ei chwarae gyda sawl defnyddiwr ar unwaith:
  • Crowdplay fel TwitchPlayPokemon, dim ond mwy traws-lwyfan a mwy amser real
  • Gemau all-lein ar-lein. Gall llawer o ddefnyddwyr chwarae heb sefydlu rhwydwaith. Bellach gellir chwarae Samurai Shodown gyda 2 chwaraewr dros rwydwaith CloudRetro

  
  Fersiwn demo o gêm aml-chwaraewr ar-lein ar wahanol ddyfeisiau

  Isadeiledd

  Gofynion a stac technoleg

  Isod mae rhestr o ofynion a osodais cyn cychwyn ar y prosiect.

  1. Un chwaraewr
  Efallai nad yw'r gofyniad hwn yn ymddangos yn rhy bwysig ac amlwg yma, ond mae'n un o fy siopau cludfwyd allweddol, mae'n cadw hapchwarae cwmwl mor bell i ffwrdd o wasanaethau ffrydio traddodiadol â phosibl. Os byddwn yn canolbwyntio ar y gêm chwaraewr sengl, gallwn gael gwared ar y gweinydd canolog neu CDN oherwydd nid oes rhaid i ni ffrydio i'r llu. Yn lle uwchlwytho ffrydiau i weinydd amlyncu neu basio pecynnau i weinydd WebSocket canolog, mae ffrydiau gwasanaeth yn cael eu ffrydio'n uniongyrchol i'r defnyddiwr trwy gysylltiad cyfoedion WebRTC.

  2. ffrwd cyfryngau latency isel
  Wrth ddarllen am Stadia, rwy'n aml yn gweld WebRTC yn cael ei grybwyll mewn rhai erthyglau. Sylweddolais fod WebRTC yn dechnoleg ragorol, ac mae'n wych i'w ddefnyddio mewn hapchwarae cwmwl. Mae WebRTC yn brosiect sy'n darparu cyfathrebu amser real i borwyr gwe a chymwysiadau symudol trwy API syml. Mae'n darparu cysylltedd rhwng cymheiriaid, mae wedi'i optimeiddio ar gyfer cyfryngau, ac mae ganddo godecs safonol adeiledig fel VP8 a H264.

  Rhoddais flaenoriaeth i ddarparu'r profiad defnyddiwr gorau posibl dros gynnal graffeg o ansawdd uchel. Caniateir rhai colledion yn yr algorithm. Mae gan Google Stadia gam ychwanegol i leihau maint y ddelwedd ar y gweinydd ac mae'r fframiau'n cael eu huwchraddio i ansawdd uwch cyn eu trosglwyddo i'r cyfoedion.

  3. Seilwaith gwasgaredig gyda llwybrau daearyddol
  Waeth pa mor optimaidd yw'r algorithm cywasgu a'r cod, y rhwydwaith yw'r ffactor penderfynu o hyd sy'n cyfrannu fwyaf at hwyrni. Dylai fod gan y bensaernïaeth fecanwaith ar gyfer paru'r gweinydd sydd agosaf at y defnyddiwr i leihau amser taith gron (RTT). Dylai fod gan y bensaernïaeth 1 cydlynydd a nifer o weinyddion ffrydio wedi'u dosbarthu ledled y byd: Gorllewin yr UD, Dwyrain yr UD, Ewrop, Singapore, Tsieina. Rhaid i bob gweinydd ffrydio fod yn gwbl ynysig. Gall y system addasu ei dosbarthiad pan fydd y gweinydd yn ymuno â'r rhwydwaith neu'n gadael. Felly, gyda thraffig uchel, mae ychwanegu gweinyddwyr ychwanegol yn caniatáu graddio llorweddol.

  4. Cysondeb porwr
  Mae hapchwarae cwmwl ar ei orau pan fydd angen y lleiafswm lleiaf gan ddefnyddwyr. Mae hyn yn golygu ei bod hi'n bosibl rhedeg yn y porwr. Mae porwyr yn helpu i wneud y profiad hapchwarae mor gyfforddus â phosibl i ddefnyddwyr trwy eu harbed rhag gosod meddalwedd a chaledwedd. Mae porwyr hefyd yn helpu i ddarparu traws-lwyfan ar gyfer fersiynau symudol a bwrdd gwaith. Yn ffodus, mae WebRTC yn cael ei gefnogi'n dda mewn amrywiol borwyr.

  5. Gwahaniad clir o'r rhyngwyneb gêm a gwasanaeth
  Rwy'n gweld gwasanaeth hapchwarae cwmwl fel platfform. Dylai pawb allu cysylltu unrhyw beth â'r platfform. Rwyf bellach wedi integreiddio LibRetro gyda gwasanaeth gêm cwmwl oherwydd bod LibRetro yn cynnig rhyngwyneb efelychydd gêm hardd ar gyfer gemau retro fel SNES, GBA, PS.

  6. Ystafelloedd ar gyfer aml-chwaraewr, chwarae torfol a chysylltu allanol (cyswllt dwfn) â'r gêm
  Mae CloudRetro yn cefnogi llawer o gemau newydd fel CrowdPlay ac Online MultiPlayer ar gyfer gemau retro. Os bydd sawl defnyddiwr yn agor yr un cyswllt dwfn ar wahanol gyfrifiaduron, byddant yn gweld yr un gêm yn rhedeg a hyd yn oed yn gallu ymuno â hi.

  Ar ben hynny, mae gwladwriaethau gêm yn cael eu storio yn y storfa cwmwl. Mae hyn yn galluogi defnyddwyr i barhau â'r gêm ar unrhyw adeg ar unrhyw ddyfais arall.

  7. Graddio llorweddol
  Fel unrhyw SAAS y dyddiau hyn, rhaid dylunio hapchwarae cwmwl i fod yn llorweddol scalable. Mae'r cynllun cydlynydd-gweithiwr yn caniatáu ichi ychwanegu mwy o weithwyr i wasanaethu mwy o draffig.

  8. Heb ei glymu i un cwmwl
  Mae seilwaith CloudRetro yn cael ei gynnal gan wahanol ddarparwyr cwmwl (Cefnfor Digidol, Alibaba, darparwr arfer) ar gyfer gwahanol ranbarthau. Rwy'n galluogi rhedeg mewn cynhwysydd Docker seilwaith ac yn ffurfweddu gosodiadau rhwydwaith gyda sgript bash er mwyn osgoi bod yn ddibynnol ar ddarparwr cwmwl sengl. Gan gyfuno hyn â NAT Traversal yn WebRTC, gallwn gael yr hyblygrwydd i ddefnyddio CloudRetro ar unrhyw lwyfan cwmwl a hyd yn oed peiriant unrhyw ddefnyddiwr.

  Dyluniad pensaernïol

  Gweithiwr: (neu'r gweinydd ffrydio a grybwyllir uchod) yn lluosi'r gemau, yn rhedeg y biblinell amgodio, ac yn ffrydio'r cyfryngau wedi'u hamgodio i'r defnyddwyr. Mae achosion gweithwyr yn cael eu dosbarthu ledled y byd, a gall pob gweithiwr drin sesiynau defnyddwyr lluosog ar yr un pryd.

  Cydlynydd: yn gyfrifol am baru'r defnyddiwr newydd gyda'r gweithiwr ffrydio mwyaf addas. Mae'r cydlynydd yn cyfathrebu â'r gweithwyr trwy WebSocket.

  Storio cyflwr gêm: storfa ganolog o bell ar gyfer pob cyflwr gêm. Mae'r storfa hon yn darparu nodweddion pwysig fel arbed / llwyth o bell.

  
  Pensaernïaeth lefel uchaf CloudRetro

  Sgript Custom

  Pan fydd defnyddiwr newydd yn agor CloudRetro yng nghamau 1 a 2 a ddangosir yn y ffigur isod, gofynnir am y cydlynydd, ynghyd â rhestr o weithwyr sydd ar gael, i'r dudalen gyntaf. Ar ôl hynny, yng ngham 3, mae'r cleient yn cyfrifo oedi ar gyfer pob ymgeisydd gan ddefnyddio cais ping HTTP. Yna caiff y rhestr hon o oedi ei hanfon yn ôl at y cydlynydd er mwyn iddo allu pennu'r gweithiwr mwyaf priodol i wasanaethu'r defnyddiwr. Mae Cam 4 isod yn creu gêm. Sefydlir cysylltiad ffrydio WebRTC rhwng y defnyddiwr a'r gweithiwr penodedig.
  
  Sgript bersonol ar ôl cael mynediad

  Beth sydd y tu mewn i'r gweithiwr

  Mae piblinellau gêm a ffrydio yn cael eu storio y tu mewn i'r gweithiwr ar wahân ac yn cyfnewid gwybodaeth yno trwy'r rhyngwyneb. Ar hyn o bryd, mae'r cyfathrebu hwn yn cael ei wneud trwy drosglwyddo data yn y cof drosodd sianeli golang yn yr un broses. Y nod nesaf yw arwahanu, h.y. lansiad annibynnol y gêm mewn proses arall.

  
  Rhyngweithio cydrannau gweithwyr

  Prif gydrannau:

  • WebRTC: elfen cleient sy'n derbyn mewnbwn defnyddwyr ac yn allbynnu'r cyfryngau wedi'u hamgodio o'r gweinydd.
  • Efelychydd gêm: elfen gêm. Diolch i lyfrgell Libretro, mae'r system yn gallu rhedeg y gêm y tu mewn i'r un broses a rhyng-gipio'r cyfryngau a'r ffrwd mewnbwn yn fewnol.
  • Mae fframiau yn y gêm yn cael eu dal a'u hanfon at yr amgodiwr.
  • Amgodiwr delwedd/sain: piblinell amgodio sy'n derbyn fframiau cyfryngau, yn eu hamgodio yn y cefndir, ac yn allbynnu delweddau/sain wedi'u hamgodio.

  Gweithredu

  Mae CloudRetro yn dibynnu ar WebRTC fel technoleg asgwrn cefn, felly cyn plymio i fanylion gweithrediad Golang, penderfynais siarad am WebRTC ei hun. Mae'n ddarn anhygoel o dechnoleg sydd wedi fy helpu'n aruthrol i gyflawni ffrydio hwyrni is-eiliad.

  WebRTC

  Mae WebRTC wedi'i gynllunio i ddarparu cysylltiadau cymar-i-gymar o ansawdd uchel ar ap symudol brodorol a phorwyr gan ddefnyddio APIs syml.

  NAT Traversal

  Mae WebRTC yn adnabyddus am ei ymarferoldeb NAT Traversal. Mae WebRTC wedi'i gynllunio ar gyfer cyfathrebu rhwng cymheiriaid. Ei ddiben yw dod o hyd i'r llwybr uniongyrchol mwyaf priodol, gan osgoi pyrth NAT a waliau tân, i gymar-i-gymar trwy broses o'r enw ICE. Fel rhan o'r broses hon, mae APIs WebRTC yn dod o hyd i'ch cyfeiriad IP cyhoeddus gan ddefnyddio gweinyddwyr STUN a'i anfon ymlaen at weinydd cyfnewid (TWRN) pan na ellir sefydlu cysylltiad uniongyrchol.

  Fodd bynnag, nid yw CloudRetro yn manteisio'n llawn ar y gallu hwn. Nid yw ei gysylltiadau cymar-i-gymar yn bodoli rhwng defnyddwyr, ond rhwng defnyddwyr a gweinyddwyr cwmwl. Mae gan ochr gweinydd y model lai o gyfyngiadau ar gyfathrebu uniongyrchol na dyfais defnyddiwr arferol. Mae hyn yn caniatáu ichi agor porthladdoedd sy'n dod i mewn ymlaen llaw neu ddefnyddio cyfeiriadau IP cyhoeddus yn uniongyrchol, gan nad yw'r gweinydd y tu ôl i NAT.

  Yn flaenorol, roeddwn i eisiau troi'r prosiect yn blatfform dosbarthu gêm ar gyfer Cloud Gaming. Y syniad oedd caniatáu i grewyr gemau ddarparu gemau ac adnoddau ffrydio. A byddai defnyddwyr yn rhyngweithio'n uniongyrchol â darparwyr. Yn y modd datganoledig hwn, mae CloudRetro yn gyfrwng yn unig ar gyfer cysylltu adnoddau ffrydio trydydd parti â defnyddwyr, sy'n ei gwneud yn fwy graddadwy pan nad yw cynnal yn dibynnu arno mwyach. Mae rôl WebRTC NAT Traversal yn bwysig iawn yma i hwyluso cychwyn cysylltiad cymar-i-gymar ar adnoddau ffrydio trydydd parti, sy'n ei gwneud hi'n haws i'r crëwr gysylltu â'r rhwydwaith.

  Cywasgu fideo

  Mae cywasgu fideo yn rhan anhepgor o'r biblinell ac mae'n cyfrannu'n fawr at esmwythder y nant. Er nad oes angen gwybod holl fanylion amgodio fideo VP8/H264, mae deall y cysyniad yn helpu i ddeall paramedrau cyflymder ffrydio fideo, dadfygio ymddygiad annisgwyl, ac addasu hwyrni.

  Mae cywasgu fideo ar gyfer gwasanaeth ffrydio yn heriol oherwydd mae'n rhaid i'r algorithm sicrhau bod cyfanswm yr amser amgodio + amser trosglwyddo rhwydwaith + amser datgodio mor fach â phosib. Yn ogystal, rhaid i'r broses amgodio fod yn gyson ac yn barhaus. Nid yw rhai cyfaddawdau mewn amgodio yn berthnasol - er enghraifft, ni allwn ffafrio amser amgodio hir dros faint ffeil llai ac amser datgodio, na defnyddio cywasgu anghyson.

  Y syniad y tu ôl i gywasgu fideo yw dileu darnau diangen o wybodaeth tra'n cynnal lefel dderbyniol o ffyddlondeb i ddefnyddwyr. Yn ogystal ag amgodio fframiau delwedd statig unigol, mae'r algorithm yn casglu'r ffrâm gyfredol o'r blaenorol a'r nesaf, felly dim ond eu gwahaniaeth sy'n cael ei anfon. Fel y gwelwch o enghraifft Pacman, dim ond pwyntiau gwahaniaethol sy'n cael eu trosglwyddo.

  
  Cymharu fframiau fideo gan ddefnyddio Pacman fel enghraifft

  Cywasgu sain

  Yn yr un modd, mae'r algorithm cywasgu sain yn hepgor data na all bodau dynol ei ganfod. Ar hyn o bryd Opus yw'r codec sain sy'n perfformio orau. Fe'i cynlluniwyd i drawsyrru ton sain dros brotocol datagram trefnedig fel RTP (Protocol Cludiant Amser Real). Mae ei oedi yn llai nag oedi mp3 ac aac, ac mae'r ansawdd yn uwch. Mae'r hwyrni fel arfer tua 5 ~ 66,5ms.

  Pion, WebRTC yn Golang

  Gwystlo yn brosiect ffynhonnell agored sy'n dod â WebRTC i Golang. Yn lle lapio arferol llyfrgelloedd brodorol C ++ WebRTC, mae Pion yn weithrediad brodorol Golang WebRTC gyda gwell perfformiad, integreiddio Go, a rheolaeth fersiwn ar brotocolau WebRTC.

  Mae'r llyfrgell hefyd yn darparu data ffrydio gyda llawer o fodiwlau adeiledig gwych gydag oedi o lai nag eiliad. Mae ganddo ei weithrediad ei hun o STUN, DTLS, SCTP, ac ati. a pheth arbrofi gyda QUIC a WebAssembly. Ar ei phen ei hun, mae'r llyfrgell ffynhonnell agored hon yn ffynhonnell ddysgu dda iawn gyda dogfennaeth wych, gweithredu protocol rhwydwaith, ac enghreifftiau cŵl.

  Mae'r gymuned Pion, dan arweiniad crëwr angerddol iawn, yn eithaf bywiog ac mae ganddo lawer o drafodaeth o ansawdd am WebRTC. Os oes gennych ddiddordeb yn y dechnoleg hon, ymunwch http://pion.ly/slack - byddwch chi'n dysgu llawer o bethau newydd.

  Ysgrifennu CloudRetro yn Golang

  
  Gweithredu Gweithiwr yn Go

  Ewch sianeli ar waith

  Gyda dyluniad hyfryd sianeli Go, mae materion ffrydio digwyddiadau a chyfnewid yn cael eu symleiddio'n fawr. Fel yn y diagram, mae sawl cydran yn rhedeg ochr yn ochr â gwahanol GoRoutines. Mae pob cydran yn rheoli ei chyflwr ei hun ac yn cyfathrebu trwy sianeli. Mae honiad dethol Golang yn achosi i un digwyddiad atomig gael ei brosesu bob tro yn y gêm (tic gêm). Mae hyn yn golygu nad oes angen blocio ar gyfer y dyluniad hwn. Er enghraifft, pan fydd defnyddiwr yn cael ei gadw, mae angen ciplun cyflwr gêm lawn. Rhaid i'r cyflwr hwn aros yn barhaus, gan fewngofnodi nes bod y arbediad wedi'i gwblhau. Yn ystod pob tic gêm, dim ond gweithrediad arbed neu gychwyn y gall y backend ei brosesu, sy'n gwneud y broses yn edefyn yn ddiogel.

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

  ffan-mewn / ffan-allan

  Mae'r templed Golang hwn yn wych ar gyfer fy achos defnydd CrowdPlay a Multiple Player. Yn dilyn y patrwm hwn, mae holl fewnbynnau defnyddwyr yn yr un ystafell yn cael eu cynnwys yn sianel fewnbwn y ganolfan. Yna mae'r cyfryngau gêm yn cael ei ddefnyddio i bob defnyddiwr yn yr un ystafell. Yn y modd hwn, rydym yn cyflawni rhaniad y cyflwr gêm rhwng sawl sesiwn gêm o wahanol ddefnyddwyr.

  
  Cydamseru rhwng gwahanol sesiynau

  Anfanteision Golang

  Nid yw Golang yn berffaith. Mae'r sianel yn araf. O'i gymharu â blocio, yn syml, mae sianel Go yn ffordd haws o drin digwyddiadau cydamserol a ffrydio, ond nid yw sianel yn darparu'r perfformiad gorau. O dan y sianel mae rhesymeg blocio cymhleth. Felly, gwnes rai addasiadau i'r gweithredu trwy ail-gymhwyso cloeon a gwerthoedd atomig wrth ailosod sianeli i wneud y gorau o berfformiad.

  Yn ogystal, mae casglwr sbwriel Golang yn anhydrin, sydd weithiau'n achosi seibiau hir amheus. Mae hyn yn ymyrryd yn fawr â'r cymhwysiad ffrydio amser real.

  COG

  Mae'r prosiect yn defnyddio'r llyfrgell Golang ffynhonnell agored VP8/H264 presennol ar gyfer cywasgu cyfryngau a Libretro ar gyfer efelychwyr gêm. Mae pob un o'r llyfrgelloedd hyn yn ddeunydd lapio yn unig ar gyfer y llyfrgell C yn Go gan ddefnyddio COG. Rhestrir rhai o'r anfanteision yn y post yma Dave Cheney. Problemau a wynebais:

  • anallu i ddal damwain yn CGO, hyd yn oed gyda Golang RecoveryCrash;
  • yr anallu i nodi tagfa perfformiad pan na allwn ganfod problemau gronynnog yn CGO.

  Casgliad

  Rwyf wedi cyflawni fy nod o ddarganfod gwasanaethau hapchwarae cwmwl a chreu platfform sy'n fy helpu i chwarae gemau retro hiraethus gyda fy ffrindiau ar-lein. Ni fyddai’r prosiect hwn wedi bod yn bosibl heb lyfrgell Pion a chefnogaeth cymuned Pion. Rwy’n hynod ddiolchgar am ei ddatblygiad dwys. Sicrhaodd yr APIs syml a ddarparwyd gan WebRTC a Pion integreiddiad di-dor. Rhyddhawyd fy mhrawf cysyniad cyntaf yr un wythnos, er nad oeddwn yn ymwybodol o gyfathrebu rhwng cymheiriaid (P2P) ymlaen llaw.

  Er gwaethaf rhwyddineb integreiddio, mae ffrydio P2P yn wir yn faes cymhleth iawn mewn cyfrifiadureg. Mae'n rhaid iddo ddelio â chymhlethdod pensaernïaeth rhwydwaith aml-flwyddyn fel IP a NAT i greu sesiwn cyfoedion-i-gymar. Wrth weithio ar y prosiect hwn, rwyf wedi cronni llawer o wybodaeth werthfawr am rwydweithio ac optimeiddio perfformiad, felly rwy'n argymell bod pawb yn ceisio adeiladu cynhyrchion P2P gan ddefnyddio WebRTC.

  Mae CloudRetro yn darparu ar gyfer yr holl achosion defnydd yr oeddwn yn eu disgwyl o fy safbwynt fel gamer retro. Fodd bynnag, credaf fod llawer o feysydd yn y prosiect y gallaf eu gwella, megis gwneud y rhwydwaith yn fwy dibynadwy a pherfformiwr, darparu graffeg gêm o ansawdd uwch, neu'r gallu i rannu gemau rhwng defnyddwyr. Rwy'n gweithio'n galed ar hyn. Dilynwch os gwelwch yn dda prosiect a chefnogwch ef os ydych yn ei hoffi.

Ffynhonnell: hab.com