Open source cloud game on WebRTC: p2p, multiplayer, zero latency

ຊອບແວເປັນການບໍລິການ, ໂຄງສ້າງພື້ນຖານເປັນການບໍລິການ, ເວທີເປັນການບໍລິການ, ເວທີການສື່ສານເປັນການບໍລິການ, ການປະຊຸມວິດີໂອເປັນການບໍລິການ, ແມ່ນຫຍັງກ່ຽວກັບເກມເມຄເປັນບໍລິການ? ໄດ້ມີຄວາມພະຍາຍາມຫຼາຍຄັ້ງແລ້ວທີ່ຈະສ້າງການຫຼິ້ນເກມໃນຄລາວ (Cloud Gaming), ເຊັ່ນ Stadia, ທີ່ເປີດຕົວໂດຍ Google ເມື່ອບໍ່ດົນມານີ້. Stadia ບໍ່ໃໝ່ກັບ WebRTC, ແຕ່ຄົນອື່ນສາມາດໃຊ້ WebRTC ໃນທາງດຽວກັນບໍ?

Thanh Nguyen ຕັດສິນໃຈທົດສອບໂອກາດນີ້ໃນໂຄງການ open source CloudRetro ຂອງລາວ. CloudRetro ແມ່ນອີງໃສ່ Pion, ນິຍົມ ຫ້ອງສະໝຸດ WebRTC ອີງໃສ່ Go (ຂໍຂອບໃຈ ສະແດງໃຫ້ເຫັນ ຈາກທີມງານພັດທະນາ Pion ສໍາລັບການຊ່ວຍເຫຼືອຂອງພວກເຂົາໃນການກະກຽມບົດຄວາມນີ້). ​ໃນ​ບົດ​ຄວາມ​ນີ້, ທ່ານ Thanh ​ໄດ້​ສະ​ເໜີ​ສະພາບ​ລວມຂອງ​ສະຖາປັດຕະຍະກຳ​ຂອງ​ໂຄງການ​ຂອງ​ຕົນ, ພ້ອມ​ທັງ​ກ່າວ​ເຖິງ​ບັນດາ​ສິ່ງ​ທີ່​ເປັນ​ປະ​ໂຫຍ​ດທີ່​ລາວ​ໄດ້​ຮຽນ​ຮູ້ ​ແລະ ສິ່ງ​ທ້າ​ທາຍ​ທີ່​ລາວ​ປະສົບ​ໃນ​ການ​ເຮັດ​ວຽກ.

ເຂົ້າ

ໃນປີກາຍນີ້, ເມື່ອ Google ປະກາດ Stadia, ມັນກໍ່ເຮັດໃຫ້ຂ້ອຍຄິດ. ແນວຄວາມຄິດດັ່ງກ່າວແມ່ນເປັນເອກະລັກແລະນະວັດຕະກໍາຫຼາຍທີ່ຂ້າພະເຈົ້າສົງໄສຢ່າງຕໍ່ເນື່ອງວ່າມັນເປັນໄປໄດ້ແນວໃດກັບເຕັກໂນໂລຢີທີ່ມີຢູ່. ຄວາມປາຖະໜາທີ່ຈະເຂົ້າໃຈຫົວຂໍ້ນີ້ໃຫ້ດີຂຶ້ນໄດ້ກະຕຸ້ນຂ້ອຍໃຫ້ສ້າງເວີຊັ່ນຂອງຂ້ອຍເອງຂອງເກມຄລາວແບບເປີດ. ຜົນໄດ້ຮັບແມ່ນ fantastic ພຽງແຕ່. ຂ້າງລຸ່ມນີ້ຂ້າພະເຈົ້າຢາກແບ່ງປັນຂະບວນການເຮັດວຽກກ່ຽວກັບປີຂອງຂ້ອຍ ໂຄງການ.

TLDR: ສະບັບສະໄລ້ສັ້ນທີ່ມີຈຸດເດັ່ນ

ເປັນຫຍັງເກມຄລາວຈຶ່ງເປັນອະນາຄົດ

ຂ້າ​ພະ​ເຈົ້າ​ເຊື່ອ​ວ່າ​ໃນ​ໄວໆ​ນີ້ Cloud Gaming ຈະ​ກາຍ​ເປັນ​ການ​ຜະ​ລິດ​ຕໍ່​ໄປ​ຂອງ​ການ​ບໍ່​ພຽງ​ແຕ່​ການ​ເກມ​, ແຕ່​ຍັງ​ຂົງ​ເຂດ​ອື່ນໆ​ຂອງ​ວິ​ທະ​ຍາ​ສາດ​ຄອມ​ພິວ​ເຕີ​. Cloud gaming ແມ່ນຈຸດສູງສຸດຂອງຮູບແບບລູກຄ້າ/ເຊີບເວີ. ຮູບແບບນີ້ຊ່ວຍເພີ່ມປະສິດທິພາບການຈັດການ backend ແລະຫຼຸດຜ່ອນການເຮັດວຽກຂອງ frontend ໂດຍການໂຮດເຫດຜົນເກມຢູ່ໃນເຊີບເວີທາງໄກແລະຖ່າຍທອດຮູບພາບ/ສຽງໄປຫາລູກຄ້າ. ເຊີບເວີເຮັດການປະມວນຜົນຢ່າງໜັກເພື່ອໃຫ້ລູກຄ້າບໍ່ມີຂໍ້ຈຳກັດຂອງຮາດແວອີກຕໍ່ໄປ.

Google Stadia ຊ່ວຍໃຫ້ທ່ານສາມາດຫຼິ້ນໄດ້ ເກມ AAA (ເຊັ່ນ: ເກມ blockbuster ລະດັບສູງ) ໃນການໂຕ້ຕອບເຊັ່ນ YouTube. ວິທີການດຽວກັນສາມາດໃຊ້ກັບແອັບພລິເຄຊັນອອບໄລນ໌ທີ່ຮຸນແຮງອື່ນໆ ເຊັ່ນ: ລະບົບປະຕິບັດການ ຫຼື ການອອກແບບກາຟິກ 2D/3D, ແລະອື່ນໆ. ເພື່ອໃຫ້ພວກເຮົາສາມາດແລ່ນພວກມັນໄດ້ຢ່າງຕໍ່ເນື່ອງໃນອຸປະກອນທີ່ມີສະເປັກຕ່ຳໃນທົ່ວຫຼາຍແພລດຟອມ.

