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

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

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

ເຖິງແມ່ນວ່າສະຖາປັດຕະຍະກໍາ peer-to-peer ຍັງຖືກນໍາໃຊ້ໃນບາງເກມ, client-server ແມ່ນມາດຕະຖານ: ມັນງ່າຍຕໍ່ການປະຕິບັດ, ຕ້ອງການຄວາມກວ້າງຂອງຊ່ອງທາງນ້ອຍກວ່າ, ແລະເຮັດໃຫ້ມັນງ່າຍຕໍ່ການປ້ອງກັນການໂກງ. ດັ່ງນັ້ນ, ໃນບົດສອນນີ້ພວກເຮົາຈະສຸມໃສ່ສະຖາປັດຕະຍະກໍາລູກຄ້າ - ເຄື່ອງແມ່ຂ່າຍ.

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

ລະບົບເກມເຄືອຂ່າຍມີສາມອົງປະກອບຕົ້ນຕໍ:

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

ມັນເປັນສິ່ງ ສຳ ຄັນຫຼາຍທີ່ຈະເຂົ້າໃຈບົດບາດຂອງແຕ່ລະພາກສ່ວນແລະສິ່ງທ້າທາຍທີ່ກ່ຽວຂ້ອງກັບພວກມັນ.

ອະນຸສັນຍາການຂົນສົ່ງ

ຂັ້ນຕອນທໍາອິດແມ່ນເລືອກໂປໂຕຄອນສໍາລັບການຂົນສົ່ງຂໍ້ມູນລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າ. ມີສອງໂປໂຕຄອນອິນເຕີເນັດສໍາລັບການນີ້: TCP и UDP. ແຕ່ທ່ານສາມາດສ້າງໂປໂຕຄອນການຂົນສົ່ງຂອງທ່ານເອງໂດຍອີງໃສ່ຫນຶ່ງຂອງພວກເຂົາຫຼືໃຊ້ຫ້ອງສະຫມຸດທີ່ໃຊ້ພວກມັນ.

ການປຽບທຽບ TCP ແລະ UDP

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

UDP ແມ່ນພຽງແຕ່ຊັ້ນບາງໆຢູ່ເທິງ IP. ດັ່ງນັ້ນ, ມັນມີຂໍ້ຈໍາກັດດຽວກັນ. ໃນທາງກົງກັນຂ້າມ, TCP ມີຫຼາຍລັກສະນະ. ມັນສະຫນອງການເຊື່ອມຕໍ່ທີ່ເຊື່ອຖືໄດ້, ເປັນລະບຽບລະຫວ່າງສອງ nodes ກັບການກວດສອບຄວາມຜິດພາດ. ເພາະສະນັ້ນ, TCP ແມ່ນສະດວກຫຼາຍແລະຖືກນໍາໃຊ້ໃນຫຼາຍໂປໂຕຄອນອື່ນໆ, e.g. HTTP, FTP и SMTP. ແຕ່ລັກສະນະເຫຼົ່ານີ້ທັງຫມົດມາໃນລາຄາ: ຊັກຊ້າ.

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

ແຕ່ຕາມທີ່ເຈົ້າອາດຈະຈິນຕະນາການໄດ້, ຄວາມແຝງຢູ່ໃນເກມທີ່ມີຜູ້ຫຼິ້ນຫຼາຍຄົນມີຄວາມສຳຄັນຫຼາຍ, ໂດຍສະເພາະໃນປະເພດການກະທຳເຊັ່ນ FPS. ນີ້ແມ່ນເຫດຜົນທີ່ເກມຈໍານວນຫຼາຍໃຊ້ UDP ກັບໂປໂຕຄອນຂອງຕົນເອງ.

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

ດັ່ງນັ້ນ, ຖ້າ TCP ດູດຫຼາຍ, ພວກເຮົາຈະສ້າງໂປໂຕຄອນການຂົນສົ່ງຂອງພວກເຮົາໂດຍອີງໃສ່ UDP?

