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

ສະບາຍດີ, ຂ້ອຍແມ່ນ Nikita Brizhak, ຜູ້ພັດທະນາເຊີບເວີຈາກ Pixonic. ມື້​ນີ້​ຂ້າ​ພະ​ເຈົ້າ​ຢາກ​ຈະ​ສົນ​ທະ​ນາ​ກ່ຽວ​ກັບ​ການ​ຊົດ​ເຊີຍ​ສໍາ​ລັບ​ການ lag ໃນ multiplayer ໂທລະ​ສັບ​ມື​ຖື​.

ບົດຄວາມຈໍານວນຫຼາຍໄດ້ຖືກຂຽນກ່ຽວກັບການຊົດເຊີຍຄວາມຊ້າຂອງເຄື່ອງແມ່ຂ່າຍ, ລວມທັງພາສາລັດເຊຍ. ນີ້ບໍ່ແປກໃຈ, ນັບຕັ້ງແຕ່ເຕັກໂນໂລຢີນີ້ຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນໃນການສ້າງ FPS multiplayer ນັບຕັ້ງແຕ່ທ້າຍຊຸມປີ 90s. ຕົວຢ່າງ, ທ່ານສາມາດຈື່ຈໍາ QuakeWorld mod, ເຊິ່ງເປັນຫນຶ່ງໃນທໍາອິດທີ່ໃຊ້ມັນ.

ພວກເຮົາຍັງໃຊ້ມັນຢູ່ໃນມືຖືຫຼາຍຜູ້ນ Dino Squad ຂອງພວກເຮົາ.

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

ສອງສາມຄໍາກ່ຽວກັບ cortex ແລະເຕັກໂນໂລຢີຂອງພວກເຮົາ.

Dino Squad ເປັນນັກຍິງ PvP ມືຖືເຄືອຂ່າຍ. ຜູ້ຫຼິ້ນຄວບຄຸມໄດໂນເສົາທີ່ມີອາວຸດຫຼາກຫຼາຍຊະນິດ ແລະຕໍ່ສູ້ກັນໃນທີມ 6v6.

ທັງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍແມ່ນອີງໃສ່ Unity. ສະຖາປັດຕະຍະກໍາແມ່ນຂ້ອນຂ້າງຄລາສສິກສໍາລັບ shooters: ເຄື່ອງແມ່ຂ່າຍແມ່ນ authoritarian, ແລະການຄາດຄະເນລູກຄ້າເຮັດວຽກກ່ຽວກັບລູກຄ້າ. ການຈຳລອງເກມແມ່ນຂຽນໂດຍໃຊ້ ECS ພາຍໃນເຮືອນ ແລະຖືກໃຊ້ທັງເຊີບເວີ ແລະລູກຂ່າຍ.

ຖ້ານີ້ແມ່ນຄັ້ງທຳອິດທີ່ເຈົ້າໄດ້ຍິນເລື່ອງການຊົດເຊີຍຄວາມຊັກຊ້າ, ນີ້ແມ່ນການເລົ່າສັ້ນໆກ່ຽວກັບບັນຫາ.

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

ໃນຂະນະທີ່ຢູ່ໃນເຄືອຂ່າຍທ້ອງຖິ່ນຄວາມລ່າຊ້ານີ້ (ນິຍົມເອີ້ນວ່າ input lag) ອາດຈະບໍ່ສັງເກດເຫັນ, ເມື່ອຫຼີ້ນຜ່ານອິນເຕີເນັດມັນຈະສ້າງຄວາມຮູ້ສຶກຂອງ "ເລື່ອນຢູ່ເທິງກ້ອນ" ເມື່ອຄວບຄຸມຕົວລະຄອນ. ບັນຫານີ້ແມ່ນມີຄວາມກ່ຽວຂ້ອງສອງເທົ່າສໍາລັບເຄືອຂ່າຍມືຖື, ບ່ອນທີ່ກໍລະນີທີ່ ping ຂອງຜູ້ນແມ່ນ 200 ms ແມ່ນຍັງຖືວ່າເປັນການເຊື່ອມຕໍ່ທີ່ດີເລີດ. ປົກກະຕິແລ້ວ ping ສາມາດເປັນ 350, 500, ຫຼື 1000 ms. ຫຼັງຈາກນັ້ນ, ມັນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະຫຼິ້ນ shooter ໄວທີ່ມີ input lag.

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

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

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