ອະນາຄົດຂອງເທກໂນໂລຍີນີ້: ຈິນຕະນາການວ່າ Microsoft Windows 10 ແລ່ນຢູ່ໃນຕົວທ່ອງເວັບ Chrome ບໍ?

ການຫຼິ້ນເກມໃນຄລາວແມ່ນມີຄວາມທ້າທາຍທາງດ້ານເຕັກນິກ

ການຫຼິ້ນເກມແມ່ນໜຶ່ງໃນພື້ນທີ່ທີ່ຫາຍາກທີ່ຕ້ອງຕອບສະໜອງຜູ້ໃຊ້ຢ່າງຄົງທີ່ ແລະໄວ. ຖ້າບາງຄັ້ງພວກເຮົາພົບກັບຄວາມລ່າຊ້າ 2 ວິນາທີໃນເວລາຄລິກໃສ່ຫນ້າ, ນີ້ແມ່ນຍອມຮັບໄດ້. ການຖ່າຍທອດວິດີໂອສົດໆມີແນວໂນ້ມທີ່ຈະຊັກຊ້າສອງສາມວິນາທີ, ແຕ່ຍັງຄົງໃຫ້ຄວາມສາມາດໃຊ້ໄດ້ທີ່ສົມເຫດສົມຜົນ. ຢ່າງໃດກໍຕາມ, ຖ້າເກມຊ້າລົງເລື້ອຍໆໂດຍ 500ms, ມັນກໍ່ບໍ່ສາມາດຫຼິ້ນໄດ້. ເປົ້າໝາຍຂອງພວກເຮົາແມ່ນເພື່ອບັນລຸການຕອບສະໜອງທີ່ຕໍ່າທີ່ສຸດເພື່ອໃຫ້ຊ່ອງຫວ່າງລະຫວ່າງວັດສະດຸປ້ອນ ແລະສື່ມີໜ້ອຍເທົ່າທີ່ເປັນໄປໄດ້. ດັ່ງນັ້ນ, ວິທີການແບບດັ້ງເດີມຂອງການຖ່າຍທອດວິດີໂອແມ່ນບໍ່ສາມາດໃຊ້ໄດ້ຢູ່ທີ່ນີ້.

ແມ່ແບບເກມ Cloud ທົ່ວໄປ

ໂຄງການແຫຼ່ງເປີດ CloudRetro

ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈສ້າງຕົວຢ່າງການທົດສອບຂອງເກມຟັງເພື່ອເບິ່ງວ່າທັງຫມົດນີ້ເປັນໄປໄດ້ກັບຂໍ້ຈໍາກັດເຄືອຂ່າຍທີ່ເຄັ່ງຄັດ. ຂ້າພະເຈົ້າໄດ້ເລືອກ Golang ສໍາລັບຫຼັກຖານສະແດງແນວຄວາມຄິດເພາະວ່າມັນເປັນພາສາທີ່ຂ້ອຍຄຸ້ນເຄີຍທີ່ສຸດແລະເຫມາະສົມກັບການປະຕິບັດນີ້ສໍາລັບເຫດຜົນອື່ນໆ, ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບຕໍ່ມາ. ໄປແມ່ນງ່າຍດາຍແລະພັດທະນາຢ່າງໄວວາ; ຊ່ອງໃນ Go ແມ່ນດີເລີດສໍາລັບການຈັດການ multithreading.

ໂຄງການ CloudRetro.io ເປັນບໍລິການເກມຟັງຄລາວທີ່ເປີດສໍາລັບການຫຼິ້ນເກມ retro. ເປົ້າໝາຍຂອງໂຄງການແມ່ນເພື່ອນຳເອົາປະສົບການການຫຼິ້ນເກມທີ່ສະດວກສະບາຍທີ່ສຸດໃຫ້ກັບເກມ retro ແບບດັ້ງເດີມ ແລະເພີ່ມຜູ້ຫຼິ້ນຫຼາຍຄົນ.
ທ່ານສາມາດຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບໂຄງການທີ່ນີ້: https://github.com/giongto35/cloud-game.

ຟັງຊັນ CloudRetro

CloudRetro ໃຊ້ເກມ retro ເພື່ອສະແດງໃຫ້ເຫັນເຖິງພະລັງຂອງການຫຼິ້ນເກມໃນຄລາວ. ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບປະສົບການການຫຼິ້ນເກມທີ່ເປັນເອກະລັກຫຼາຍຢ່າງ.

• Portability ຂອງເກມ
  • ການຫຼິ້ນທັນທີເມື່ອເປີດໜ້າ; ບໍ່ຈໍາເປັນຕ້ອງດາວໂຫລດຫຼືຕິດຕັ້ງ
  • ເຮັດວຽກຢູ່ໃນຕົວທ່ອງເວັບຂອງມືຖື, ດັ່ງນັ້ນບໍ່ຈໍາເປັນຕ້ອງມີຊອບແວທີ່ຈະດໍາເນີນການ