ມັນສັບສົນເລັກນ້ອຍ. ເຖິງແມ່ນວ່າ TCP ແມ່ນເກືອບດີທີ່ສຸດສໍາລັບລະບົບເຄືອຂ່າຍເກມ, ມັນສາມາດເຮັດວຽກໄດ້ດີສໍາລັບເກມສະເພາະຂອງທ່ານແລະປະຫຍັດເວລາທີ່ມີຄຸນຄ່າ. ຕົວຢ່າງ, ເວລາ latency ອາດຈະບໍ່ເປັນບັນຫາສໍາລັບເກມ turn-based ຫຼືເກມທີ່ສາມາດຫຼິ້ນໄດ້ພຽງແຕ່ໃນເຄືອຂ່າຍ LAN, ບ່ອນທີ່ latency ແລະການສູນເສຍແພັກເກັດແມ່ນຕ່ໍາກວ່າໃນອິນເຕີເນັດ.

ເກມທີ່ປະສົບຜົນສໍາເລັດຫຼາຍຢ່າງ, ລວມທັງ World of Warcraft, Minecraft ແລະ Terraria, ໃຊ້ TCP. ຢ່າງໃດກໍຕາມ, FPS ສ່ວນໃຫຍ່ໃຊ້ໂປໂຕຄອນທີ່ອີງໃສ່ UDP ຂອງຕົນເອງ, ດັ່ງນັ້ນພວກເຮົາຈະສົນທະນາເພີ່ມເຕີມກ່ຽວກັບພວກມັນຂ້າງລຸ່ມນີ້.

ຖ້າທ່ານຕັດສິນໃຈໃຊ້ TCP, ໃຫ້ແນ່ໃຈວ່າມັນຖືກປິດໃຊ້ງານ ສູດການຄິດໄລ່ຂອງ Nagle, ເນື່ອງຈາກວ່າມັນ buffers packets ກ່ອນທີ່ຈະສົ່ງ, ຊຶ່ງຫມາຍຄວາມວ່າມັນເພີ່ມທະວີການ latency.

ເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຄວາມແຕກຕ່າງລະຫວ່າງ UDP ແລະ TCP ໃນບໍລິບົດຂອງເກມຫຼາຍຜູ້ນ, ທ່ານສາມາດອ່ານບົດຄວາມຂອງ Glenn Fiedler. UDP ທຽບກັບ. TCP.

ພິທີການຂອງຕົນເອງ

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

ບົດຄວາມທໍາອິດ ເຄືອຂ່າຍສໍາລັບນັກຂຽນໂປລແກລມເກມ ປີ 2008, ງ່າຍ​ກວ່າ​ຄັ້ງ​ທີ​ສອງ​, ການສ້າງອະນຸສັນຍາເຄືອຂ່າຍເກມ 2016. ຂ້ອຍຂໍແນະນໍາໃຫ້ເຈົ້າເລີ່ມຕົ້ນດ້ວຍຕົວເກົ່າ.

ໃຫ້ສັງເກດວ່າ Glenn Fiedler ເປັນຜູ້ສະຫນັບສະຫນູນໃຫຍ່ຂອງການນໍາໃຊ້ໂປໂຕຄອນທີ່ກໍາຫນົດເອງໂດຍອີງໃສ່ UDP. ແລະຫຼັງຈາກອ່ານບົດຄວາມຂອງລາວ, ທ່ານອາດຈະຮັບຮອງເອົາຄວາມຄິດເຫັນຂອງລາວວ່າ TCP ມີຂໍ້ບົກຜ່ອງທີ່ຮ້າຍແຮງຢູ່ໃນວີດີໂອເກມ, ແລະເຈົ້າຈະຕ້ອງປະຕິບັດໂປໂຕຄອນຂອງຕົນເອງ.

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

ຫ້ອງສະຫມຸດເຄືອຂ່າຍ

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

