ការលេងហ្គេមពពកប្រភពបើកចំហនៅលើ WebRTC៖ p2p, អ្នកលេងច្រើន, ភាពយឺតយ៉ាវសូន្យ

កម្មវិធីជាសេវាកម្ម ហេដ្ឋារចនាសម្ព័ន្ធជាសេវាកម្ម វេទិកាជាសេវាកម្ម វេទិកាទំនាក់ទំនងជាសេវាកម្ម សន្និសីទវីដេអូជាសេវាកម្ម ចុះយ៉ាងណាចំពោះហ្គេមលើពពកជាសេវាកម្មមួយ? មាន​ការ​ព្យាយាម​ជា​ច្រើន​ដង​រួច​មក​ហើយ​ក្នុង​ការ​បង្កើត​ការ​លេង​ហ្គេម​លើ​ពពក (Cloud Gaming) ដូច​ជា Stadia ដែល​ទើប​តែ​បាន​ដាក់​ឱ្យ​ប្រើ​ដោយ Google ។ ស្តាឌីយ៉ា មិនថ្មីចំពោះ WebRTC ទេ។ប៉ុន្តែតើអ្នកផ្សេងទៀតអាចប្រើ WebRTC តាមរបៀបដូចគ្នាដែរឬទេ?

Thanh Nguyen បានសម្រេចចិត្តសាកល្បងឱកាសនេះលើគម្រោងប្រភពបើកចំហរបស់គាត់ CloudRetro ។ CloudRetro គឺផ្អែកលើ Pion, ពេញនិយម បណ្ណាល័យ WebRTC ផ្អែកលើ Go (សូមអរគុណ បានបង្ហាញ ពីក្រុមអភិវឌ្ឍន៍ Pion សម្រាប់ជំនួយរបស់ពួកគេក្នុងការរៀបចំអត្ថបទនេះ) ។ នៅក្នុងអត្ថបទនេះ លោក Thanh ផ្តល់នូវទិដ្ឋភាពទូទៅនៃស្ថាបត្យកម្មនៃគម្រោងរបស់គាត់ ហើយក៏និយាយអំពីអ្វីដែលមានប្រយោជន៍ដែលគាត់បានរៀន និងបញ្ហាប្រឈមអ្វីខ្លះដែលគាត់បានជួបប្រទះក្នុងអំឡុងពេលការងាររបស់គាត់។

ធាតុ

កាលពីឆ្នាំមុន នៅពេលដែល Google បានប្រកាសអំពី Stadia វាបានធ្វើឱ្យខ្ញុំមានអារម្មណ៍រំភើប។ គំនិតនេះគឺប្លែក និងច្នៃប្រឌិតខ្លាំង ដែលខ្ញុំតែងតែងឿងឆ្ងល់ថា តើវាអាចទៅរួចដោយរបៀបណាជាមួយបច្ចេកវិទ្យាដែលមានស្រាប់។ បំណងប្រាថ្នាដើម្បីយល់កាន់តែច្បាស់អំពីប្រធានបទនេះបានជំរុញឱ្យខ្ញុំបង្កើតកំណែផ្ទាល់ខ្លួនរបស់ខ្ញុំនៃហ្គេមពពកប្រភពបើកចំហ។ លទ្ធផលគឺអស្ចារ្យណាស់។ ខាង​ក្រោម​នេះ​ខ្ញុំ​ចង់​ចែក​រំលែក​ដំណើរ​ការ​នៃ​ការ​ធ្វើ​ការ​ក្នុង​ឆ្នាំ​របស់​ខ្ញុំ គម្រោង.

TLDR៖ កំណែស្លាយខ្លីជាមួយនឹងគំនួសពណ៌

ហេតុអ្វីបានជាការលេងហ្គេមលើពពកគឺជាអនាគត

ខ្ញុំជឿថា Cloud Gaming នឹងក្លាយទៅជាជំនាន់ក្រោយនៃការលេងហ្គេមមិនត្រឹមតែប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានផ្នែកផ្សេងទៀតនៃវិទ្យាសាស្ត្រកុំព្យូទ័រផងដែរ។ ការលេងហ្គេមលើពពកគឺជាចំណុចកំពូលនៃគំរូម៉ាស៊ីនភ្ញៀវ/ម៉ាស៊ីនមេ។ គំរូនេះបង្កើនការគ្រប់គ្រងផ្នែកខាងក្រោយ និងកាត់បន្ថយការងារផ្នែកខាងមុខដោយបង្ហោះតក្កវិជ្ជាហ្គេមនៅលើម៉ាស៊ីនមេពីចម្ងាយ និងការផ្សាយរូបភាព/សំឡេងទៅកាន់អតិថិជន។ ម៉ាស៊ីនមេដំណើរការយ៉ាងធ្ងន់ធ្ងរ ដូច្នេះម៉ាស៊ីនភ្ញៀវលែងមានក្តីមេត្តាចំពោះការកំណត់ផ្នែករឹងទៀតហើយ។

Google Stadia ពិតជាអនុញ្ញាតឱ្យអ្នកលេង ហ្គេម AAA (ឧ. ហ្គេមកំពូលៗ) នៅលើចំណុចប្រទាក់ដូចជា YouTube ។ វិធីសាស្រ្តដូចគ្នាអាចត្រូវបានអនុវត្តចំពោះកម្មវិធីក្រៅបណ្តាញធ្ងន់ៗផ្សេងទៀត ដូចជាប្រព័ន្ធប្រតិបត្តិការ ឬការរចនាក្រាហ្វិក 2D/3D ជាដើម។ ដូច្នេះយើងអាចដំណើរការពួកវាបានជាប់លាប់នៅលើឧបករណ៍ដែលមានលក្ខណៈពិសេសទាបនៅលើវេទិកាជាច្រើន។

អនាគតនៃបច្ចេកវិទ្យានេះ៖ ស្រមៃមើលថាតើ Microsoft Windows 10 ដំណើរការលើកម្មវិធីរុករកតាមអ៊ីនធឺណិត Chrome ដែរឬទេ?