• ເຊດຊັນເກມສາມາດຖືກແບ່ງປັນຜ່ານຫຼາຍອຸປະກອນ ແລະເກັບໄວ້ໃນຄລາວສຳລັບຄັ້ງຕໍ່ໄປທີ່ທ່ານເຂົ້າສູ່ລະບົບ
• ເກມສາມາດຖືກຖ່າຍທອດໄດ້, ຫຼືມັນສາມາດຫຼິ້ນໄດ້ໂດຍຜູ້ໃຊ້ຫຼາຍຄົນໃນເວລາດຽວກັນ:
  • Crowdplay ເຊັ່ນ TwitchPlayPokemon, ພຽງແຕ່ຂ້າມເວທີແລະເວລາຈິງຫຼາຍຂຶ້ນ
  • ເກມອອຟໄລອອນໄລນ໌. ຜູ້ໃຊ້ຫຼາຍຄົນສາມາດຫຼິ້ນໄດ້ໂດຍບໍ່ຕ້ອງຕັ້ງເຄືອຂ່າຍ. ດຽວນີ້ Samurai Shodown ສາມາດຫຼິ້ນໄດ້ໂດຍ 2 ຜູ້ຫຼິ້ນຜ່ານເຄືອຂ່າຍ CloudRetro

  
  ເວີຊັນສາທິດຂອງເກມຫຼິ້ນຫຼາຍຄົນອອນໄລນ໌ຢູ່ໃນອຸປະກອນຕ່າງໆ

  ພື້ນຖານໂຄງລ່າງ

  ຄວາມຕ້ອງການແລະເຕັກໂນໂລຊີ stack

  ຂ້າງລຸ່ມນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງຄວາມຕ້ອງການທີ່ຂ້າພະເຈົ້າກໍານົດໄວ້ກ່ອນທີ່ຈະເລີ່ມຕົ້ນໂຄງການ.

  1. ຜູ້ນ XNUMX
  ຄວາມຕ້ອງການນີ້ອາດຈະເບິ່ງຄືວ່າບໍ່ສໍາຄັນເກີນໄປຫຼືເຫັນໄດ້ຊັດເຈນຢູ່ທີ່ນີ້, ແຕ່ມັນແມ່ນຫນຶ່ງໃນສິ່ງທີ່ສໍາຄັນຂອງຂ້ອຍ, ມັນຊ່ວຍໃຫ້ການຫຼິ້ນເກມໃນຄລາວຢູ່ຫ່າງໄກຈາກການບໍລິການສະຕີມແບບດັ້ງເດີມເທົ່າທີ່ເປັນໄປໄດ້. ຖ້າພວກເຮົາສຸມໃສ່ເກມທີ່ຜູ້ນດຽວ, ພວກເຮົາສາມາດກໍາຈັດເຄື່ອງແມ່ຂ່າຍສູນກາງຫຼື CDN ເພາະວ່າພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງຖ່າຍທອດໄປສູ່ມະຫາຊົນ. ແທນທີ່ຈະອັບໂຫລດສະຕຣີມໄປຫາເຊີບເວີ sink ຫຼືສົ່ງແພັກເກັດໄປຍັງເຊີບເວີ WebSocket ທີ່ເປັນສູນກາງ, ກະແສບໍລິການຖືກສົ່ງໂດຍກົງໃຫ້ຜູ້ໃຊ້ຜ່ານການເຊື່ອມຕໍ່ແບບ peer-to-peer WebRTC.

  2. ກະແສມີເດຍທີ່ມີເວລາຕອບສະໜອງຕໍ່າ
  ການອ່ານກ່ຽວກັບ Stadia, ຂ້ອຍມັກຈະເຫັນ WebRTC ທີ່ກ່າວເຖິງໃນບາງບົດຄວາມ. ຂ້ອຍຮູ້ວ່າ WebRTC ເປັນເທັກໂນໂລຍີທີ່ໂດດເດັ່ນ ແລະດີເລີດສຳລັບໃຊ້ໃນເກມຟັງ. WebRTC ແມ່ນໂຄງການທີ່ໃຫ້ຕົວທ່ອງເວັບແລະຄໍາຮ້ອງສະຫມັກມືຖືທີ່ມີການສື່ສານແບບສົດໆຜ່ານ API ງ່າຍໆ. ມັນສະຫນອງການເຊື່ອມຕໍ່ peer-to-peer, ຖືກປັບແຕ່ງສໍາລັບສື່, ແລະມີຕົວແປງສັນຍານມາດຕະຖານເຊັ່ນ VP8 ແລະ H264.

  ຂ້າພະເຈົ້າໄດ້ຈັດລໍາດັບຄວາມສໍາຄັນໃນການຮັບປະກັນປະສົບການຜູ້ໃຊ້ທີ່ດີທີ່ສຸດທີ່ເປັນໄປໄດ້ຫຼາຍກວ່າການຮັກສາຮູບພາບທີ່ມີຄຸນນະພາບສູງ. ການສູນເສຍບາງຢ່າງແມ່ນຍອມຮັບໄດ້ໃນ algorithm. Google Stadia ມີຂັ້ນຕອນເພີ່ມເຕີມຂອງການຫຼຸດຜ່ອນຂະຫນາດຮູບພາບໃນເຊີຟເວີ, ແລະເຟຣມຖືກປັບປຸງໃຫ້ມີຄຸນນະພາບສູງກວ່າກ່ອນທີ່ຈະຖືກສົ່ງໄປຫາເພື່ອນມິດ.

  3. ການແຈກຢາຍໂຄງສ້າງພື້ນຖານທີ່ມີເສັ້ນທາງພູມສາດ
  ບໍ່ວ່າວິທີການບີບອັດແລະລະຫັດຖືກປັບປຸງໃຫ້ດີເທົ່າໃດ, ເຄືອຂ່າຍຍັງຄົງເປັນປັດໃຈຕັດສິນທີ່ປະກອບສ່ວນຫຼາຍທີ່ສຸດຕໍ່ການ latency. ສະຖາປັດຕະຍະກໍາຕ້ອງມີກົນໄກການຈັບຄູ່ເຄື່ອງແມ່ຂ່າຍທີ່ໃກ້ຊິດກັບຜູ້ໃຊ້ທີ່ສຸດເພື່ອຫຼຸດຜ່ອນເວລາໄປກັບ (RTT). ສະຖາປັດຕະຍະກໍາຕ້ອງມີ 1 ຜູ້ປະສານງານແລະເຄື່ອງແມ່ຂ່າຍ streaming ຫຼາຍແຈກຢາຍທົ່ວໂລກ: ສະຫະລັດຕາເວັນຕົກ, ສະຫະລັດຕາເວັນອອກ, ເອີຣົບ, ສິງກະໂປ, ຈີນ. ເຊີບເວີສະຕຣີມມິງທັງໝົດຕ້ອງຢູ່ໂດດດ່ຽວຢ່າງສົມບູນ. ລະບົບສາມາດປັບການແຈກຢາຍຂອງມັນເມື່ອເຄື່ອງແມ່ຂ່າຍເຂົ້າຮ່ວມຫຼືອອກຈາກເຄືອຂ່າຍ. ດັ່ງນັ້ນ, ດ້ວຍການຈາລະຈອນຂະຫນາດໃຫຍ່, ການເພີ່ມເຄື່ອງແມ່ຂ່າຍເພີ່ມເຕີມເຮັດໃຫ້ການປັບຂະຫນາດຕາມແນວນອນ.

  4. ຄວາມເຂົ້າກັນໄດ້ຂອງຕົວທ່ອງເວັບ
  ການຫຼິ້ນເກມໃນຄລາວແມ່ນດີທີ່ສຸດເມື່ອມັນຕ້ອງການໜ້ອຍທີ່ສຸດຈາກຜູ້ໃຊ້. ນີ້ຫມາຍຄວາມວ່າມັນເປັນໄປໄດ້ທີ່ຈະດໍາເນີນການໃນຕົວທ່ອງເວັບ. ຕົວທ່ອງເວັບຊ່ວຍເຮັດໃຫ້ປະສົບການການຫຼິ້ນເກມສະດວກສະບາຍເທົ່າທີ່ເປັນໄປໄດ້ສໍາລັບຜູ້ໃຊ້, ຊ່ວຍປະຢັດໃຫ້ເຂົາເຈົ້າຈາກການຕິດຕັ້ງຊອບແວແລະຮາດແວ. ຕົວທ່ອງເວັບຍັງຊ່ວຍສະຫນອງການເຮັດວຽກຂ້າມເວທີລະຫວ່າງສະບັບມືຖືແລະ desktop. ໂຊກດີ, WebRTC ໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ດີໃນທົ່ວຕົວທ່ອງເວັບຕ່າງໆ.

  5. ການ​ແຍກ​ອອກ​ຢ່າງ​ຈະ​ແຈ້ງ​ຂອງ​ການ​ໂຕ້​ຕອບ​ຂອງ​ເກມ​ແລະ​ການ​ບໍ​ລິ​ການ​
  ຂ້ອຍເບິ່ງການບໍລິການເກມຟັງເປັນເວທີ. ທຸກຄົນຄວນຈະສາມາດເຊື່ອມຕໍ່ສິ່ງໃດກັບເວທີ. ໃນປັດຈຸບັນຂ້າພະເຈົ້າໄດ້ປະສົມປະສານ LibRetro ກັບການບໍລິການເກມຟັງເນື່ອງຈາກວ່າ LibRetro ສະຫນອງການໂຕ້ຕອບເກມ emulator ທີ່ສວຍງາມສໍາລັບເກມ retro ເຊັ່ນ SNES, GBA, PS.

  6. ຫ້ອງສໍາລັບ multiplayer, ການຫຼິ້ນຝູງຊົນແລະການເຊື່ອມຕໍ່ພາຍນອກ (deep-link) ກັບເກມ
  CloudRetro ຮອງຮັບການຫຼິ້ນເກມໃໝ່ຫຼາຍຢ່າງເຊັ່ນ CrowdPlay ແລະ Online MultiPlayer ສໍາລັບເກມ retro. ຖ້າຜູ້ໃຊ້ຫຼາຍຄົນເປີດລິ້ງເລິກດຽວກັນຢູ່ໃນຄອມພິວເຕີທີ່ແຕກຕ່າງກັນ, ພວກເຂົາຈະເຫັນເກມແລ່ນດຽວກັນແລະຍັງສາມາດເຂົ້າຮ່ວມມັນໄດ້.

  ຍິ່ງໄປກວ່ານັ້ນ, ລັດເກມຖືກເກັບໄວ້ໃນການເກັບຮັກສາຟັງ. ນີ້ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດສືບຕໍ່ຫຼິ້ນໄດ້ທຸກເວລາໃນອຸປະກອນອື່ນ.

  7. ການປັບຂະຫນາດຕາມແນວນອນ
  ເຊັ່ນດຽວກັບ SAAS ທຸກມື້ນີ້, ການຫຼິ້ນເກມຄລາວຕ້ອງຖືກອອກແບບເພື່ອໃຫ້ສາມາດຂະຫຍາຍໄດ້ຕາມລວງນອນ. ການອອກແບບຜູ້ປະສານງານ - ພະນັກງານຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມຄົນງານຫຼາຍຂຶ້ນເພື່ອຮັບໃຊ້ການຈະລາຈອນຫຼາຍ.

  8. ບໍ່ມີການເຊື່ອມຕໍ່ກັບເມຄດຽວ
  ໂຄງສ້າງພື້ນຖານຂອງ CloudRetro ແມ່ນໂຮດຢູ່ໃນຜູ້ໃຫ້ບໍລິການຄລາວທີ່ແຕກຕ່າງກັນ (Digital Ocean, Alibaba, custom provider) ສໍາລັບພາກພື້ນຕ່າງໆ. ຂ້ອຍເປີດໃຊ້ງານໃນ Docker container ສໍາລັບໂຄງສ້າງພື້ນຖານແລະກໍານົດການຕັ້ງຄ່າເຄືອຂ່າຍໂດຍໃຊ້ bash script ເພື່ອຫຼີກເວັ້ນການຖືກລັອກຢູ່ໃນຜູ້ໃຫ້ບໍລິການຟັງດຽວ. ໂດຍການສົມທົບອັນນີ້ກັບ NAT Traversal ໃນ WebRTC, ພວກເຮົາສາມາດມີຄວາມຍືດຫຍຸ່ນໃນການນຳໃຊ້ CloudRetro ໃນທຸກເວທີຄລາວ ແລະແມ້ແຕ່ຢູ່ໃນເຄື່ອງຂອງຜູ້ໃຊ້ໃດໆກໍຕາມ.

  ການອອກແບບສະຖາປັດຕະຍະກໍາ

  ຄົນງານ: (ຫຼືເຊີບເວີການຖ່າຍທອດທີ່ໄດ້ກ່າວມາຂ້າງເທິງ) ທະວີຄູນເກມ, ແລ່ນທໍ່ການເຂົ້າລະຫັດ, ແລະຖ່າຍທອດສື່ທີ່ເຂົ້າລະຫັດໃຫ້ກັບຜູ້ໃຊ້. ຕົວ ຢ່າງ ຂອງ ຄົນ ເຮັດ ວຽກ ແມ່ນ ໄດ້ ຖືກ ແຈກ ຢາຍ ໃນ ທົ່ວ ໂລກ, ແລະ ພະ ນັກ ງານ ແຕ່ ລະ ຄົນ ສາ ມາດ ຈັດ ການ ກອງ ປະ ຊຸມ ຜູ້ ໃຊ້ ຫຼາຍ ຄົນ ພ້ອມໆ ກັນ.

  ຜູ້ປະສານງານ: ຮັບຜິດຊອບສໍາລັບການຈັບຄູ່ຜູ້ໃຊ້ໃຫມ່ກັບພະນັກງານທີ່ເຫມາະສົມທີ່ສຸດສໍາລັບການຖ່າຍທອດ. ຜູ້ປະສານງານພົວພັນກັບພະນັກງານຜ່ານ WebSocket.

  ພື້ນທີ່ເກັບຂໍ້ມູນເກມ: ພື້ນທີ່ຈັດເກັບຂໍ້ມູນທາງໄກສູນກາງສຳລັບທຸກສະຖານະເກມ. ການເກັບຮັກສານີ້ສະຫນອງຫນ້າທີ່ທີ່ສໍາຄັນເຊັ່ນການປະຫຍັດ / ການໂຫຼດຈາກໄລຍະໄກ.

  
  ສະຖາປັດຕະຍະກໍາລະດັບສູງສຸດຂອງ CloudRetro

  Custom Script

  ເມື່ອຜູ້ໃຊ້ໃຫມ່ເປີດ CloudRetro ໃນຂັ້ນຕອນ 1 ແລະ 2 ທີ່ສະແດງຢູ່ໃນຮູບຂ້າງລຸ່ມນີ້, ຜູ້ປະສານງານພ້ອມກັບບັນຊີລາຍຊື່ຂອງພະນັກງານທີ່ມີຢູ່ແມ່ນຮ້ອງຂໍໃຫ້ຫນ້າທໍາອິດ. ຫຼັງຈາກນີ້, ໃນຂັ້ນຕອນທີ 3 ລູກຄ້າຄິດໄລ່ຄວາມລ່າຊ້າສໍາລັບຜູ້ສະຫມັກທັງຫມົດໂດຍໃຊ້ຄໍາຮ້ອງຂໍ HTTP ping. ຫຼັງຈາກນັ້ນ, ບັນຊີລາຍຊື່ຂອງການຊັກຊ້ານີ້ຖືກສົ່ງໄປຫາຜູ້ປະສານງານເພື່ອໃຫ້ລາວສາມາດກໍານົດພະນັກງານທີ່ເຫມາະສົມທີ່ສຸດເພື່ອຮັບໃຊ້ຜູ້ໃຊ້. ຂັ້ນ​ຕອນ​ທີ 4 ຂ້າງ​ລຸ່ມ​ນີ້​ສ້າງ​ເກມ​. ການ​ເຊື່ອມ​ຕໍ່​ສະ​ຕ​ຣີມ WebRTC ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ລະ​ຫວ່າງ​ຜູ້​ໃຊ້​ແລະ​ພະ​ນັກ​ງານ​ທີ່​ໄດ້​ຮັບ​ມອບ​ຫມາຍ.
  
  script ຜູ້ໃຊ້ຫຼັງຈາກການເຂົ້າເຖິງ

  ແມ່ນຫຍັງຢູ່ພາຍໃນຄົນງານ

  ເກມ ແລະທໍ່ຖ່າຍທອດຖືກເກັບໄວ້ພາຍໃນຄົນງານໃນການໂດດດ່ຽວ ແລະແລກປ່ຽນຂໍ້ມູນຢູ່ທີ່ນັ້ນໂດຍຜ່ານການໂຕ້ຕອບ. ໃນປັດຈຸບັນ, ການສື່ສານນີ້ແມ່ນປະຕິບັດໂດຍການໂອນຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາຜ່ານ ຊ່ອງ Golang ໃນຂະບວນການດຽວກັນ. ເປົ້າຫມາຍຕໍ່ໄປແມ່ນການແບ່ງແຍກ, i.e. ການເປີດຕົວເອກະລາດຂອງເກມໃນຂະບວນການອື່ນ.

  
  ການໂຕ້ຕອບຂອງອົງປະກອບຂອງພະນັກງານ

  ອົງ​ປະ​ກອບ​ຕົ້ນ​ຕໍ​:

  • WebRTC: ອົງປະກອບລູກຂ່າຍທີ່ຍອມຮັບການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ ແລະອອກສື່ທີ່ເຂົ້າລະຫັດຈາກເຊີບເວີ.
  • ຕົວຈຳລອງເກມ: ອົງປະກອບເກມ. ຂໍຂອບໃຈກັບຫ້ອງສະຫມຸດ Libretro, ລະບົບສາມາດດໍາເນີນການເກມພາຍໃນຂະບວນການດຽວກັນແລະພາຍໃນ intercept media ແລະ input stream.
  • ເຟຣມໃນເກມຖືກຈັບ ແລະສົ່ງໄປຫາຕົວເຂົ້າລະຫັດ.
  • ຕົວເຂົ້າລະຫັດຮູບພາບ/ສຽງ: ທໍ່ການເຂົ້າລະຫັດທີ່ເອົາກອບສື່, ເຂົ້າລະຫັດພວກມັນໃນພື້ນຫຼັງ, ແລະສົ່ງຜົນອອກມາຈາກຮູບພາບ/ສຽງທີ່ເຂົ້າລະຫັດ.

  Реализация

  CloudRetro ອີງໃສ່ WebRTC ເປັນເຕັກໂນໂລຢີກະດູກສັນຫຼັງ, ດັ່ງນັ້ນກ່ອນທີ່ຈະເຂົ້າໄປໃນລາຍລະອຽດຂອງການປະຕິບັດ Golang, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈເວົ້າກ່ຽວກັບ WebRTC ຕົວຂອງມັນເອງ. ນີ້ແມ່ນເທັກໂນໂລຍີທີ່ໜ້າຕື່ນຕາຕື່ນໃຈທີ່ໄດ້ຊ່ວຍຂ້ອຍຢ່າງໃຫຍ່ຫຼວງໃນການບັນລຸເວລາ latency ທີສອງສຳລັບການຖ່າຍທອດຂໍ້ມູນ.

  WebRTC

  WebRTC ຖືກອອກແບບມາເພື່ອສະໜອງການເຊື່ອມຕໍ່ peer-to-peer ທີ່ມີຄຸນນະພາບສູງໃນແອັບຯມືຖື ແລະຕົວທ່ອງເວັບພື້ນເມືອງໂດຍໃຊ້ APIs ງ່າຍໆ.

  ເສັ້ນທາງຜ່ານ NAT

  WebRTC ແມ່ນເປັນທີ່ຮູ້ຈັກສໍາລັບການເຮັດວຽກ NAT Traversal ຂອງມັນ. WebRTC ຖືກອອກແບບມາສໍາລັບການສື່ສານແບບ peer-to-peer. ເປົ້າຫມາຍຂອງມັນແມ່ນເພື່ອຊອກຫາເສັ້ນທາງກົງທີ່ເຫມາະສົມທີ່ສຸດ, ຫຼີກເວັ້ນການ NAT gateways ແລະ firewalls ສໍາລັບການສື່ສານ peer-to-peer ຜ່ານຂະບວນການທີ່ເອີ້ນວ່າ ICE. ເປັນສ່ວນຫນຶ່ງຂອງຂະບວນການນີ້, WebRTC APIs ຊອກຫາທີ່ຢູ່ IP ສາທາລະນະຂອງທ່ານໂດຍໃຊ້ເຄື່ອງແມ່ຂ່າຍ STUN ແລະສົ່ງຕໍ່ໄປຫາເຄື່ອງແມ່ຂ່າຍ relay (ຫັນ) ເມື່ອການເຊື່ອມຕໍ່ໂດຍກົງບໍ່ສາມາດຖືກສ້າງຕັ້ງຂຶ້ນ.

  ຢ່າງໃດກໍຕາມ, CloudRetro ບໍ່ໄດ້ໃຊ້ຄຸນສົມບັດນີ້ຢ່າງເຕັມສ່ວນ. ການເຊື່ອມຕໍ່ peer-to-peer ຂອງມັນບໍ່ມີລະຫວ່າງຜູ້ໃຊ້, ແຕ່ລະຫວ່າງຜູ້ໃຊ້ແລະເຄື່ອງແມ່ຂ່າຍຟັງ. ດ້ານເຊີບເວີຂອງແບບຈໍາລອງມີຂໍ້ຈໍາກັດການສື່ສານໂດຍກົງຫນ້ອຍກວ່າອຸປະກອນຂອງຜູ້ໃຊ້ທົ່ວໄປ. ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເປີດພອດຂາເຂົ້າລ່ວງຫນ້າຫຼືໃຊ້ທີ່ຢູ່ IP ສາທາລະນະໂດຍກົງ, ເພາະວ່າເຄື່ອງແມ່ຂ່າຍບໍ່ຢູ່ຫລັງ NAT.

  ກ່ອນຫນ້ານີ້, ຂ້າພະເຈົ້າຕ້ອງການປ່ຽນໂຄງການເປັນເວທີການແຈກຢາຍເກມສໍາລັບ Cloud Gaming. ແນວຄວາມຄິດແມ່ນເພື່ອອະນຸຍາດໃຫ້ຜູ້ສ້າງເກມສະຫນອງເກມແລະຊັບພະຍາກອນການຖ່າຍທອດ. ແລະຜູ້ໃຊ້ຈະພົວພັນກັບຜູ້ໃຫ້ບໍລິການໂດຍກົງ. ໃນລັກສະນະການແບ່ງຂັ້ນຄຸ້ມຄອງນີ້, CloudRetro ແມ່ນພຽງແຕ່ກອບສໍາລັບການເຊື່ອມຕໍ່ຊັບພະຍາກອນນ້ໍາຂອງພາກສ່ວນທີສາມກັບຜູ້ໃຊ້, ເຮັດໃຫ້ມັນສາມາດຂະຫຍາຍໄດ້ຫຼາຍເມື່ອມັນບໍ່ໄດ້ຖືກໂຮດອີກຕໍ່ໄປ. ບົດບາດຂອງ WebRTC NAT Traversal ໃນທີ່ນີ້ແມ່ນມີຄວາມສໍາຄັນຫຼາຍເພື່ອອໍານວຍຄວາມສະດວກໃນການເຊື່ອມຕໍ່ peer-to-peer ໃນເບື້ອງຕົ້ນກ່ຽວກັບຊັບພະຍາກອນນ້ໍາຂອງພາກສ່ວນທີສາມ, ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບຜູ້ສ້າງເພື່ອເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍ.

  ການບີບອັດວິດີໂອ

  ການບີບອັດວິດີໂອແມ່ນສ່ວນຫນຶ່ງທີ່ຂາດບໍ່ໄດ້ຂອງທໍ່ແລະປະກອບສ່ວນຢ່າງຫຼວງຫຼາຍຕໍ່ການໄຫຼທີ່ລຽບງ່າຍ. ໃນຂະນະທີ່ມັນບໍ່ຈໍາເປັນທີ່ຈະຮູ້ທຸກລາຍລະອຽດຂອງການເຂົ້າລະຫັດວິດີໂອ VP8/H264, ການເຂົ້າໃຈແນວຄວາມຄິດສາມາດຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈຕົວເລືອກຄວາມໄວໃນການຖ່າຍທອດວິດີໂອ, ແກ້ບັນຫາພຶດຕິກໍາທີ່ບໍ່ຄາດຄິດ, ແລະປັບເວລາ latency.

  ການບີບອັດວິດີໂອສໍາລັບການບໍລິການສະຕີມແມ່ນເປັນສິ່ງທ້າທາຍເພາະວ່າສູດການຄິດໄລ່ຕ້ອງຮັບປະກັນວ່າເວລາເຂົ້າລະຫັດທັງຫມົດ + ເວລາສົ່ງຜ່ານເຄືອຂ່າຍ + ເວລາການຖອດລະຫັດແມ່ນຕໍ່າທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້. ນອກຈາກນັ້ນ, ຂະບວນການເຂົ້າລະຫັດຕ້ອງສອດຄ່ອງແລະຢ່າງຕໍ່ເນື່ອງ. ການແລກປ່ຽນການເຂົ້າລະຫັດບາງຢ່າງບໍ່ຖືກນຳໃຊ້—ຕົວຢ່າງ: ພວກເຮົາບໍ່ສາມາດຮອງຮັບເວລາການເຂົ້າລະຫັດທີ່ຍາວນານຕໍ່ກັບຂະໜາດໄຟລ໌ທີ່ນ້ອຍກວ່າ ແລະເວລາການຖອດລະຫັດ, ຫຼືໃຊ້ການບີບອັດທີ່ບໍ່ສອດຄ່ອງກັນ.

  ແນວຄວາມຄິດທີ່ຢູ່ເບື້ອງຫລັງການບີບອັດວິດີໂອແມ່ນເພື່ອລົບລ້າງຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນໃນຂະນະທີ່ຮັກສາລະດັບຄວາມຖືກຕ້ອງທີ່ຍອມຮັບໄດ້ສໍາລັບຜູ້ໃຊ້. ນອກເຫນືອຈາກການເຂົ້າລະຫັດເຟຣມຮູບພາບຄົງທີ່ຂອງແຕ່ລະບຸກຄົນ, ສູດການຄິດໄລ່ infers ກອບປະຈຸບັນຈາກທີ່ຜ່ານມາແລະຕໍ່ໄປ, ດັ່ງນັ້ນພຽງແຕ່ຄວາມແຕກຕ່າງຂອງພວກມັນຖືກສົ່ງ. ດັ່ງທີ່ສາມາດເຫັນໄດ້ຈາກຕົວຢ່າງກັບ Pacman, ພຽງແຕ່ຈຸດທີ່ແຕກຕ່າງກັນຖືກສົ່ງຕໍ່.

  
  ການປຽບທຽບກອບວິດີໂອທີ່ໃຊ້ Pacman ເປັນຕົວຢ່າງ

  ການບີບອັດສຽງ

  ເຊັ່ນດຽວກັນ, ຂັ້ນຕອນການບີບອັດສຽງຈະຍົກເລີກຂໍ້ມູນທີ່ມະນຸດບໍ່ສາມາດຮັບຮູ້ໄດ້. Opus ປະຈຸບັນແມ່ນຕົວແປງສັນຍານສຽງທີ່ມີປະສິດຕິພາບດີທີ່ສຸດ. ມັນຖືກອອກແບບມາເພື່ອສົ່ງຄື້ນສຽງຜ່ານໂປຣໂຕຄອນ datagram ທີ່ສັ່ງເຊັ່ນ RTP (Real Time Transport Protocol). latency ຂອງມັນຕໍ່າກວ່າ mp3 ແລະ aac, ແລະຄຸນນະພາບສູງກວ່າ. latency ປົກກະຕິແລ້ວແມ່ນປະມານ 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 Channels ໃນການປະຕິບັດ

  ຂໍຂອບໃຈກັບການອອກແບບຊ່ອງທີ່ສວຍງາມຂອງ Go, ບັນຫາຂອງການຖ່າຍທອດເຫດການ ແລະຄວາມສອດຄ່ອງແມ່ນງ່າຍດາຍຫຼາຍ. ເຊັ່ນດຽວກັບຢູ່ໃນແຜນວາດ, GoRoutines ທີ່ແຕກຕ່າງກັນມີຫຼາຍອົງປະກອບທີ່ເຮັດວຽກຂະຫນານ. ແຕ່ລະອົງປະກອບຄຸ້ມຄອງລັດຂອງຕົນແລະຕິດຕໍ່ສື່ສານຜ່ານຊ່ອງທາງຕ່າງໆ. ການຢືນຢັນການເລືອກຂອງ Golang ບັງຄັບໃຫ້ເຫດການປະລໍາມະນູອັນໜຶ່ງຖືກປະມວນຜົນທຸກຄັ້ງໃນເກມ (ໝາຍຕິກເກມ). ນີ້ຫມາຍຄວາມວ່າບໍ່ຈໍາເປັນຕ້ອງມີການລັອກສໍາລັບການອອກແບບນີ້. ຕົວຢ່າງ, ເມື່ອຜູ້ໃຊ້ບັນທຶກ, ຮູບພາບເຕັມຂອງສະຖານະເກມແມ່ນຕ້ອງການ. ສະຖານະນີ້ຄວນຈະສືບຕໍ່ຢ່າງຕໍ່ເນື່ອງ, ເຂົ້າສູ່ລະບົບຈົນກ່ວາບັນທຶກສໍາເລັດ. ໃນລະຫວ່າງແຕ່ລະໝາຍຕິກເກມ, backend ພຽງແຕ່ສາມາດຈັດການບັນທຶກ ຫຼືການປ້ອນຂໍ້ມູນ, ເຮັດໃຫ້ກະທູ້ຂອງຂະບວນການປອດໄພ.

  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 ຂອງຂ້ອຍຢ່າງສົມບູນແບບ. ປະຕິບັດຕາມຮູບແບບນີ້, ວັດສະດຸປ້ອນຂອງຜູ້ໃຊ້ທັງຫມົດຢູ່ໃນຫ້ອງດຽວແມ່ນຖືກສ້າງຂຶ້ນໃນຊ່ອງທາງເຂົ້າກາງ. ຫຼັງຈາກນັ້ນ, ມີເດຍເກມຖືກນຳໃຊ້ໃຫ້ກັບຜູ້ໃຊ້ທັງໝົດຢູ່ໃນຫ້ອງດຽວກັນ. ດ້ວຍວິທີນີ້, ພວກເຮົາບັນລຸການແບ່ງສ່ວນຂອງລັດເກມລະຫວ່າງເກມຫຼາຍໆຄັ້ງຂອງຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນ.

  
  synchronization ລະຫວ່າງກອງປະຊຸມທີ່ແຕກຕ່າງກັນ

  ຂໍ້ເສຍຂອງ Golang

  Golang ບໍ່ສົມບູນແບບ. ຊ່ອງແມ່ນຊ້າ. ເມື່ອປຽບທຽບກັບການປິດກັ້ນ, ຊ່ອງທາງ Go ແມ່ນພຽງແຕ່ວິທີທີ່ງ່າຍກວ່າທີ່ຈະຈັດການກັບເຫດການທີ່ກົງກັນແລະເປັນກະທູ້, ແຕ່ຊ່ອງທາງບໍ່ໄດ້ສະຫນອງການປະຕິບັດທີ່ດີທີ່ສຸດ. ມີເຫດຜົນທາງຕັນທີ່ຊັບຊ້ອນຢູ່ໃຕ້ຊ່ອງ. ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ເຮັດການປັບຕົວບາງຢ່າງໃນການປະຕິບັດ, ນໍາໃຊ້ໃຫມ່ locks ແລະຄ່າປະລໍາມະນູໃນເວລາທີ່ປ່ຽນຊ່ອງທາງເພື່ອເພີ່ມປະສິດທິພາບການປະຕິບັດ.

  ນອກຈາກນັ້ນ, ຜູ້ເກັບຂີ້ເຫຍື້ອໃນ Golang ແມ່ນບໍ່ສາມາດຈັດການໄດ້, ເຊິ່ງບາງຄັ້ງກໍ່ເຮັດໃຫ້ເກີດການຢຸດຊົ່ວຄາວທີ່ຫນ້າສົງໄສ. ອັນນີ້ແຊກແຊງຢ່າງໃຫຍ່ຫຼວງກັບແອັບພລິເຄຊັນການຖ່າຍທອດແບບສົດໆ.

  COG

  ໂຄງການດັ່ງກ່າວໃຊ້ຫ້ອງສະໝຸດ Golang VP8/H264 ແຫຼ່ງເປີດທີ່ມີຢູ່ແລ້ວສຳລັບການບີບອັດສື່ ແລະ Libretro ສຳລັບຕົວຈຳລອງເກມ. ຫ້ອງສະຫມຸດທັງຫມົດເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ຫໍ່ຂອງຫ້ອງສະຫມຸດ C ໃນ Go ໂດຍໃຊ້ COG. ບາງຂໍ້ເສຍແມ່ນໄດ້ລະບຸໄວ້ໃນ ຕອບນີ້ໂດຍ Dave Cheney. ບັນຫາທີ່ຂ້ອຍພົບ:

  • ຄວາມບໍ່ສາມາດທີ່ຈະຈັບອຸປະຕິເຫດໃນ CGO, ເຖິງແມ່ນວ່າມີ Golang RecoveryCrash;
  • ຄວາມລົ້ມເຫຼວທີ່ຈະກໍານົດຂໍ້ບົກພ່ອງດ້ານການປະຕິບັດໃນເວລາທີ່ພວກເຮົາບໍ່ສາມາດກວດພົບບັນຫາລາຍລະອຽດໃນ CGO.

  ສະຫລຸບ

  ຂ້າພະເຈົ້າໄດ້ບັນລຸເປົ້າຫມາຍຂອງຂ້າພະເຈົ້າໃນການເຂົ້າໃຈການບໍລິການເກມຟັງແລະສ້າງເວທີທີ່ຊ່ວຍໃຫ້ຂ້າພະເຈົ້າຫຼິ້ນເກມ retro nostalgic ກັບຫມູ່ເພື່ອນຂອງຂ້າພະເຈົ້າອອນໄລນ໌. ໂຄງ​ການ​ນີ້​ຈະ​ເປັນ​ໄປ​ບໍ່​ໄດ້​ຖ້າ​ບໍ່​ມີ​ຫ້ອງ​ສະ​ຫມຸດ Pion ແລະ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ຂອງ​ຊຸມ​ຊົນ Pion​. ຂ້າ​ພະ​ເຈົ້າ​ມີ​ຄວາມ​ກະ​ຕັນ​ຍູ​ທີ່​ສຸດ​ສໍາ​ລັບ​ການ​ພັດ​ທະ​ນາ​ຢ່າງ​ເຂັ້ມ​ແຂງ​ຂອງ​ຕົນ​. APIs ງ່າຍໆທີ່ສະໜອງໃຫ້ໂດຍ WebRTC ແລະ Pion ຮັບປະກັນການເຊື່ອມໂຍງແບບບໍ່ຕິດຂັດ. ຫຼັກຖານສະແດງແນວຄວາມຄິດທໍາອິດຂອງຂ້ອຍໄດ້ຖືກປ່ອຍອອກມາໃນອາທິດດຽວກັນ, ເຖິງແມ່ນວ່າຂ້ອຍບໍ່ມີຄວາມຮູ້ກ່ຽວກັບການສື່ສານແບບ peer-to-peer (P2P).

  ເຖິງວ່າຈະມີຄວາມງ່າຍດາຍຂອງການເຊື່ອມໂຍງ, P2P streaming ຢ່າງແທ້ຈິງແມ່ນພື້ນທີ່ສະລັບສັບຊ້ອນຫຼາຍໃນວິທະຍາສາດຄອມພິວເຕີ. ນາງຕ້ອງຈັດການກັບຄວາມສັບສົນຂອງສະຖາປັດຕະຍະກໍາເຄືອຂ່າຍທີ່ຍາວນານເຊັ່ນ IP ແລະ NAT ເພື່ອສ້າງກອງປະຊຸມ peer-to-peer. ໃນຂະນະທີ່ເຮັດວຽກໃນໂຄງການນີ້, ຂ້າພະເຈົ້າໄດ້ຮັບຄວາມຮູ້ທີ່ມີຄຸນຄ່າຫຼາຍກ່ຽວກັບເຄືອຂ່າຍແລະການເພີ່ມປະສິດທິພາບການປະຕິບັດ, ດັ່ງນັ້ນຂ້າພະເຈົ້າຊຸກຍູ້ໃຫ້ທຸກຄົນພະຍາຍາມສ້າງຜະລິດຕະພັນ P2P ໂດຍໃຊ້ WebRTC.

  CloudRetro ຕອບສະໜອງໄດ້ທຸກກໍລະນີການນຳໃຊ້ທີ່ຂ້ອຍຄາດໄວ້ຈາກທັດສະນະຂອງຂ້ອຍໃນຖານະນັກຫຼິ້ນເກມຍຸກຍຸກ. ແນວໃດກໍ່ຕາມ, ຂ້າພະເຈົ້າຄິດວ່າມີຫຼາຍຂົງເຂດໃນໂຄງການທີ່ຂ້ອຍສາມາດປັບປຸງໄດ້, ເຊັ່ນວ່າເຮັດໃຫ້ເຄືອຂ່າຍມີຄວາມໜ້າເຊື່ອຖື ແລະ ມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ສະໜອງກາຟິກເກມທີ່ມີຄຸນນະພາບສູງຂຶ້ນ ຫຼື ຄວາມສາມາດໃນການແບ່ງປັນເກມລະຫວ່າງຜູ້ໃຊ້. ຂ້ອຍກໍາລັງເຮັດວຽກຫນັກໃນເລື່ອງນີ້. ກະລຸນາປະຕິບັດຕາມ ໂຄງການ ແລະສະຫນັບສະຫນູນມັນຖ້າທ່ານມັກມັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com