• ໂຢຈິມໂບ Glenn Fiedler
• ຣັກເນັດ, ເຊິ່ງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນອີກຕໍ່ໄປ, ແຕ່ມີສ້ອມຂອງມັນ SLikeNet ເບິ່ງຄືວ່າມັນຍັງເຄື່ອນໄຫວຢູ່.
• ອີເນັດ ເປັນຫ້ອງສະຫມຸດທີ່ສ້າງຂຶ້ນສໍາລັບ multiplayer FPS Cube
• GameNetworkingSockets ວາວ

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ພະ​ຍາ​ຍາມ​ທັງ​ຫມົດ​, ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ມັກ ENet ເພາະ​ວ່າ​ມັນ​ເປັນ​ການ​ງ່າຍ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ແລະ​ເຊື່ອ​ຖື​ໄດ້​. ນອກຈາກນັ້ນ, ມັນມີເອກະສານທີ່ຊັດເຈນແລະ tutorial ສໍາລັບຜູ້ເລີ່ມຕົ້ນ.

ພິທີການການຂົນສົ່ງ: ສະຫຼຸບ

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

ທາງເລືອກລະຫວ່າງ TCP, UDP ແລະຫ້ອງສະຫມຸດແມ່ນຂຶ້ນກັບປັດໃຈຈໍານວນຫນຶ່ງ. ຫນ້າທໍາອິດ, ຈາກຄວາມຕ້ອງການຂອງເກມ: ມັນຕ້ອງການ latency ຕ່ໍາບໍ? ອັນທີສອງ, ຈາກຂໍ້ກໍານົດຂອງໂປໂຕຄອນຄໍາຮ້ອງສະຫມັກ: ມັນຕ້ອງການໂປໂຕຄອນທີ່ເຊື່ອຖືໄດ້ບໍ? ດັ່ງທີ່ພວກເຮົາຈະເຫັນໃນສ່ວນຕໍ່ໄປ, ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງໂປໂຕຄອນຄໍາຮ້ອງສະຫມັກທີ່ໂປໂຕຄອນທີ່ບໍ່ຫນ້າເຊື່ອຖືແມ່ນຂ້ອນຂ້າງເຫມາະສົມ. ສຸດທ້າຍ, ທ່ານຍັງຈໍາເປັນຕ້ອງຄໍານຶງເຖິງປະສົບການຂອງຜູ້ພັດທະນາເຄື່ອງຈັກເຄືອຂ່າຍ.

ຂ້ອຍມີຄໍາແນະນໍາສອງຢ່າງ:

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

ໃນຕອນທ້າຍຂອງພາກນີ້, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານ ແນະນຳການຕັ້ງໂປຣແກຣມເກມຫຼາຍຄົນ ໂດຍ Brian Hook, ເຊິ່ງກວມເອົາຫຼາຍຫົວຂໍ້ທີ່ສົນທະນາຢູ່ທີ່ນີ້.

ໂປຣໂຕຄໍແອັບພລິເຄຊັນ

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

ຮູບແບບຄລາສສິກແມ່ນວ່າລູກຄ້າສົ່ງຂໍ້ມູນຫຼືການປະຕິບັດໄປຫາເຄື່ອງແມ່ຂ່າຍ, ແລະເຄື່ອງແມ່ຂ່າຍຈະສົ່ງສະຖານະເກມໃນປະຈຸບັນໃຫ້ກັບລູກຄ້າ.

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

ການຈັດລໍາດັບ

ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ແມ່ນ​ການ​ປ່ຽນ​ຂໍ້​ມູນ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ສົ່ງ (ການ​ປ້ອນ​ຂໍ້​ມູນ​ຫຼື​ສະ​ພາບ​ເກມ​) ເປັນ​ຮູບ​ແບບ​ທີ່​ເຫມາະ​ສົມ​ສໍາ​ລັບ​ການ​ສົ່ງ​. ຂະບວນການນີ້ເອີ້ນວ່າ ລໍາດັບ.

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