ປະກອບອາວຸດທີ່ມີຄວາມຮູ້ນີ້, ພວກເຮົາເລີ່ມປະຕິບັດການຊົດເຊີຍຄວາມຊ້າຂອງເຄື່ອງແມ່ຂ່າຍໃນ Dino Squad. ກ່ອນອື່ນ ໝົດ, ພວກເຮົາຕ້ອງເຂົ້າໃຈວິທີການຟື້ນຟູໃນເຄື່ອງແມ່ຂ່າຍສິ່ງທີ່ລູກຄ້າໄດ້ເຫັນ? ແລະສິ່ງທີ່ແນ່ນອນຕ້ອງໄດ້ຮັບການຟື້ນຟູ? ໃນເກມຂອງພວກເຮົາ, hits ຈາກອາວຸດແລະຄວາມສາມາດແມ່ນຄິດໄລ່ໂດຍຜ່ານການ raycasts ແລະ overlays - ນັ້ນແມ່ນ, ໂດຍຜ່ານການໂຕ້ຕອບກັບ colliders ທາງດ້ານຮ່າງກາຍຂອງ enemy. ດັ່ງນັ້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຜະລິດໃຫມ່ຕໍາແຫນ່ງຂອງ colliders ເຫຼົ່ານີ້, ທີ່ຜູ້ນ "ເຫັນ" ທ້ອງຖິ່ນ, ໃນເຄື່ອງແມ່ຂ່າຍ. ໃນເວລານັ້ນພວກເຮົາກໍາລັງໃຊ້ Unity ຮຸ່ນ 2018.x. API ຟີຊິກຢູ່ທີ່ນັ້ນແມ່ນຄົງທີ່, ໂລກທາງດ້ານຮ່າງກາຍມີຢູ່ໃນສໍາເນົາດຽວ. ບໍ່ມີວິທີທີ່ຈະຊ່ວຍປະຢັດລັດຂອງມັນແລະຫຼັງຈາກນັ້ນຟື້ນຟູມັນຈາກກ່ອງ. ດັ່ງນັ້ນສິ່ງທີ່ຕ້ອງເຮັດ?

ການ​ແກ້​ໄຂ​ແມ່ນ​ຢູ່​ໃນ​ດ້ານ​; ອົງ​ປະ​ກອບ​ທັງ​ຫມົດ​ຂອງ​ມັນ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ແລ້ວ​ໂດຍ​ພວກ​ເຮົາ​ເພື່ອ​ແກ້​ໄຂ​ບັນ​ຫາ​ອື່ນໆ​:

1. ສໍາລັບລູກຄ້າແຕ່ລະຄົນ, ພວກເຮົາຈໍາເປັນຕ້ອງຮູ້ວ່າເວລາໃດທີ່ລາວເຫັນ opponents ເມື່ອລາວກົດປຸ່ມ. ພວກເຮົາໄດ້ຂຽນຂໍ້ມູນນີ້ໃສ່ຊຸດປ້ອນຂໍ້ມູນແລ້ວ ແລະໃຊ້ມັນເພື່ອປັບການຄາດເດົາຂອງລູກຄ້າ.
2. ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດເກັບຮັກສາປະຫວັດສາດຂອງລັດເກມ. ມັນແມ່ນຢູ່ໃນນັ້ນທີ່ພວກເຮົາຈະຖືຕໍາແຫນ່ງຂອງ opponents ຂອງພວກເຮົາ (ແລະດັ່ງນັ້ນ, colliders ຂອງເຂົາເຈົ້າ). ພວກເຮົາມີປະຫວັດຂອງລັດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍແລ້ວ, ພວກເຮົາໃຊ້ມັນເພື່ອສ້າງ deltas. ໂດຍຮູ້ເວລາທີ່ຖືກຕ້ອງ, ພວກເຮົາສາມາດຊອກຫາລັດທີ່ຖືກຕ້ອງໃນປະຫວັດສາດໄດ້ຢ່າງງ່າຍດາຍ.
3. ຕອນນີ້ພວກເຮົາມີສະຖານະເກມຈາກປະຫວັດສາດຢູ່ໃນມື, ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດ synchronize ຂໍ້ມູນຜູ້ນກັບສະຖານະຂອງໂລກທາງດ້ານຮ່າງກາຍ. colliders ທີ່ມີຢູ່ແລ້ວ - ຍ້າຍອອກ, ທີ່ຂາດຫາຍໄປ - ສ້າງ, ທີ່ບໍ່ຈໍາເປັນ - ທໍາລາຍ. ເຫດຜົນນີ້ຍັງຖືກຂຽນໄວ້ແລ້ວ ແລະປະກອບດ້ວຍລະບົບ ECS ຫຼາຍອັນ. ພວກເຮົາໄດ້ໃຊ້ມັນເພື່ອຈັດຫ້ອງເກມຫຼາຍຫ້ອງໃນຂະບວນການ Unity ດຽວ. ແລະນັບຕັ້ງແຕ່ໂລກທາງດ້ານຮ່າງກາຍແມ່ນຫນຶ່ງຕໍ່ຂະບວນການ, ມັນຕ້ອງໄດ້ຮັບການນໍາໃຊ້ຄືນໃຫມ່ລະຫວ່າງຫ້ອງ. ກ່ອນທີ່ຈະແຕ່ລະຫມາຍຕິກຂອງການຈໍາລອງ, ພວກເຮົາ "ປັບ" ສະຖານະຂອງໂລກທາງດ້ານຮ່າງກາຍແລະ reinitialized ມັນກັບຂໍ້ມູນສໍາລັບຫ້ອງປະຈຸບັນ, ພະຍາຍາມ reuse ວັດຖຸເກມ Unity ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ໂດຍຜ່ານລະບົບສະນຸກເກີທີ່ສະຫລາດ. ທັງຫມົດທີ່ຍັງຄົງຢູ່ແມ່ນເພື່ອຮຽກຮ້ອງເຫດຜົນດຽວກັນສໍາລັບລັດເກມຈາກອະດີດ.