ការលេងហ្គេមលើពពកមានការប្រកួតប្រជែងផ្នែកបច្ចេកទេស

ការលេងហ្គេមគឺជាផ្នែកដ៏កម្រមួយ ដែលតម្រូវឱ្យអ្នកប្រើប្រាស់ឆ្លើយតបរហ័ស និងថេរ។ ប្រសិនបើម្តងម្កាលយើងជួបប្រទះការពន្យាពេល 2 វិនាទីនៅពេលចុចលើទំព័រ នេះអាចទទួលយកបាន។ ការ​ផ្សាយ​បន្ត​ផ្ទាល់​វីដេអូ​មាន​ទំនោរ​យឺត​ពេល​ប៉ុន្មាន​វិនាទី ប៉ុន្តែ​នៅ​តែ​ផ្តល់​ឱ្យ​នូវ​លទ្ធភាព​ប្រើ​ប្រាស់​សម​ហេតុ​ផល។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើហ្គេមនេះយឺតជាង 500ms នោះវាមិនអាចលេងបានទេ។ គោលដៅរបស់យើងគឺដើម្បីសម្រេចបាននូវភាពយឺតយ៉ាវទាបបំផុត ដើម្បីឱ្យគម្លាតរវាងការបញ្ចូល និងប្រព័ន្ធផ្សព្វផ្សាយមានទំហំតូចតាមដែលអាចធ្វើទៅបាន។ ដូច្នេះ វិធីសាស្រ្តបែបប្រពៃណីចំពោះការផ្សាយវីដេអូមិនត្រូវបានអនុវត្តនៅទីនេះទេ។

គំរូហ្គេមពពកទូទៅ

គម្រោងប្រភពបើកចំហ CloudRetro

ខ្ញុំបានសម្រេចចិត្តបង្កើតគំរូសាកល្បងនៃហ្គេមលើពពក ដើម្បីមើលថាតើអ្វីៗទាំងអស់នេះអាចទៅរួចដែរឬទេ ជាមួយនឹងការរឹតបន្តឹងបណ្តាញដ៏តឹងរ៉ឹងបែបនេះ។ ខ្ញុំបានជ្រើសរើស Golang សម្រាប់ភ័ស្តុតាងនៃគោលគំនិត ព្រោះវាជាភាសាដែលខ្ញុំធ្លាប់ស្គាល់ជាងគេ ហើយស័ក្តិសមសម្រាប់ការអនុវត្តនេះ ដោយសារហេតុផលជាច្រើនទៀត ដូចដែលខ្ញុំបានរកឃើញនៅពេលក្រោយ។ ទៅគឺសាមញ្ញហើយអភិវឌ្ឍយ៉ាងលឿន; Channels in Go គឺល្អសម្រាប់ការគ្រប់គ្រង multithreading។

គម្រោង CloudRetro.io គឺជាសេវាកម្មហ្គេមពពកប្រភពបើកចំហសម្រាប់ការលេងហ្គេមបែបអតីតកាល។ គោលដៅនៃគម្រោងនេះគឺដើម្បីនាំយកបទពិសោធន៍លេងហ្គេមដែលមានផាសុកភាពបំផុតទៅកាន់ហ្គេមបែបបុរាណ និងបន្ថែមអ្នកលេងច្រើន។
អ្នកអាចស្វែងយល់បន្ថែមអំពីគម្រោងនៅទីនេះ៖ https://github.com/giongto35/cloud-game.

មុខងារ CloudRetro

CloudRetro ប្រើប្រាស់ហ្គេមបែបអតីតកាល ដើម្បីបង្ហាញពីថាមពលនៃការលេងហ្គេមលើពពក។ ដែលអនុញ្ញាតឱ្យអ្នកទទួលបានបទពិសោធន៍លេងហ្គេមប្លែកៗជាច្រើន។

• ភាពចល័តនៃហ្គេម
  • ការចាក់សារថ្មីភ្លាមៗនៅពេលបើកទំព័រ; មិនចាំបាច់ទាញយក ឬដំឡើងទេ។
  • ដំណើរការនៅក្នុងកម្មវិធីរុករកតាមទូរស័ព្ទ ដូច្នេះមិនចាំបាច់ប្រើកម្មវិធីដើម្បីដំណើរការវាទេ។