ມັນແນະນໍາໃຫ້ໃຊ້ຮູບແບບຖານສອງແທນ, ເຊິ່ງມີຄວາມຫນາແຫນ້ນຫຼາຍ. ນັ້ນແມ່ນ, packets ຈະມີພຽງແຕ່ສອງສາມ bytes. ມີບັນຫາທີ່ຈະພິຈາລະນາຢູ່ທີ່ນີ້ ຄໍາສັ່ງ byte, ເຊິ່ງອາດຈະແຕກຕ່າງກັນໃນຄອມພິວເຕີທີ່ແຕກຕ່າງກັນ.

ເພື່ອ serialize ຂໍ້ມູນ, ທ່ານສາມາດນໍາໃຊ້ຫ້ອງສະຫມຸດ, ຕົວຢ່າງ:

• ແບນແບນ Google
• Cap'n Proto ບໍລິສັດພະຍຸຊາຍ
• ເມລໍດເຂົ້າ Shane Grant ແລະ Randolph Voorhees

ພຽງ​ແຕ່​ເຮັດ​ໃຫ້​ແນ່​ໃຈວ່​າ​ຫ້ອງ​ສະ​ຫມຸດ​ສ້າງ​ການ​ເກັບ​ຮັກ​ສາ​ແບບ​ເຄື່ອນ​ໄຫວ​ແລະ​ເປັນ​ຫ່ວງ​ເປັນ​ໄຍ​ກ່ຽວ​ກັບ endianness​.

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

Glenn Fiedler ຂຽນສອງບົດຄວາມກ່ຽວກັບການ serialization: ຊຸດການອ່ານ ແລະການຂຽນ и ຍຸດທະສາດການຈັດລໍາດັບ.

ການບີບອັດ

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

ການຫຸ້ມຫໍ່ນ້ອຍ

ເຕັກນິກທໍາອິດແມ່ນການຫຸ້ມຫໍ່ນ້ອຍ. ມັນປະກອບດ້ວຍການນໍາໃຊ້ຢ່າງແທ້ຈິງຈໍານວນບິດທີ່ຈໍາເປັນເພື່ອອະທິບາຍມູນຄ່າທີ່ຕ້ອງການ. ຕົວຢ່າງ, ຖ້າທ່ານມີ enum ທີ່ສາມາດມີ 16 ຄ່າທີ່ແຕກຕ່າງກັນ, ຫຼັງຈາກນັ້ນແທນທີ່ຈະເປັນ byte ທັງຫມົດ (8 bits), ທ່ານສາມາດນໍາໃຊ້ພຽງແຕ່ 4 bits.

Glenn Fiedler ອະທິບາຍວິທີການປະຕິບັດນີ້ຢູ່ໃນພາກທີສອງຂອງບົດຄວາມ ຊຸດການອ່ານ ແລະການຂຽນ.

ການຫຸ້ມຫໍ່ບິດເຮັດວຽກໄດ້ດີໂດຍສະເພາະກັບການເກັບຕົວຢ່າງ, ເຊິ່ງຈະເປັນຫົວຂໍ້ຂອງພາກຕໍ່ໄປ.

ການເກັບຕົວຢ່າງ

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

Glenn Fiedler (ອີກເທື່ອຫນຶ່ງ!) ສະແດງໃຫ້ເຫັນວິທີການເອົາຕົວຢ່າງເຂົ້າໄປໃນການປະຕິບັດໃນບົດຄວາມຂອງລາວ ການບີບອັດພາບຖ່າຍ.

ສູດການຄິດໄລ່ການບີບອັດ

ເຕັກນິກຕໍ່ໄປຈະເປັນສູດການຄິດໄລ່ການບີບອັດ lossless.

ນີ້ແມ່ນ, ໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ, ແມ່ນສາມ algorithms ທີ່ຫນ້າສົນໃຈທີ່ສຸດທີ່ທ່ານຈໍາເປັນຕ້ອງຮູ້:

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