ໂດຍການເອົາອົງປະກອບທັງຫມົດເຫຼົ່ານີ້ເຂົ້າກັນ, ພວກເຮົາມີ "ເຄື່ອງຈັກທີ່ໃຊ້ເວລາ" ທີ່ສາມາດມ້ວນຄືນສະພາບຂອງໂລກທາງດ້ານຮ່າງກາຍໄປສູ່ເວລາທີ່ເຫມາະສົມ. ລະຫັດໄດ້ກາຍເປັນງ່າຍດາຍ:

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

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

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

ແຕ່ມີກົນຈັກດັ່ງກ່າວໜ້ອຍຫຼາຍໃນ Dino Squad! ສ່ວນໃຫຍ່ຂອງອາວຸດໃນເກມສ້າງ projectiles - ລູກປືນທີ່ມີຊີວິດຍາວທີ່ບິນສໍາລັບຫມາຍຕິກ simulation ຫຼາຍ (ໃນບາງກໍລະນີ, ຫມາຍຕິກຫຼາຍສິບ). ຈະເຮັດແນວໃດກັບພວກເຂົາ, ເວລາໃດພວກເຂົາຄວນຈະບິນ?

В ບົດຄວາມບູຮານ ກ່ຽວກັບເຄືອຂ່າຍ Half-Life, guys ຈາກ Valve ໄດ້ຖາມຄໍາຖາມດຽວກັນ, ແລະຄໍາຕອບຂອງເຂົາເຈົ້າແມ່ນນີ້: ການຊົດເຊີຍການຊັກຊ້າຂອງ projectile ແມ່ນມີບັນຫາ, ແລະມັນດີກວ່າທີ່ຈະຫຼີກເວັ້ນ.

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

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

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

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

• ລູກປືນໝົດອາຍຸແລ້ວ. ນີ້​ຫມາຍ​ຄວາມ​ວ່າ​ການ​ຄິດ​ໄລ່​ແມ່ນ​ສິ້ນ​ສຸດ​ລົງ​, ພວກ​ເຮົາ​ສາ​ມາດ​ນັບ​ພາດ​ຫຼື​ຕີ​ໄດ້​. ແລະນີ້ແມ່ນຈຸດດຽວກັນທີ່ຍິງຖືກຍິງ! ສໍາລັບພວກເຮົາ, ນີ້ແມ່ນທັງບວກແລະລົບ. ບວກ - ເພາະວ່າສໍາລັບຜູ້ນຍິງນີ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍລະຫວ່າງການຕີແລະການຫຼຸດຜ່ອນສຸຂະພາບຂອງສັດຕູ. ການຫຼຸດລົງແມ່ນວ່າຜົນກະທົບດຽວກັນໄດ້ຖືກສັງເກດເຫັນໃນເວລາທີ່ opponents ຍິງໃສ່ຜູ້ນ: ສັດຕູ, ມັນຈະເບິ່ງຄືວ່າ, ພຽງແຕ່ຍິງລູກຊ້າ, ແລະຄວາມເສຍຫາຍໄດ້ຖືກນັບແລ້ວ.
• ລູກປືນໄດ້ຮອດເວລາເຊີບເວີແລ້ວ. ໃນກໍລະນີນີ້, ການຈໍາລອງຂອງມັນຈະສືບຕໍ່ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕໍ່ໄປ tick ໂດຍບໍ່ມີການຊົດເຊີຍ lag. ສໍາລັບ projectiles ຊ້າ, ນີ້ທາງທິດສະດີສາມາດຫຼຸດຜ່ອນຈໍານວນຂອງ rollbacks ຟີຊິກເມື່ອທຽບກັບທາງເລືອກທໍາອິດ. ໃນເວລາດຽວກັນ, ການໂຫຼດທີ່ບໍ່ສະເຫມີກັນໃນ simulation ເພີ່ມຂຶ້ນ: ເຄື່ອງແມ່ຂ່າຍບໍ່ເຮັດວຽກ, ຫຼືຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງຫມາຍຕິກມັນແມ່ນການຄິດໄລ່ອາຍແກັສຫມາຍຕິກ simulation ສໍາລັບຫຼາຍ bullets.

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

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