• វគ្គហ្គេមអាចត្រូវបានចែករំលែកនៅលើឧបករណ៍ជាច្រើន ហើយរក្សាទុកក្នុងពពកសម្រាប់ពេលក្រោយដែលអ្នកចូល
• ហ្គេមនេះអាចត្រូវបានចាក់ ឬវាអាចលេងដោយអ្នកប្រើប្រាស់ជាច្រើនក្នុងពេលតែមួយ៖
  • Crowdplay ដូចជា TwitchPlayPokemon មានតែវេទិកាឆ្លងគ្នា និងពេលវេលាពិតច្រើនទៀត
  • ហ្គេមក្រៅបណ្តាញតាមអ៊ីនធឺណិត។ អ្នកប្រើប្រាស់ជាច្រើនអាចលេងដោយមិនចាំបាច់ដំឡើងបណ្តាញ។ Samurai Shodown ឥឡូវនេះអាចត្រូវបានលេងដោយអ្នកលេង 2 នាក់នៅលើបណ្តាញ CloudRetro

  
  កំណែសាកល្បងនៃហ្គេមអ្នកលេងច្រើនលើអ៊ីនធឺណិតនៅលើឧបករណ៍ផ្សេងៗ

  ហេដ្ឋារចនាសម្ព័ន្ធ

  តម្រូវការនិងបច្ចេកវិទ្យាជង់

  ខាងក្រោមនេះគឺជាបញ្ជីនៃតម្រូវការដែលខ្ញុំបានកំណត់មុនពេលចាប់ផ្តើមគម្រោង។

  1. អ្នកលេងម្នាក់
  តម្រូវការនេះប្រហែលជាមិនសំខាន់ពេក ឬច្បាស់នៅទីនេះទេ ប៉ុន្តែវាគឺជាការដកយកដ៏សំខាន់របស់ខ្ញុំ វាអនុញ្ញាតឱ្យហ្គេមលើពពកនៅឆ្ងាយពីសេវាកម្មស្ទ្រីមបែបប្រពៃណីតាមដែលអាចធ្វើទៅបាន។ ប្រសិនបើយើងផ្តោតលើហ្គេមដែលមានអ្នកលេងតែម្នាក់ យើងអាចកម្ចាត់ម៉ាស៊ីនមេ ឬ CDN ចេញពីកណ្តាល ព្រោះយើងមិនចាំបាច់ចាក់ផ្សាយទៅកាន់មហាជននោះទេ។ ជំនួសឱ្យការអាប់ឡូតស្ទ្រីមទៅកាន់ម៉ាស៊ីនមេលិច ឬបញ្ជូនកញ្ចប់ព័ត៌មានទៅម៉ាស៊ីនមេ WebSocket កណ្តាល ស្ទ្រីមសេវាកម្មត្រូវបានបញ្ជូនដោយផ្ទាល់ទៅអ្នកប្រើប្រាស់តាមរយៈការតភ្ជាប់ WebRTC ពីគ្នាទៅវិញទៅមក។

  2. ស្ទ្រីមមេឌៀដែលមានភាពយឺតយ៉ាវទាប
  ការអានអំពី Stadia ខ្ញុំតែងតែឃើញ WebRTC ដែលបានលើកឡើងនៅក្នុងអត្ថបទមួយចំនួន។ ខ្ញុំបានដឹងថា WebRTC គឺជាបច្ចេកវិទ្យាដ៏ល្អឥតខ្ចោះ និងល្អឥតខ្ចោះសម្រាប់ប្រើប្រាស់ក្នុងការលេងហ្គេមលើពពក។ WebRTC គឺជាគម្រោងដែលផ្តល់កម្មវិធីរុករកតាមអ៊ីនធឺណិត និងកម្មវិធីទូរស័ព្ទជាមួយនឹងការទំនាក់ទំនងតាមពេលវេលាជាក់ស្តែងតាមរយៈ API ដ៏សាមញ្ញមួយ។ វាផ្តល់នូវការភ្ជាប់ពីមិត្តភ័ក្តិទៅមិត្តភ័ក្តិ ត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ប្រព័ន្ធផ្សព្វផ្សាយ និងមានកូឌិកស្តង់ដារដែលភ្ជាប់មកជាមួយដូចជា VP8 និង H264 ។

  ខ្ញុំបានកំណត់អាទិភាពក្នុងការធានានូវបទពិសោធន៍អ្នកប្រើប្រាស់ល្អបំផុតដែលអាចធ្វើទៅបាន លើការរក្សាក្រាហ្វិកដែលមានគុណភាពខ្ពស់។ ការខាតបង់ខ្លះអាចទទួលយកបាននៅក្នុងក្បួនដោះស្រាយ។ Google Stadia មានជំហានបន្ថែមក្នុងការកាត់បន្ថយទំហំរូបភាពនៅលើម៉ាស៊ីនមេ ហើយស៊ុមត្រូវបានបង្កើនគុណភាពកាន់តែខ្ពស់មុនពេលបញ្ជូនទៅកាន់មិត្តភ័ក្តិ។

  3. ចែកចាយហេដ្ឋារចនាសម្ព័ន្ធជាមួយនឹងផ្លូវភូមិសាស្ត្រ
  មិនថាក្បួនដោះស្រាយការបង្ហាប់ និងកូដត្រូវបានធ្វើឱ្យប្រសើរប៉ុណ្ណានោះទេ បណ្តាញនៅតែជាកត្តាសម្រេចចិត្តដែលរួមចំណែកច្រើនបំផុតដល់ភាពយឺតយ៉ាវ។ ស្ថាបត្យកម្មត្រូវតែមានយន្តការមួយដើម្បីផ្គូផ្គងម៉ាស៊ីនមេដែលនៅជិតអ្នកប្រើប្រាស់បំផុត ដើម្បីកាត់បន្ថយពេលវេលាធ្វើដំណើរទៅមក (RTT)។ ស្ថាបត្យកម្មត្រូវតែមានអ្នកសម្របសម្រួល 1 និងម៉ាស៊ីនមេស្ទ្រីមជាច្រើនដែលចែកចាយទូទាំងពិភពលោក៖ អាមេរិកខាងលិច អាមេរិកខាងកើត អឺរ៉ុប សិង្ហបុរី ចិន។ ម៉ាស៊ីនមេស្ទ្រីមទាំងអស់ត្រូវតែដាច់ដោយឡែកទាំងស្រុង។ ប្រព័ន្ធអាចកែសម្រួលការចែកចាយរបស់វា នៅពេលដែលម៉ាស៊ីនមេចូលរួម ឬចាកចេញពីបណ្តាញ។ ដូច្នេះជាមួយនឹងចរាចរណ៍ធំ ការបន្ថែមម៉ាស៊ីនមេបន្ថែមអនុញ្ញាតឱ្យធ្វើមាត្រដ្ឋានផ្ដេក។

  4. ភាពឆបគ្នានៃកម្មវិធីរុករក
  ការលេងហ្គេមលើពពកគឺល្អបំផុតនៅពេលដែលវាត្រូវការតិចបំផុតពីអ្នកប្រើប្រាស់។ នេះមានន័យថាវាអាចដំណើរការនៅក្នុងកម្មវិធីរុករក។ កម្មវិធីរុករកតាមអ៊ីនធឺណិតជួយធ្វើឱ្យបទពិសោធន៍លេងហ្គេមមានផាសុកភាពតាមដែលអាចធ្វើទៅបានសម្រាប់អ្នកប្រើប្រាស់ ដោយរក្សាទុកពួកគេពីការដំឡើងកម្មវិធី និងផ្នែករឹង។ កម្មវិធីរុករកក៏ជួយផ្តល់មុខងារឆ្លងវេទិការវាងកំណែចល័ត និងកុំព្យូទ័រផងដែរ។ ជាសំណាងល្អ WebRTC ត្រូវបានគាំទ្រយ៉ាងល្អនៅទូទាំងកម្មវិធីរុករកផ្សេងៗ។

  5. ការបំបែកយ៉ាងច្បាស់លាស់នៃចំណុចប្រទាក់ហ្គេម និងសេវាកម្ម
  ខ្ញុំមើលសេវាកម្មហ្គេមលើពពកជាវេទិកាមួយ។ មនុស្សគ្រប់រូបគួរតែអាចភ្ជាប់អ្វីៗទៅវេទិកា។ ឥឡូវនេះខ្ញុំបានរួមបញ្ចូល LibRetro ជាមួយនឹងសេវាកម្ម cloud gaming ពីព្រោះ LibRetro ផ្តល់នូវចំណុចប្រទាក់កម្មវិធីត្រាប់តាមហ្គេមដ៏ស្រស់ស្អាតសម្រាប់ហ្គេម retro ដូចជា SNES, GBA, PS ។

  6. បន្ទប់សម្រាប់អ្នកលេងច្រើន ការលេងហ្វូងមនុស្ស និងការភ្ជាប់ខាងក្រៅ (តំណជ្រៅ) ជាមួយហ្គេម
  CloudRetro គាំទ្រការលេងហ្គេមថ្មីជាច្រើនដូចជា CrowdPlay និង Online MultiPlayer សម្រាប់ហ្គេមអតីតកាល។ ប្រសិនបើអ្នកប្រើមួយចំនួនបើកតំណភ្ជាប់ជ្រៅដូចគ្នានៅលើកុំព្យូទ័រផ្សេងគ្នា ពួកគេនឹងឃើញហ្គេមដែលកំពុងដំណើរការដូចគ្នា ហើយថែមទាំងអាចចូលរួមវាបានទៀតផង។

  ជាងនេះទៅទៀត ស្ថានភាពហ្គេមត្រូវបានរក្សាទុកក្នុងឃ្លាំងផ្ទុកពពក។ វាអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់បន្តលេងបានគ្រប់ពេលនៅលើឧបករណ៍ផ្សេងទៀត។

  7. ការធ្វើមាត្រដ្ឋានផ្ដេក
  ដូច SAAS ណាមួយនាពេលបច្ចុប្បន្ននេះ ការលេងហ្គេមលើពពកត្រូវតែត្រូវបានរចនាឡើងដើម្បីឱ្យមានមាត្រដ្ឋានផ្ដេក។ ការរចនាអ្នកសម្របសម្រួល-កម្មករអនុញ្ញាតឱ្យអ្នកបន្ថែមកម្មករបន្ថែមទៀតដើម្បីបម្រើចរាចរណ៍កាន់តែច្រើន។

  8. គ្មានការតភ្ជាប់ទៅពពកតែមួយ
  ហេដ្ឋារចនាសម្ព័ន្ធរបស់ CloudRetro ត្រូវបានរៀបចំឡើងនៅលើអ្នកផ្តល់សេវាពពកផ្សេងៗគ្នា (Digital Ocean, Alibaba, អ្នកផ្តល់សេវាផ្ទាល់ខ្លួន) សម្រាប់តំបន់ផ្សេងៗគ្នា។ ខ្ញុំបើកដំណើរការក្នុងកុងតឺន័រ Docker សម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធ និងកំណត់រចនាសម្ព័ន្ធការកំណត់បណ្តាញដោយប្រើស្គ្រីប bash ដើម្បីជៀសវាងការជាប់សោរចូលទៅក្នុងអ្នកផ្តល់សេវាពពកតែមួយ។ ដោយការរួមបញ្ចូលវាជាមួយ NAT Traversal នៅក្នុង WebRTC យើងអាចមានភាពបត់បែនក្នុងការដាក់ពង្រាយ CloudRetro នៅលើវេទិកាពពកណាមួយ និងសូម្បីតែនៅលើម៉ាស៊ីនរបស់អ្នកប្រើណាមួយ។

  ការរចនាស្ថាបត្យកម្ម

  កម្មករ៖ (ឬម៉ាស៊ីនមេស្ទ្រីមដែលបានរៀបរាប់ខាងលើ) គុណហ្គេម ដំណើរការបំពង់បំប្លែងកូដ និងចាក់មេឌៀដែលបានអ៊ិនកូដដល់អ្នកប្រើប្រាស់។ ករណីកម្មករត្រូវបានចែកចាយពាសពេញពិភពលោក ហើយកម្មករនិមួយៗអាចគ្រប់គ្រងវគ្គអ្នកប្រើប្រាស់ជាច្រើនក្នុងពេលដំណាលគ្នា។

  អ្នកសម្របសម្រួល៖ ទទួលខុសត្រូវក្នុងការផ្គូផ្គងអ្នកប្រើប្រាស់ថ្មីជាមួយកម្មករដែលសមស្របបំផុតសម្រាប់ការផ្សាយ។ អ្នកសម្របសម្រួលធ្វើអន្តរកម្មជាមួយកម្មករតាមរយៈ WebSocket ។

  ការផ្ទុកស្ថានភាពហ្គេម៖ ឧបករណ៍ផ្ទុកពីចម្ងាយកណ្តាលសម្រាប់រដ្ឋហ្គេមទាំងអស់។ ឧបករណ៍ផ្ទុកនេះផ្តល់នូវមុខងារសំខាន់ៗដូចជា រក្សាទុក/ផ្ទុកពីចម្ងាយ។

  
  ស្ថាបត្យកម្មកម្រិតកំពូលនៃ CloudRetro

  ស្គ្រីបផ្ទាល់ខ្លួន

  នៅពេលដែលអ្នកប្រើប្រាស់ថ្មីបើក CloudRetro នៅក្នុងជំហានទី 1 និងទី 2 ដែលបង្ហាញក្នុងរូបភាពខាងក្រោម អ្នកសម្របសម្រួលរួមជាមួយនឹងបញ្ជីបុគ្គលិកដែលមានត្រូវបានស្នើសុំទៅកាន់ទំព័រទីមួយ។ បន្ទាប់ពីនេះ ក្នុងជំហានទី 3 អតិថិជនគណនាការពន្យារពេលសម្រាប់បេក្ខជនទាំងអស់ដោយប្រើសំណើ HTTP ping ។ បន្ទាប់មកបញ្ជីនៃការពន្យារពេលនេះត្រូវបានបញ្ជូនត្រឡប់ទៅអ្នកសម្របសម្រួលវិញដើម្បីឱ្យគាត់អាចកំណត់បុគ្គលិកដែលសមរម្យបំផុតដើម្បីបម្រើអ្នកប្រើប្រាស់។ ជំហានទី 4 ខាងក្រោមបង្កើតហ្គេម។ ការតភ្ជាប់ស្ទ្រីម WebRTC ត្រូវបានបង្កើតឡើងរវាងអ្នកប្រើប្រាស់ និងបុគ្គលិកដែលបានចាត់តាំង។
  
  ស្គ្រីបអ្នកប្រើប្រាស់បន្ទាប់ពីទទួលបានសិទ្ធិចូលប្រើ

  អ្វីដែលនៅខាងក្នុងកម្មករ

  ហ្គេម និងបំពង់ស្ទ្រីមត្រូវបានរក្សាទុកនៅខាងក្នុងបុគ្គលិកក្នុងភាពឯកោ និងផ្លាស់ប្តូរព័ត៌មាននៅទីនោះតាមរយៈចំណុចប្រទាក់។ បច្ចុប្បន្ននេះទំនាក់ទំនងនេះត្រូវបានអនុវត្តដោយការផ្ទេរទិន្នន័យនៅក្នុងអង្គចងចាំតាមរយៈ ប៉ុស្តិ៍ Golang នៅក្នុងដំណើរការដូចគ្នា។ គោលដៅបន្ទាប់គឺការបំបែកខ្លួន, i.e. ការបើកដំណើរការហ្គេមដោយឯករាជ្យនៅក្នុងដំណើរការមួយផ្សេងទៀត។

  
  អន្តរកម្មនៃសមាសធាតុកម្មករ

  សមាសធាតុសំខាន់ៗ៖

  • WebRTC៖ សមាសភាគម៉ាស៊ីនភ្ញៀវដែលទទួលយកការបញ្ចូលរបស់អ្នកប្រើ និងបញ្ចេញមេឌៀដែលបានអ៊ិនកូដពីម៉ាស៊ីនមេ។
  • កម្មវិធីត្រាប់តាមហ្គេម៖ សមាសធាតុហ្គេម។ សូមអរគុណដល់បណ្ណាល័យ Libretro ប្រព័ន្ធអាចដំណើរការហ្គេមនៅក្នុងដំណើរការដូចគ្នា និងស្ទាក់ចាប់ប្រព័ន្ធផ្សព្វផ្សាយ និងស្ទ្រីមបញ្ចូលខាងក្នុង។
  • ស៊ុមក្នុងហ្គេមត្រូវបានចាប់យក និងផ្ញើទៅកាន់កម្មវិធីបំប្លែងកូដ។
  • រូបភាព/កម្មវិធីបំប្លែងសំឡេង៖ បំពង់បំប្លែងការអ៊ិនកូដដែលយកស៊ុមមេឌៀ អ៊ិនកូដពួកវាក្នុងផ្ទៃខាងក្រោយ និងបញ្ចេញរូបភាព/អូឌីយ៉ូដែលបានអ៊ិនកូដ។

  Реализация

  CloudRetro ពឹងផ្អែកលើ WebRTC ជាបច្ចេកវិជ្ជាឆ្អឹងខ្នងរបស់វា ដូច្នេះមុននឹងចូលទៅក្នុងព័ត៌មានលម្អិតនៃការអនុវត្ត Golang ខ្ញុំបានសម្រេចចិត្តនិយាយអំពី WebRTC ខ្លួនឯង។ នេះគឺជាបច្ចេកវិទ្យាដ៏អស្ចារ្យដែលបានជួយខ្ញុំយ៉ាងខ្លាំងក្នុងការសម្រេចបាននូវភាពយឺតយ៉ាវទីពីរសម្រាប់ការផ្សាយទិន្នន័យ។

  WebRTC

  WebRTC ត្រូវ​បាន​រចនា​ឡើង​ដើម្បី​ផ្តល់​នូវ​ការ​តភ្ជាប់​ពី​មួយ​ទៅ​មួយ​ដែល​មាន​គុណភាព​ខ្ពស់​នៅ​លើ​កម្មវិធី​ទូរសព្ទ​និង​កម្មវិធីរុករក​តាម​អ៊ីនធឺណិត​ដើម​ដោយ​ប្រើ APIs សាមញ្ញ។

  NAT ឆ្លងកាត់

  WebRTC ត្រូវបានគេស្គាល់ថាសម្រាប់មុខងារ NAT Traversal របស់វា។ WebRTC ត្រូវ​បាន​រចនា​ឡើង​សម្រាប់​ការ​ទំនាក់ទំនង​ពី​មនុស្ស​ម្នាក់​ទៅ​ម្នាក់។ គោលដៅរបស់វាគឺដើម្បីស្វែងរកផ្លូវផ្ទាល់ដែលសមរម្យបំផុត ជៀសវាងច្រកផ្លូវ NAT និងជញ្ជាំងភ្លើងសម្រាប់ការទំនាក់ទំនងពីមិត្តភ័ក្តិតាមរយៈដំណើរការហៅថា ICE. ជាផ្នែកនៃដំណើរការនេះ WebRTC APIs ស្វែងរកអាសយដ្ឋាន IP សាធារណៈរបស់អ្នកដោយប្រើម៉ាស៊ីនមេ STUN ហើយបញ្ជូនវាទៅម៉ាស៊ីនមេបញ្ជូនត (បើក) នៅពេលដែលការតភ្ជាប់ដោយផ្ទាល់មិនអាចបង្កើតបាន។

  ទោះយ៉ាងណាក៏ដោយ CloudRetro មិនទាញយកប្រយោជន៍ទាំងស្រុងពីលក្ខណៈពិសេសនេះទេ។ ការតភ្ជាប់ពីមិត្តភ័ក្តិរបស់វាមិនមានរវាងអ្នកប្រើប្រាស់ទេ ប៉ុន្តែរវាងអ្នកប្រើប្រាស់ និងម៉ាស៊ីនមេពពក។ ផ្នែកខាងម៉ាស៊ីនមេនៃម៉ូដែលនេះមានការរឹតបន្តឹងទំនាក់ទំនងផ្ទាល់តិចជាងឧបករណ៍អ្នកប្រើប្រាស់ធម្មតា។ នេះអនុញ្ញាតឱ្យអ្នកបើកច្រកចូលជាមុន ឬប្រើអាសយដ្ឋាន IP សាធារណៈដោយផ្ទាល់ ដោយសារម៉ាស៊ីនមេមិននៅពីក្រោយ NAT ទេ។

  ពីមុនខ្ញុំចង់បង្វែរគម្រោងទៅជាវេទិកាចែកចាយហ្គេមសម្រាប់ Cloud Gaming។ គំនិតនេះគឺដើម្បីអនុញ្ញាតឱ្យអ្នកបង្កើតហ្គេមផ្តល់ហ្គេម និងធនធាននៃការផ្សាយ។ ហើយអ្នកប្រើប្រាស់នឹងធ្វើអន្តរកម្មជាមួយអ្នកផ្តល់សេវាដោយផ្ទាល់។ នៅក្នុងលក្ខណៈវិមជ្ឈការនេះ CloudRetro គ្រាន់តែជាក្របខ័ណ្ឌសម្រាប់ភ្ជាប់ធនធានស្ទ្រីមភាគីទីបីទៅកាន់អ្នកប្រើប្រាស់ ដែលធ្វើឱ្យវាអាចធ្វើមាត្រដ្ឋានបានកាន់តែច្រើននៅពេលដែលវាលែងជាម្ចាស់ផ្ទះ។ តួនាទីរបស់ WebRTC NAT Traversal នៅទីនេះគឺមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការជួយសម្រួលដល់ការចាប់ផ្តើមការតភ្ជាប់ពីម្នាក់ទៅម្នាក់នៅលើធនធាននៃការផ្សាយរបស់ភាគីទីបី ដែលធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់អ្នកបង្កើតដើម្បីភ្ជាប់ទៅបណ្តាញ។

  ការបង្ហាប់វីដេអូ

  ការបង្ហាប់វីដេអូគឺជាផ្នែកមួយដែលមិនអាចខ្វះបាននៃបំពង់បង្ហូរប្រេង និងរួមចំណែកយ៉ាងច្រើនដល់លំហូររលូន។ ខណៈពេលដែលវាមិនចាំបាច់ក្នុងការដឹងរាល់ព័ត៌មានលម្អិតនៃការអ៊ិនកូដវីដេអូ VP8/H264 នោះ ការយល់ដឹងអំពីគោលគំនិតអាចជួយអ្នកឱ្យយល់អំពីជម្រើសល្បឿនវីដេអូស្ទ្រីម បំបាត់កំហុសអាកប្បកិរិយាដែលមិនរំពឹងទុក និងកែតម្រូវភាពយឺតយ៉ាវ។

  ការបង្ហាប់វីដេអូសម្រាប់សេវាកម្មស្ទ្រីមគឺពិបាកព្រោះក្បួនដោះស្រាយត្រូវតែធានាថាពេលវេលាអ៊ិនកូដសរុប + ពេលវេលាបញ្ជូនបណ្តាញ + ពេលវេលាឌិកូដគឺទាបតាមដែលអាចធ្វើទៅបាន។ លើសពីនេះ ដំណើរការសរសេរកូដត្រូវតែស្រប និងបន្ត។ ការដោះដូរការបំប្លែងកូដមួយចំនួនមិនត្រូវបានអនុវត្តទេ—ឧទាហរណ៍ យើងមិនអាចអនុគ្រោះដល់ការបំប្លែងកូដយូរជាងទំហំឯកសារតូចជាង និងរយៈពេលនៃការឌិកូដ ឬប្រើការបង្ហាប់មិនស៊ីសង្វាក់គ្នានោះទេ។

  គំនិតនៅពីក្រោយការបង្ហាប់វីដេអូគឺដើម្បីលុបបំបាត់ព័ត៌មានដែលមិនចាំបាច់ ខណៈពេលដែលរក្សាបាននូវកម្រិតភាពត្រឹមត្រូវដែលអាចទទួលយកបានសម្រាប់អ្នកប្រើប្រាស់។ បន្ថែមពីលើការអ៊ិនកូដស៊ុមរូបភាពឋិតិវន្តបុគ្គល ក្បួនដោះស្រាយបង្ហាញពីស៊ុមបច្ចុប្បន្នពីស៊ុមមុន និងបន្ទាប់ ដូច្នេះមានតែភាពខុសគ្នារបស់ពួកគេប៉ុណ្ណោះដែលត្រូវបានផ្ញើ។ ដូចដែលអាចមើលឃើញពីឧទាហរណ៍ជាមួយ Pacman មានតែចំនុចឌីផេរ៉ង់ស្យែលប៉ុណ្ណោះដែលត្រូវបានបញ្ជូន។

  
  ការប្រៀបធៀបស៊ុមវីដេអូដោយប្រើ Pacman ជាឧទាហរណ៍

  ការបង្ហាប់អូឌីយ៉ូ

  ដូចគ្នានេះដែរ ក្បួនដោះស្រាយការបង្ហាប់អូឌីយ៉ូ លុបទិន្នន័យដែលមនុស្សមិនអាចយល់បាន។ Opus បច្ចុប្បន្នគឺជាកូឌិកអូឌីយ៉ូដែលដំណើរការល្អបំផុត។ វាត្រូវបានរចនាឡើងដើម្បីបញ្ជូនរលកអូឌីយ៉ូលើពិធីការ datagram ដែលបានបញ្ជាទិញដូចជា RTP (Real Time Transport Protocol)។ ភាពយឺតរបស់វាទាបជាង mp3 និង aac ហើយគុណភាពគឺខ្ពស់ជាង។ ភាពយឺតយ៉ាវជាធម្មតាគឺប្រហែល 5 ~ 66,5ms ។

  Pion, WebRTC នៅ Golang

  ភី គឺជាគម្រោងប្រភពបើកចំហដែលនាំ WebRTC ទៅ Golang ។ ជំនួសឱ្យការរុំធម្មតានៃបណ្ណាល័យ C++ WebRTC ដើម Pion គឺជាការអនុវត្ត Golang នៃ WebRTC ជាមួយនឹងការអនុវត្តកាន់តែប្រសើរ ការរួមបញ្ចូល Go និងការគ្រប់គ្រងកំណែលើពិធីការ WebRTC ។

  បណ្ណាល័យក៏បើកការផ្សាយជាមួយនឹងឧបករណ៍ភ្ជាប់ដ៏អស្ចារ្យជាច្រើនជាមួយនឹងភាពយឺតយ៉ាវទីពីរ។ វាមានការអនុវត្តផ្ទាល់ខ្លួនរបស់ STUN, DTLS, SCTP ជាដើម។ និងការពិសោធន៍មួយចំនួនជាមួយ QUIC និង WebAssembly ។ បណ្ណាល័យប្រភពបើកចំហនេះគឺជាធនធានសិក្សាដ៏ល្អមួយជាមួយនឹងឯកសារដ៏ល្អ ការអនុវត្តពិធីការបណ្តាញ និងឧទាហរណ៍ល្អៗ។

  សហគមន៍ Pion ដែលដឹកនាំដោយអ្នកបង្កើតដែលស្រលាញ់ខ្លាំង មានភាពរស់រវើក ជាមួយនឹងការពិភាក្សាអំពីគុណភាពជាច្រើនកំពុងដំណើរការអំពី WebRTC ។ ប្រសិនបើអ្នកចាប់អារម្មណ៍លើបច្ចេកវិទ្យានេះ សូមចូលរួម http://pion.ly/slack - អ្នកនឹងរៀនអ្វីថ្មីៗជាច្រើន។

  ការសរសេរ CloudRetro នៅក្នុង Golang

  
  ការអនុវត្តកម្មករនៅក្នុង Go

  ទៅកាន់ប៉ុស្តិ៍នៅក្នុងសកម្មភាព

  សូមអរគុណចំពោះការរចនាប៉ុស្តិ៍ដ៏ស្រស់ស្អាតរបស់ Go បញ្ហានៃការផ្សាយព្រឹត្តិការណ៍ និងការស្របគ្នាត្រូវបានសម្រួលយ៉ាងខ្លាំង។ ដូចនៅក្នុងដ្យាក្រាម GoRoutines ផ្សេងគ្នាមានសមាសធាតុជាច្រើនដែលកំពុងដំណើរការស្របគ្នា។ សមាសធាតុនីមួយៗគ្រប់គ្រងស្ថានភាពរបស់វា និងទំនាក់ទំនងតាមរយៈបណ្តាញ។ ការអះអាងជ្រើសរើសរបស់ Golang បង្ខំឱ្យព្រឹត្តិការណ៍អាតូមិកមួយត្រូវបានដំណើរការរាល់ពេលនៅក្នុងហ្គេម (គូសធីកក្នុងហ្គេម)។ នេះមានន័យថាមិនចាំបាច់ចាក់សោរសម្រាប់ការរចនានេះទេ។ ឧទាហរណ៍ នៅពេលដែលអ្នកប្រើប្រាស់រក្សាទុក រូបថតពេញលេញនៃស្ថានភាពហ្គេមត្រូវបានទាមទារ។ ស្ថានភាពនេះគួរតែបន្ត ដោយចូលរហូតដល់ការរក្សាទុកបានបញ្ចប់។ កំឡុងពេលធីកហ្គេមនីមួយៗ កម្មវិធីខាងក្រោយអាចគ្រប់គ្រងបានតែប្រតិបត្តិការរក្សាទុក ឬបញ្ចូលប៉ុណ្ណោះ ដែលធ្វើឱ្យដំណើរការដំណើរការមានសុវត្ថិភាព។

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

  អ្នកគាំទ្រចូល / ចេញអ្នកគាំទ្រ

  គំរូ Golang នេះសមនឹងករណីប្រើប្រាស់ CrowdPlay និង Multiple Player របស់ខ្ញុំយ៉ាងល្អឥតខ្ចោះ។ តាមលំនាំនេះ ធាតុចូលរបស់អ្នកប្រើប្រាស់ទាំងអស់នៅក្នុងបន្ទប់មួយត្រូវបានសាងសង់នៅក្នុងច្រកចូលកណ្តាល។ បន្ទាប់មកប្រព័ន្ធផ្សព្វផ្សាយហ្គេមត្រូវបានដាក់ឱ្យប្រើប្រាស់ទៅកាន់អ្នកប្រើប្រាស់ទាំងអស់នៅក្នុងបន្ទប់តែមួយ។ នៅក្នុងវិធីនេះ យើងសម្រេចបាននូវការបែងចែកស្ថានភាពហ្គេមរវាងវគ្គហ្គេមជាច្រើននៃអ្នកប្រើប្រាស់ផ្សេងៗគ្នា។

  
  ការធ្វើសមកាលកម្មរវាងវគ្គផ្សេងៗគ្នា

  គុណវិបត្តិនៃ Golang

  Golang គឺមិនល្អឥតខ្ចោះទេ។ ឆានែលគឺយឺត។ បើប្រៀបធៀបទៅនឹងការទប់ស្កាត់ ប៉ុស្តិ៍ Go គឺជាមធ្យោបាយងាយស្រួលជាងក្នុងការដោះស្រាយព្រឹត្តិការណ៍ដំណាលគ្នា និងជាខ្សែ ប៉ុន្តែប៉ុស្តិ៍មិនផ្តល់នូវដំណើរការល្អបំផុតនោះទេ។ មានតក្កវិជ្ជាទប់ស្កាត់ស្មុគស្មាញនៅក្រោមឆានែល។ ដូច្នេះខ្ញុំបានធ្វើការកែតម្រូវមួយចំនួនចំពោះការអនុវត្ត ដោយអនុវត្តការចាក់សោ និងតម្លៃអាតូមិចឡើងវិញនៅពេលជំនួសឆានែលដើម្បីបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការ។

  លើសពីនេះ អ្នកប្រមូលសំរាមនៅ Golang គឺមិនអាចគ្រប់គ្រងបាន ដែលជួនកាលបណ្តាលឱ្យមានការផ្អាកយូរគួរឱ្យសង្ស័យ។ វារំខានយ៉ាងខ្លាំងដល់កម្មវិធីផ្សាយតាមពេលវេលាជាក់ស្តែង។

  ស៊ី។ អូ

  គម្រោងនេះប្រើប្រាស់បណ្ណាល័យ Golang VP8/H264 ដែលមានប្រភពបើកចំហសម្រាប់ការបង្រួមប្រព័ន្ធផ្សព្វផ្សាយ និង Libretro សម្រាប់កម្មវិធីត្រាប់តាមហ្គេម។ បណ្ណាល័យ​ទាំង​អស់​នេះ​គឺ​គ្រាន់​តែ​ជា​កញ្ចប់​នៃ​បណ្ណាល័យ C ក្នុង Go ដោយ​ប្រើ ស៊ី។ អូ. គុណវិបត្តិមួយចំនួនត្រូវបានរាយក្នុង ប្រកាសនេះដោយ Dave Cheney. បញ្ហាដែលខ្ញុំជួបប្រទះ៖

  • អសមត្ថភាពក្នុងការចាប់ការគាំងនៅក្នុង CGO សូម្បីតែជាមួយនឹង Golang RecoveryCrash;
  • ការបរាជ័យក្នុងការកំណត់អត្តសញ្ញាណការរាំងស្ទះនៃការអនុវត្ត នៅពេលដែលយើងមិនអាចរកឃើញបញ្ហាលម្អិតនៅក្នុង CGO ។

  សេចក្តីសន្និដ្ឋាន

  ខ្ញុំបានសំរេចគោលដៅរបស់ខ្ញុំក្នុងការយល់ដឹងអំពីសេវាកម្មហ្គេមលើពពក និងបង្កើតវេទិកាដែលជួយខ្ញុំលេងហ្គេមអតីតកាលដែលនឹកស្មានមិនដល់ជាមួយមិត្តរបស់ខ្ញុំតាមអ៊ីនធឺណិត។ គម្រោងនេះនឹងមិនអាចធ្វើទៅបានទេបើគ្មានបណ្ណាល័យ Pion និងការគាំទ្រពីសហគមន៍ Pion ។ ខ្ញុំ​មាន​អំណរគុណ​យ៉ាង​ខ្លាំង​ចំពោះ​ការ​អភិវឌ្ឍ​យ៉ាង​ខ្លាំង​របស់​វា។ APIs សាមញ្ញដែលផ្តល់ដោយ WebRTC និង Pion ធានាបាននូវការរួមបញ្ចូលដោយគ្មានថ្នេរ។ ភ័ស្តុតាងដំបូងនៃគំនិតរបស់ខ្ញុំត្រូវបានចេញផ្សាយនៅសប្តាហ៍ដដែលនោះ ទោះបីជាខ្ញុំមិនមានចំណេះដឹងពីមុនអំពីការទំនាក់ទំនងពីមិត្តភ័ក្តិ (P2P) ក៏ដោយ។

  ទោះបីជាមានភាពងាយស្រួលក្នុងការរួមបញ្ចូលក៏ដោយ ការស្ទ្រីម P2P គឺពិតជាតំបន់ស្មុគស្មាញក្នុងវិទ្យាសាស្ត្រកុំព្យូទ័រ។ នាងត្រូវដោះស្រាយជាមួយនឹងភាពស្មុគស្មាញនៃស្ថាបត្យកម្មបណ្តាញដែលមានរយៈពេលយូរដូចជា IP និង NAT ដើម្បីបង្កើតវគ្គ peer-to-peer ។ ខណៈពេលដែលកំពុងធ្វើការលើគម្រោងនេះ ខ្ញុំបានទទួលចំណេះដឹងដ៏មានតម្លៃជាច្រើនអំពីបណ្តាញ និងការបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការ ដូច្នេះខ្ញុំលើកទឹកចិត្តអ្នកគ្រប់គ្នាឱ្យសាកល្បងបង្កើតផលិតផល P2P ដោយប្រើ WebRTC ។

  CloudRetro ឆ្លើយតបទៅនឹងករណីប្រើប្រាស់ទាំងអស់ដែលខ្ញុំបានរំពឹងទុកពីទស្សនៈរបស់ខ្ញុំក្នុងនាមជាអ្នកលេងហ្គេមបែបអតីតកាល។ ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំគិតថាមានផ្នែកជាច្រើននៅក្នុងគម្រោងដែលខ្ញុំអាចកែលម្អ ដូចជាការធ្វើឱ្យបណ្តាញកាន់តែគួរឱ្យទុកចិត្ត និងដំណើរការ ការផ្តល់ក្រាហ្វិកហ្គេមគុណភាពខ្ពស់ ឬសមត្ថភាពក្នុងការចែករំលែកហ្គេមរវាងអ្នកប្រើប្រាស់។ ខ្ញុំកំពុងធ្វើការយ៉ាងលំបាកលើរឿងនេះ។ សូម​អនុវត្ត​តាម គម្រោង ហើយគាំទ្រវាប្រសិនបើអ្នកចូលចិត្តវា។

ប្រភព: www.habr.com