ການບີບອັດ Delta

ເຕັກນິກການບີບອັດສຸດທ້າຍແມ່ນການບີບອັດ delta. ມັນປະກອບດ້ວຍຄວາມຈິງທີ່ວ່າພຽງແຕ່ຄວາມແຕກຕ່າງລະຫວ່າງສະຖານະເກມໃນປະຈຸບັນແລະລັດສຸດທ້າຍທີ່ໄດ້ຮັບໂດຍລູກຄ້າໄດ້ຖືກຖ່າຍທອດ.

ມັນຖືກນໍາໃຊ້ຄັ້ງທໍາອິດໃນເຄື່ອງຈັກເຄືອຂ່າຍ Quake3. ນີ້ແມ່ນສອງບົດຄວາມອະທິບາຍວິທີການນໍາໃຊ້ມັນ:

• ຮູບແບບເຄືອຂ່າຍ Quake3 Brian Hook
• Quake 3 Source Code Review: Network Model Fabien Sanglars [translation ບົດຄວາມກ່ຽວກັບ Habre, ເບິ່ງພາກ "ຕົວແບບເຄືອຂ່າຍ"]

Glenn Fiedler ຍັງໄດ້ໃຊ້ມັນຢູ່ໃນພາກທີສອງຂອງບົດຄວາມຂອງລາວ ການບີບອັດພາບຖ່າຍ.

ການເຂົ້າລະຫັດ

ນອກຈາກນັ້ນ, ທ່ານອາດຈະຈໍາເປັນຕ້ອງໄດ້ເຂົ້າລະຫັດການໂອນຂໍ້ມູນລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ. ມີຫຼາຍເຫດຜົນສໍາລັບການນີ້:

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

ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ໃຊ້ຫ້ອງສະຫມຸດສໍາລັບການນີ້. ຂ້າພະເຈົ້າແນະນໍາໃຫ້ໃຊ້ libsodium, ເນື່ອງຈາກວ່າມັນງ່າຍດາຍໂດຍສະເພາະແລະມີ tutorials ທີ່ດີເລີດ. ຫນ້າສົນໃຈໂດຍສະເພາະແມ່ນການສອນກ່ຽວກັບ ການແລກປ່ຽນທີ່ສໍາຄັນ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສ້າງລະຫັດໃຫມ່ກັບແຕ່ລະການເຊື່ອມຕໍ່ໃຫມ່.

Application Protocol: ສະຫຼຸບ

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

ເຫດຜົນຂອງຄໍາຮ້ອງສະຫມັກ

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

ຍິ່ງໄປກວ່ານັ້ນ, ລະຫວ່າງສອງການປັບປຸງລັດ, ໂລກແມ່ນສະຖິດຢ່າງສົມບູນ. ຖ້າອັດຕາການປັບປຸງຂອງລັດແມ່ນຕໍ່າ, ຫຼັງຈາກນັ້ນການເຄື່ອນໄຫວຈະ jerky ຫຼາຍ.

ມີເຕັກນິກຈໍານວນຫນຶ່ງເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຂອງບັນຫານີ້, ແລະຂ້ອຍຈະກວມເອົາພວກເຂົາໃນພາກຕໍ່ໄປ.

ເທັກນິກການຊັກຊ້າ

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