ແຍກຕ່າງຫາກ, ມັນເປັນມູນຄ່າການຍົກບັນຫາການປະຕິບັດ. ຖ້າເຈົ້າຄິດວ່າສິ່ງທັງໝົດນີ້ຈະຊ້າລົງ, ຂ້ອຍຕອບວ່າ: ແມ່ນ. ຄວາມສາມັກຄີແມ່ນຂ້ອນຂ້າງຊ້າໃນການເຄື່ອນຍ້າຍ colliders ແລະເປີດແລະປິດໃຫ້ເຂົາເຈົ້າ. ໃນ Dino Squad, ໃນກໍລະນີທີ່ "ຮ້າຍແຮງທີ່ສຸດ", ສາມາດມີລູກສອນໄຟຫຼາຍຮ້ອຍລູກພ້ອມໆກັນໃນການສູ້ຮົບ. ການເຄື່ອນຍ້າຍ colliders ເພື່ອນັບແຕ່ລະ projectile ສ່ວນບຸກຄົນແມ່ນຄວາມຫລູຫລາທີ່ບໍ່ສາມາດຊື້ໄດ້. ດັ່ງນັ້ນ, ມັນເປັນສິ່ງຈໍາເປັນທີ່ສຸດສໍາລັບພວກເຮົາທີ່ຈະຫຼຸດຜ່ອນຈໍານວນຂອງຟີຊິກ "rollbacks". ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໄດ້ສ້າງອົງປະກອບແຍກຕ່າງຫາກໃນ ECS ທີ່ພວກເຮົາບັນທຶກເວລາຂອງຜູ້ນ. ພວກ​ເຮົາ​ໄດ້​ເພີ່ມ​ມັນ​ກັບ​ຫົວ​ຫນ່ວຍ​ທັງ​ຫມົດ​ທີ່​ຕ້ອງ​ການ​ການ​ຊົດ​ເຊີຍ lag (projectiles​, ຄວາມ​ສາ​ມາດ​, ແລະ​ອື່ນໆ​)​. ກ່ອນທີ່ພວກເຮົາຈະເລີ່ມຕົ້ນການປະມວນຜົນຫນ່ວຍງານດັ່ງກ່າວ, ພວກເຮົາຈັດກຸ່ມໃຫ້ເຂົາເຈົ້າໃນເວລານີ້ແລະປຸງແຕ່ງໃຫ້ເຂົາເຈົ້າຮ່ວມກັນ, ມ້ວນກັບຄືນໂລກທາງດ້ານຮ່າງກາຍຫນຶ່ງຄັ້ງສໍາລັບແຕ່ລະ cluster.

ໃນຂັ້ນຕອນນີ້ພວກເຮົາມີລະບົບການເຮັດວຽກໂດຍທົ່ວໄປ. ລະຫັດຂອງມັນໃນຮູບແບບທີ່ງ່າຍດາຍບາງ:

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອ configure ລາຍລະອຽດ:

1. ເຂົ້າໃຈຫຼາຍປານໃດເພື່ອຈໍາກັດໄລຍະທາງສູງສຸດຂອງການເຄື່ອນໄຫວໃນເວລາ.

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

2. ກຳນົດວ່າວັດຖຸໃດສາມາດເຄື່ອນຍ້າຍໄດ້ທັນເວລາ ແລະອັນໃດບໍ່ສາມາດເຄື່ອນຍ້າຍໄດ້.

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

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

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

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

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

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

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

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

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

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

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

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

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