ເຕັກນິກທໍາອິດແມ່ນການນໍາໃຊ້ຜົນໄດ້ຮັບການປ້ອນຂໍ້ມູນໂດຍກົງໂດຍບໍ່ຕ້ອງລໍຖ້າການຕອບສະຫນອງຈາກເຄື່ອງແມ່ຂ່າຍ. ມັນ​ຖືກ​ເອີ້ນ​ວ່າ ການ​ຄາດ​ຄະ​ເນ​ຂ້າງ​ລູກ​ຄ້າ​. ຢ່າງໃດກໍຕາມ, ເມື່ອລູກຄ້າໄດ້ຮັບການອັບເດດຈາກເຄື່ອງແມ່ຂ່າຍ, ມັນຕ້ອງກວດສອບວ່າການຄາດຄະເນຂອງມັນຖືກຕ້ອງ. ຖ້ານີ້ບໍ່ແມ່ນກໍລະນີ, ລາວພຽງແຕ່ຕ້ອງການປ່ຽນລັດຂອງຕົນຕາມສິ່ງທີ່ລາວໄດ້ຮັບຈາກເຄື່ອງແມ່ຂ່າຍ, ເພາະວ່າເຄື່ອງແມ່ຂ່າຍແມ່ນ authoritarian. ເຕັກນິກນີ້ຖືກນໍາໃຊ້ຄັ້ງທໍາອິດໃນ Quake. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບມັນຢູ່ໃນບົດຄວາມ ການທົບທວນລະຫັດ Quake Engine Fabien Sanglars [translation ສຸດ Habre].

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

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

Glenn Fiedler (ຕາມເຄີຍ!) ຂຽນບົດຄວາມໃນປີ 2004 ຟີຊິກເຄືອຂ່າຍ (2004), ເຊິ່ງລາວໄດ້ວາງພື້ນຖານສໍາລັບການ synchronizing ຟີຊິກ simulations ລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າ. ໃນປີ 2014 ລາວໄດ້ຂຽນຊຸດໃຫມ່ຂອງບົດຄວາມ ຟີຊິກເຄືອຂ່າຍ, ເຊິ່ງອະທິບາຍເຕັກນິກອື່ນໆສໍາລັບການ synchronizing ຟີຊິກ simulations.

ຍັງມີສອງບົດຄວາມກ່ຽວກັບ Valve wiki, ແຫຼ່ງເຄືອຂ່າຍຜູ້ຫຼິ້ນຫຼາຍຄົນ и ວິທີການຊົດເຊີຍຄວາມແຝງໃນລູກຂ່າຍ/ເຊີບເວີ ໃນເກມອອກແບບ ແລະປັບແຕ່ງໂປໂຕຄອນ ເຊິ່ງພິຈາລະນາການຊົດເຊີຍສໍາລັບການຊັກຊ້າ.

ປ້ອງກັນການສໍ້ໂກງ

ມີສອງເຕັກນິກຕົ້ນຕໍສໍາລັບການປ້ອງກັນການໂກງ.

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

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

ເຫດຜົນຂອງຄໍາຮ້ອງສະຫມັກ: ສະຫຼຸບ

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

ຊັບພະຍາກອນທີ່ເປັນປະໂຫຍດອື່ນໆ

ຖ້າທ່ານຕ້ອງການຄົ້ນຫາຊັບພະຍາກອນອື່ນໆໃນຕົວແບບເຄືອຂ່າຍ, ທ່ານສາມາດຊອກຫາພວກມັນໄດ້ທີ່ນີ້:

• ບລັອກຂອງ Glenn Fiedler - blog ທັງຫມົດຂອງລາວແມ່ນມີມູນຄ່າການອ່ານ, ມີບົດຄວາມທີ່ດີຫຼາຍຢູ່ທີ່ນັ້ນ. ມັນເປັນ ບົດຄວາມທັງຫມົດກ່ຽວກັບເຕັກໂນໂລຢີເຄືອຂ່າຍຖືກລວບລວມ.
• ເຄືອຂ່າຍເກມທີ່ຫນ້າຫວາດສຽວ ໂດຍ M. Fatih MAR ແມ່ນບັນຊີລາຍຊື່ທີ່ສົມບູນແບບຂອງບົດຄວາມແລະວິດີໂອກ່ຽວກັບເຄື່ອງຈັກວິດີໂອເກມອອນໄລນ໌.
• В wiki ຂອງ r/gamedev subreddit ຍັງມີການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດຫຼາຍ.

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