ပြီးခဲ့သောနှစ်ပတ်အတွင်း ကျွန်ုပ်သည် ကျွန်ုပ်၏ဂိမ်းအတွက် အွန်လိုင်းအင်ဂျင်ကို လုပ်ဆောင်နေပါသည်။ အရင်ကတော့ ဂိမ်းတွေမှာ ကွန်ရက်ချိတ်ဆက်ခြင်းအကြောင်း လုံးဝမသိခဲ့တော့ ဆောင်းပါးတွေ အများကြီးဖတ်ပြီး သဘောတရားအားလုံးကို နားလည်ဖို့နဲ့ ကိုယ်ပိုင်ကွန်ရက်အင်ဂျင်ကို ရေးနိုင်စေဖို့ လက်တွေ့စမ်းသပ်မှုတွေ အများကြီးလုပ်ခဲ့တယ်။

ဤလမ်းညွှန်တွင်၊ သင့်ကိုယ်ပိုင်ဂိမ်းအင်ဂျင်ကို မရေးမီ သင်လေ့လာရန် လိုအပ်သည့် အယူအဆအမျိုးမျိုးအပြင် ၎င်းတို့ကို လေ့လာရန် အကောင်းဆုံးအရင်းအမြစ်များနှင့် ဆောင်းပါးများကို သင့်အား မျှဝေပေးလိုပါသည်။

ယေဘူယျအားဖြင့်၊ ကွန်ရက်တည်ဆောက်ပုံများ အဓိက အမျိုးအစား နှစ်ခုရှိသည်- peer-to-peer နှင့် client-server။ peer-to-peer (p2p) ဗိသုကာတွင်၊ ချိတ်ဆက်ထားသော ကစားသမားအတွဲများကြားတွင် ဒေတာကို လွှဲပြောင်းပေးသည်၊ ဖောက်သည်-ဆာဗာ ဗိသုကာတစ်ခုတွင်၊ ကစားသမားများနှင့် ဆာဗာကြားတွင်သာ ဒေတာကို လွှဲပြောင်းပါသည်။

အချို့သောဂိမ်းများတွင် peer-to-peer ဗိသုကာကိုအသုံးပြုနေဆဲဖြစ်သော်လည်း client-server သည် စံနှုန်းဖြစ်သည်- ၎င်းသည် အကောင်အထည်ဖော်ရန်ပိုမိုလွယ်ကူသည်၊ ပိုမိုသေးငယ်သောချန်နယ်အကျယ်ကိုလိုအပ်ပြီး လိမ်လည်မှုမှကာကွယ်ရန်ပိုမိုလွယ်ကူစေသည်။ ထို့ကြောင့်၊ ဤသင်ခန်းစာတွင်ကျွန်ုပ်တို့သည် client-server တည်ဆောက်ပုံကိုအာရုံစိုက်ပါမည်။

အထူးသဖြင့်၊ ကျွန်ုပ်တို့သည် အာဏာရှင်ဆာဗာများကို စိတ်ဝင်စားဆုံးဖြစ်သည်- ထိုသို့သောစနစ်များတွင် ဆာဗာသည် အမြဲတမ်းမှန်ပါသည်။ ဥပမာအားဖြင့်၊ ကစားသမားတစ်ဦးသည် သြဒိနိတ်များ (10၊ 5) တွင်ရှိပြီး ဆာဗာက ၎င်းသည် (5၊ 3) တွင်ရှိသည်ဟု ယူဆပါက၊ client သည် ဆာဗာမှတင်ပြထားသည့်အရာနှင့် ၎င်း၏ရာထူးကို အစားထိုးသင့်ပြီး ဒု-မဟုတ်၊ လုပ်ပေးသည်။ တရားဝင်ဆာဗာများကို အသုံးပြုခြင်းသည် လိမ်လည်သူများကို ခွဲခြားသတ်မှတ်ရန် ပိုမိုလွယ်ကူစေသည်။

ကွန်ရက်ဂိမ်းစနစ်များတွင် အဓိက အစိတ်အပိုင်း သုံးခုရှိသည်။

• သယ်ယူပို့ဆောင်ရေး ပရိုတိုကော- ကလိုင်းယင့်နှင့် ဆာဗာအကြား ဒေတာလွှဲပြောင်းပုံ။
• အပလီကေးရှင်း ပရိုတိုကော- ဖောက်သည်များမှ ဆာဗာသို့ လည်းကောင်း၊ ဆာဗာမှ ဖောက်သည်များထံသို့ မည်ကဲ့သို့ ဖောမတ်သို့ ပေးပို့သနည်း။
• အပလီကေးရှင်း ယုတ္တိဗေဒ- လွှဲပြောင်းထားသော ဒေတာကို ဖောက်သည်များနှင့် ဆာဗာ၏ အခြေအနေအား အပ်ဒိတ်လုပ်ရန် မည်သို့အသုံးပြုသည်။

အစိတ်အပိုင်းတစ်ခုစီ၏ အခန်းကဏ္ဍနှင့် ၎င်းတို့နှင့်ဆက်စပ်နေသော စိန်ခေါ်မှုများကို နားလည်ရန် အလွန်အရေးကြီးပါသည်။

သယ်ယူပို့ဆောင်ရေး ပရိုတိုကော

ပထမအဆင့်မှာ ဆာဗာနှင့် ဖောက်သည်များကြားတွင် ဒေတာပို့ဆောင်ရန်အတွက် ပရိုတိုကောကို ရွေးချယ်ရန်ဖြစ်သည်။ ၎င်းအတွက် အင်တာနက် ပရိုတိုကော နှစ်ခုရှိသည်။ သည် TCP и UDP ကို. သို့သော် ၎င်းတို့ထဲမှ တစ်ခုကို အခြေခံ၍ သင့်ကိုယ်ပိုင် သယ်ယူပို့ဆောင်ရေး ပရိုတိုကောကို ဖန်တီးနိုင်သည် သို့မဟုတ် ၎င်းတို့ကို အသုံးပြုသည့် စာကြည့်တိုက်ကို အသုံးပြုနိုင်သည်။

TCP နှင့် UDP နှိုင်းယှဉ်

TCP နှင့် UDP နှစ်ခုစလုံးအပေါ်အခြေခံသည်။ IP. IP သည် ပက်ကေ့ခ်ျတစ်ခုကို အရင်းအမြစ်တစ်ခုမှ လက်ခံသူထံသို့ ပေးပို့နိုင်သော်လည်း ပေးပို့လိုက်သော ပက်ကတ်သည် မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် လက်ခံသူထံ ရောက်ရှိမည်ဖြစ်ကြောင်း၊ ၎င်းသည် အနည်းဆုံး တစ်ကြိမ်ရောက်ရှိမည်ဖြစ်ပြီး၊ ပက်ကတ်များ၏ အစီအရီသည် မှန်ကန်ကြောင်းရောက်ရှိမည်ဟု အာမမခံနိုင်ပါ။ အမိန့်။ ထို့အပြင်၊ ပက်ကတ်တစ်ခုတွင် တန်ဖိုးအားဖြင့်ပေးသော ဒေတာပမာဏအကန့်အသတ်သာ ပါဝင်နိုင်သည်။ သမဂ္ဂ.

UDP သည် IP ၏ထိပ်တွင် ပါးလွှာသော အလွှာတစ်ခုသာဖြစ်သည်။ ထို့ကြောင့် တူညီသော ကန့်သတ်ချက်များရှိသည်။ ဆန့်ကျင်ဘက်အနေဖြင့် TCP တွင်အင်္ဂါရပ်များစွာရှိသည်။ ၎င်းသည် အမှားစစ်ဆေးခြင်းနှင့်အတူ node နှစ်ခုကြားတွင် ယုံကြည်စိတ်ချရသော၊ စနစ်တကျချိတ်ဆက်မှုကို ပေးဆောင်သည်။ ထို့ကြောင့် TCP သည် အလွန်အဆင်ပြေပြီး အခြားသော ပရိုတိုကောများစွာတွင် အသုံးပြုပါသည်။ သည် HTTP, တယောက်က FTP и SMTP. သို့သော် ဤအင်္ဂါရပ်များအားလုံးကို စျေးနှုန်းဖြင့် ရောက်လာသည်- နှောင့်နှေးခြင်း။.

ဤလုပ်ဆောင်ချက်များသည် latency ကို အဘယ်ကြောင့်ဖြစ်စေသည်ကို နားလည်ရန်၊ ကျွန်ုပ်တို့သည် TCP အလုပ်လုပ်ပုံကို နားလည်ရန် လိုအပ်ပါသည်။ sending node သည် packet တစ်ခုကို လက်ခံသည့် node သို့ ပို့သောအခါ၊ acknowledgment (ACK) ကို လက်ခံရရှိရန် မျှော်လင့်ပါသည်။ အကယ်၍ သတ်မှတ်ထားသောအချိန်တစ်ခုပြီးနောက် ၎င်းသည် ၎င်းကိုမရရှိပါက (ပက်ကတ် သို့မဟုတ် အသိအမှတ်ပြုမှု ပျောက်ဆုံးသွားသောကြောင့် သို့မဟုတ် အခြားအကြောင်းတစ်ခုခုကြောင့်) ၎င်းသည် ပက်ကတ်ကို ပြန်လည်ပေးပို့သည်။ ထို့အပြင်၊ TCP သည် packet များကို မှန်ကန်သောအစီအစဥ်အတိုင်း လက်ခံရရှိကြောင်း အာမခံပါသည်၊ ထို့ကြောင့် ဆုံးရှုံးသွားသော packet ကို လက်ခံရရှိသည့်အချိန်အထိ၊ လက်ခံသူမှ လက်ခံရရှိပြီးသားဖြစ်လျှင်ပင် အခြားသော packet အားလုံးကို စီမံဆောင်ရွက်နိုင်မည်မဟုတ်ပေ။

သို့သော် သင်စိတ်ကူးနိုင်သည်အတိုင်း၊ များစွာသောကစားသူဂိမ်းများတွင် latency သည် အထူးသဖြင့် FPS ကဲ့သို့သော လုပ်ဆောင်ချက်ပါဝင်သည့်အမျိုးအစားများတွင် အလွန်အရေးကြီးပါသည်။ အဲဒါကြောင့် ဂိမ်းတော်တော်များများက UDP ကို ​​သူတို့ရဲ့ကိုယ်ပိုင် protocol နဲ့ သုံးပါတယ်။

မူလ UDP-based ပရိုတိုကောသည် အကြောင်းအမျိုးမျိုးကြောင့် TCP ထက် ပိုမိုထိရောက်နိုင်သည်။ ဥပမာအားဖြင့်၊ ၎င်းသည် အချို့သော ပက်ကေ့ခ်ျများကို ယုံကြည်ပြီး အခြားအရာများကို မယုံကြည်ရဟု အမှတ်အသားပြုနိုင်သည်။ ထို့ကြောင့်၊ စိတ်မချရသော ပက်ကေ့ခ်ျသည် လက်ခံသူထံသို့ ရောက်ရှိလာသည်ဖြစ်စေ ဂရုမစိုက်ပါ။ သို့မဟုတ်ပါက ဒေတာစီးကြောင်းများစွာကို ထုတ်လွှင့်မှုတစ်ခုရှိ ပျောက်ဆုံးသွားသော ပက်ကေ့ခ်ျသည် ကျန်ရှိနေသည့် ထုတ်လွှင့်မှုများကို နှေးကွေးမသွားစေရန် ၎င်းသည် လုပ်ဆောင်နိုင်သည်။ ဥပမာအားဖြင့်၊ ပလေယာထည့်သွင်းမှုအတွက် thread တစ်ခုနှင့် ချတ်မက်ဆေ့ချ်များအတွက် အခြား thread တစ်ခုရှိနိုင်သည်။ အရေးပေါ်မဟုတ်သော ချတ်မက်ဆေ့ချ်တစ်ခု ပျောက်ဆုံးပါက၊ ၎င်းသည် အရေးတကြီးထည့်သွင်းမှုကို နှေးကွေးမည်မဟုတ်ပါ။ သို့မဟုတ် မူပိုင်ပရိုတိုကောသည် ဗီဒီယိုဂိမ်းပတ်ဝန်းကျင်တွင် ပိုမိုထိရောက်စေရန် TCP ထက် ကွဲပြားခြားနားသော ယုံကြည်စိတ်ချရမှုကို ဖော်ဆောင်ပေးနိုင်သည်။

ထို့ကြောင့် TCP သည် အလွန်ညံ့ပါက UDP ကို ​​အခြေခံ၍ ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် သယ်ယူပို့ဆောင်ရေး ပရိုတိုကောကို ဖန်တီးမည်လား။

နည်းနည်းပိုရှုပ်ထွေးတယ်။ TCP သည် ဂိမ်းကွန်ရက်စနစ်များအတွက် အသင့်တော်ဆုံးနီးပါးဖြစ်သော်လည်း၊ ၎င်းသည် သင်၏သတ်မှတ်ဂိမ်းအတွက် အတော်လေး ကောင်းမွန်စွာလုပ်ဆောင်နိုင်ပြီး သင့်အတွက် အဖိုးတန်အချိန်ကို သက်သာစေပါသည်။ ဥပမာအားဖြင့်၊ latency သည် အင်တာနက်ပေါ်ရှိ latency နှင့် packet များထက် များစွာနိမ့်ကျသော LAN ကွန်ရက်များတွင်သာ ကစားနိုင်သည့် ဂိမ်းတစ်ခုအတွက် ပြဿနာမဟုတ်နိုင်ပါ။

World of Warcraft၊ Minecraft နှင့် Terraria အပါအဝင် အောင်မြင်သောဂိမ်းများစွာသည် TCP ကို ​​အသုံးပြုသည်။ သို့သော်၊ FPS အများစုသည် ၎င်းတို့၏ကိုယ်ပိုင် UDP-based ပရိုတိုကောများကို အသုံးပြုသည်၊ ထို့ကြောင့် ၎င်းတို့အကြောင်း အောက်တွင် ကျွန်ုပ်တို့ ဆက်လက်ပြောပြပါမည်။

TCP ကိုအသုံးပြုရန်ဆုံးဖြတ်ပါက ၎င်းကိုပိတ်ထားကြောင်းသေချာပါစေ။ Nagle ၏ အယ်လဂိုရီသမ်ပေးပို့ခြင်းမပြုမီ packets များကို ကြားခံလုပ်ဆောင်ပေးသောကြောင့်၊ ဆိုလိုသည်မှာ latency ကိုတိုးစေသည်။

Multiplayer ဂိမ်းများအကြောင်း UDP နှင့် TCP အကြား ခြားနားချက်များကို ပိုမိုလေ့လာရန်၊ Glenn Fiedler ၏ ဆောင်းပါးကို ဖတ်ရှုနိုင်ပါသည်။ UDP နှင့် TCP.

ကိုယ်ပိုင် ပရိုတိုကော

ထို့ကြောင့် သင်သည် သင်၏ကိုယ်ပိုင် သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကို ဖန်တီးလိုသော်လည်း မည်သည့်နေရာတွင် စတင်ရမှန်းမသိ ဖြစ်နေပါသလား။ Glenn Fiedler သည် ဤအကြောင်းနှင့်ပတ်သက်သည့် အံ့သြဖွယ်ဆောင်းပါးနှစ်ခုကို ရေးသားထားသောကြောင့် သင်ကံကောင်းပါသည်။ သူတို့ထဲမှာ ထက်မြက်တဲ့ အတွေးတွေ အများကြီး တွေ့လိမ့်မယ်။

ပထမဆောင်းပါး ဂိမ်းပရိုဂရမ်မာများအတွက် ကွန်ရက်ချိတ်ဆက်ခြင်း။ 2008 ဒုတိယနှစ်ထက် ပိုလွယ်၊ Game Network Protocol တစ်ခုကို တည်ဆောက်ခြင်း။ ၂၀၁၆။ အသက်ကြီးတာနဲ့ စတင်ဖို့ အကြံပြုလိုပါတယ်။

Glenn Fiedler သည် UDP ကိုအခြေခံသည့် စိတ်ကြိုက်ပရိုတိုကောကို အသုံးပြုခြင်းအတွက် ကြီးမားသော ထောက်ခံသူဖြစ်ကြောင်း သတိပြုပါ။ သူ၏ ဆောင်းပါးများကို ဖတ်ပြီးနောက်၊ TCP သည် ဗီဒီယိုဂိမ်းများတွင် ဆိုးရွားသော ချို့ယွင်းချက်များ ရှိသည်ဟူသော သူ့အမြင်ကို သင်လက်ခံနိုင်ပြီး သင့်ကိုယ်ပိုင် ပရိုတိုကောကို အကောင်အထည်ဖော်လိုမည်ဖြစ်သည်။

ဒါပေမယ့် သင်ဟာ ကွန်ရက်ချိတ်ဆက်ခြင်းအတွက် အသစ်ဖြစ်ပါက၊ သင့်ကိုယ်သင် နှစ်သက်သဘောကျပြီး TCP သို့မဟုတ် စာကြည့်တိုက်ကို အသုံးပြုပါ။ သင်၏ကိုယ်ပိုင်သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကိုအောင်မြင်စွာအကောင်အထည်ဖော်ရန်၊ သင်သည်အများကြီးကြိုတင်လေ့လာရန်လိုအပ်သည်။

ကွန်ရက်စာကြည့်တိုက်များ

သင် TCP ထက် ပိုမိုထိရောက်မှုတစ်ခုခုကို လိုအပ်သော်လည်း သင့်ကိုယ်ပိုင်ပရိုတိုကောကို အကောင်အထည် ဖော်ရန်နှင့် အသေးစိတ်အချက်များစွာကို မလုပ်ဆောင်လိုပါက ကွန်ရက်စာကြည့်တိုက်ကို အသုံးပြုနိုင်သည်။ ၎င်းတို့ အများအပြားရှိသည်-

• ယိုဂျမ်ဘို Glenn Fiedler
• RakNetမပံ့ပိုးတော့ပေမယ့် လမ်းခွဲတစ်ခုပါပဲ။ SLikeNet ကြည့်ရသည်မှာ အသက်ဝင်နေဆဲဖြစ်သည်။
• ENet Multiplayer FPS အတွက် ဖန်တီးထားသည့် စာကြည့်တိုက်တစ်ခုဖြစ်သည်။ Cube
• GameNetworkingSockets ရပ်ထား

၎င်းတို့အားလုံးကို မစမ်းကြည့်ရသေးသော်လည်း အသုံးပြုရလွယ်ကူပြီး ယုံကြည်စိတ်ချရသောကြောင့် ENet ကို ပိုနှစ်သက်ပါသည်။ ထို့အပြင်၊ ၎င်းတွင်ရှင်းလင်းသောစာရွက်စာတမ်းများနှင့်အစပြုသူများအတွက်သင်ခန်းစာတစ်ခုပါရှိသည်။

သယ်ယူပို့ဆောင်ရေး ပရိုတိုကော- နိဂုံး

အကျဉ်းချုပ်ပြောရလျှင်- TCP နှင့် UDP တို့၏ အဓိက သယ်ယူပို့ဆောင်ရေး ပရိုတိုကော နှစ်ခုရှိသည်။ TCP တွင် အသုံးဝင်သောအင်္ဂါရပ်များစွာပါရှိသည်- ယုံကြည်စိတ်ချရမှု၊ ထုပ်ပိုးမှုအမှာစာထိန်းသိမ်းမှု၊ အမှားအယွင်းရှာဖွေခြင်း။ UDP တွင် ဤအရာအားလုံး မပါရှိသော်လည်း ၎င်း၏သဘောသဘာဝအရ TCP သည် အချို့ဂိမ်းများအတွက် လက်မခံနိုင်သော latency တိုးလာပါသည်။ ဆိုလိုသည်မှာ၊ latency နည်းပါးစေရန်အတွက်၊ သင်သည် UDP ကိုအခြေခံ၍ သင်၏ကိုယ်ပိုင်ပရိုတိုကောကို ဖန်တီးနိုင်သည် သို့မဟုတ် UDP တွင် သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကို အကောင်အထည်ဖော်သည့် စာကြည့်တိုက်ကို အသုံးပြု၍ များစွာသောကစားသူဗီဒီယိုဂိမ်းများအတွက် လိုက်လျောညီထွေဖြစ်စေသည်။

TCP၊ UDP နှင့် စာကြည့်တိုက်အကြား ရွေးချယ်မှုသည် အချက်များစွာပေါ်တွင် မူတည်သည်။ ပထမ၊ ဂိမ်း၏လိုအပ်ချက်များမှ၊ ၎င်းသည် latency နည်းရန် လိုအပ်ပါသလား။ ဒုတိယအနေဖြင့်၊ အပလီကေးရှင်းပရိုတိုကောလိုအပ်ချက်များမှ- ၎င်းသည် ယုံကြည်စိတ်ချရသော ပရိုတိုကော လိုအပ်ပါသလား။ နောက်အပိုင်းတွင်ကျွန်ုပ်တို့မြင်ရမည့်အတိုင်း၊ မယုံကြည်ရသောပရိုတိုကောသည်အတော်လေးသင့်လျော်သော application protocol တစ်ခုကိုဖန်တီးနိုင်သည်။ နောက်ဆုံးအနေဖြင့်၊ သင်သည် network engine developer ၏အတွေ့အကြုံကိုထည့်သွင်းစဉ်းစားရန်လိုသည်။

ငါ့မှာ အကြံဉာဏ်နှစ်ခုရှိတယ်

• ကုဒ်အားလုံးကို ပြန်မရေးဘဲ အလွယ်တကူ အစားထိုးနိုင်စေရန် ကျန်အပလီကေးရှင်းများမှ သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကို အတတ်နိုင်ဆုံး နုတ်ယူပါ။
• ပိုကောင်းအောင် မလုပ်ပါနဲ့။ အကယ်၍ သင်သည် ကွန်ရက်ချိတ်ဆက်ခြင်းဆိုင်ရာ ကျွမ်းကျင်သူမဟုတ်ပါက စိတ်ကြိုက် UDP-based သယ်ယူပို့ဆောင်ရေးပရိုတိုကော လိုအပ်ခြင်းရှိမရှိ မသေချာပါက၊ သင်သည် ယုံကြည်စိတ်ချရမှုကို ပေးဆောင်သည့် TCP သို့မဟုတ် စာကြည့်တိုက်တစ်ခုဖြင့် စတင်နိုင်ပြီး စွမ်းဆောင်ရည်ကို စမ်းသပ်ပြီး တိုင်းတာနိုင်ပါသည်။ ပြဿနာများ ဖြစ်ပေါ်လာပြီး အကြောင်းအရင်းမှာ သယ်ယူပို့ဆောင်ရေး ပရိုတိုကောဟု ယုံကြည်ပါက၊ သင်၏ကိုယ်ပိုင် သယ်ယူပို့ဆောင်ရေး ပရိုတိုကောကို ဖန်တီးရန် အချိန်ရောက်ပေမည်။

ဒီအပိုင်းကို အဆုံးထိ ဖတ်ကြည့်ဖို့ အကြံပြုချင်ပါတယ်။ Multiplayer Game Programming အကြောင်း နိဒါန်း Brian Hook မှ ဤနေရာတွင် ဆွေးနွေးထားသော အကြောင်းအရာများစွာကို ခြုံငုံမိပါသည်။

လျှောက်လွှာပရိုတိုကော

ယခု ကျွန်ုပ်တို့သည် သုံးစွဲသူများနှင့် ဆာဗာများအကြား ဒေတာဖလှယ်နိုင်စေရန်၊ ကျွန်ုပ်တို့သည် မည်သည့်ဒေတာကို လွှဲပြောင်းရန်နှင့် မည်သည့်ပုံစံဖြင့် ဆုံးဖြတ်ရန် လိုအပ်ပါသည်။

ဂန္တဝင်အစီအစဥ်မှာ ဖောက်သည်များသည် ဆာဗာသို့ ထည့်သွင်းခြင်း သို့မဟုတ် လုပ်ဆောင်ချက်များကို ပေးပို့ခြင်းဖြစ်ပြီး ဆာဗာသည် လက်ရှိဂိမ်းအခြေအနေကို ဖောက်သည်များထံ ပေးပို့ခြင်းဖြစ်သည်။

ဆာဗာသည် အပြည့်အဝပြည်နယ်ကို ပေးပို့သည်မဟုတ်သော်လည်း ကစားသမားအနီးတွင်ရှိသော အရာများပါရှိသော စစ်ထုတ်သည့်အခြေအနေတစ်ခုဖြစ်သည်။ အကြောင်းပြချက်သုံးမျိုးဖြင့် သူလုပ်သည်။ ပထမဦးစွာ၊ ပြီးပြည့်စုံသောအခြေအနေသည် ကြိမ်နှုန်းမြင့်မားစွာဖြင့် ထုတ်လွှင့်ရန် ကြီးမားလွန်းနေပေမည်။ ဒုတိယအနေနှင့်၊ ဖောက်သည်များသည် ဂိမ်းယုတ္တိဗေဒအများစုကို ဂိမ်းဆာဗာတွင် ပုံဖော်ထားသောကြောင့် ရုပ်မြင်သံကြားနှင့် အသံဒေတာကို အဓိကစိတ်ဝင်စားကြသည်။ တတိယအချက်မှာ၊ အချို့ဂိမ်းများတွင် ကစားသမားသည် အချို့သောအချက်အလက်များကို သိရှိရန်မလိုအပ်ပေ၊ ဥပမာအားဖြင့်၊ မြေပုံ၏တစ်ဖက်ခြမ်းရှိ ရန်သူ၏အနေအထား၊ မဟုတ်ပါက packets များကို ရှူရှိုက်နိုင်ပြီး သူ့ကိုသတ်ရန် မည်သည့်နေရာကို ရွှေ့ရမည်ကို အတိအကျသိနိုင်သည်။

အမှတ်စဉ်

ပထမအဆင့်မှာ ကျွန်ုပ်တို့ပေးပို့လိုသော ဒေတာ (ထည့်သွင်းမှု သို့မဟုတ် ဂိမ်းအခြေအနေ) ကို ထုတ်လွှင့်ရန်အတွက် သင့်လျော်သော ဖော်မတ်အဖြစ်သို့ ပြောင်းလဲရန်ဖြစ်သည်။ ဤဖြစ်စဉ်ကို ခေါ်သည်။ အမှတ်စဉ်.

JSON သို့မဟုတ် XML ကဲ့သို့သော လူသားဖတ်နိုင်သော ဖော်မတ်ကို အသုံးပြုရန် ချက်ချင်း သတိရလာသည်။ သို့သော် ၎င်းသည် လုံးဝမထိရောက်ဘဲ ချန်နယ်အများစုကို ဖြုန်းတီးမည်ဖြစ်သည်။

ပိုကျစ်လျစ်သော binary format ကိုသုံးရန် အကြံပြုထားသည်။ ဆိုလိုသည်မှာ၊ ပက်ကေ့ခ်ျများတွင် ဘိုက်အနည်းငယ်သာ ပါဝင်မည်ဖြစ်သည်။ ဒီနေရာမှာ စဉ်းစားစရာ ပြဿနာတစ်ခုရှိတယ်။ ဘိုက်အော်မတူညီသော ကွန်ပျူတာများတွင် ကွဲပြားနိုင်ပါသည်။

ဒေတာကို အမှတ်စဉ်ပြုလုပ်ရန်၊ ဥပမာအားဖြင့်၊ သင်သည် စာကြည့်တိုက်တစ်ခုကို အသုံးပြုနိုင်သည်။

• FlatBuffers များ Google
• Cap'n Proto သဲမုန်တိုင်းကုမ္ပဏီ
• စီရီရယ် Shane Grant နှင့် Randolph Voorhees

စာကြည့်တိုက်သည် သယ်ဆောင်ရလွယ်ကူသော မော်ကွန်းတိုက်များ ဖန်တီးပေးပြီး အဆုံးစွန်မှုကို ဂရုစိုက်ကြောင်း သေချာပါစေ။

အခြားနည်းလမ်းတစ်ခုသည် ၎င်းကို ကိုယ်တိုင်အကောင်အထည်ဖော်ရန်ဖြစ်သည်၊ အထူးသဖြင့် သင်၏ကုဒ်အတွက် ဒေတာဗဟိုပြုချဉ်းကပ်မှုကို သင်အသုံးပြုပါက အထူးခက်ခဲမည်မဟုတ်ပါ။ ထို့အပြင်၊ ၎င်းသည် သင့်အား စာကြည့်တိုက်ကိုအသုံးပြုသည့်အခါ အမြဲတမ်းမဖြစ်နိုင်သော အကောင်းဆုံးပြင်ဆင်မှုများကို လုပ်ဆောင်နိုင်စေမည်ဖြစ်သည်။

Glenn Fiedler သည် နံပါတ်စဉ်များအကြောင်း ဆောင်းပါးနှစ်ပုဒ် ရေးသားခဲ့သည်။ စာဖတ်ခြင်းနှင့် စာရေးခြင်း အစုံလိုက်များ и အမှတ်စဉ်ဗျူဟာများ.

ချုံ့

သုံးစွဲသူများနှင့် ဆာဗာများအကြား လွှဲပြောင်းပေးသည့်ဒေတာပမာဏကို ချန်နယ်၏ bandwidth ဖြင့် ကန့်သတ်ထားသည်။ ဒေတာချုံ့မှုသည် လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုစီတွင် ဒေတာပိုမိုလွှဲပြောင်းခြင်း၊ အပ်ဒိတ်အကြိမ်ရေကို တိုးမြှင့်ခြင်း သို့မဟုတ် ချန်နယ်လိုအပ်ချက်များကို ရိုးရှင်းစွာလျှော့ချနိုင်စေမည်ဖြစ်သည်။

နဲနဲများပါတယ်။

ပထမနည်းပညာမှာ bit packing ဖြစ်သည်။ ၎င်းတွင် လိုချင်သောတန်ဖိုးကိုဖော်ပြရန် လိုအပ်သော bit အရေအတွက်အတိအကျကိုအသုံးပြုခြင်းပါဝင်သည်။ ဥပမာအားဖြင့်၊ သင့်တွင် မတူညီသောတန်ဖိုး ၁၆ ခုရှိနိုင်သော enum တစ်ခုရှိပါက၊ ထို့နောက် byte တစ်ခုလုံး (16 bits) အစား 8 bits ကိုသာသုံးနိုင်သည်။

Glenn Fiedler က ဆောင်းပါးရဲ့ ဒုတိယအပိုင်းမှာ ဒါကို ဘယ်လိုအကောင်အထည်ဖော်ရမလဲဆိုတာ ရှင်းပြထားပါတယ်။ စာဖတ်ခြင်းနှင့် စာရေးခြင်း အစုံလိုက်များ.

Bit packing သည် sampling နှင့် အထူးသဖြင့် ကောင်းမွန်စွာ အလုပ်လုပ်သည်၊ နောက်အပိုင်း၏ ခေါင်းစဉ်ဖြစ်လာပါမည်။

နမူနာယူပါ။

နမူနာယူပါ။ တန်ဖိုးတစ်ခုကို ကုဒ်လုပ်ရန် ဖြစ်နိုင်ချေရှိသော တန်ဖိုးများ၏ အခွဲတစ်ခုသာ အသုံးပြုသည့် lossy compression နည်းပညာတစ်ခုဖြစ်သည်။ ခွဲခြားသတ်မှတ်ခြင်းကို အကောင်အထည်ဖော်ရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ Floating Point နံပါတ်များကို အဝိုင်းလိုက်ဖြင့် ပြုလုပ်ခြင်းဖြစ်သည်။

Glenn Fiedler (တဖန်!) သည် သူ၏ဆောင်းပါးတွင် နမူနာယူနည်းကို လက်တွေ့ကျင့်သုံးပုံကို ပြသထားသည်။ Snapshot Compression.

Compression algorithms

နောက်နည်းလမ်းတစ်ခုကတော့ lossless compression algorithms ပါ။

ဤတွင်၊ ကျွန်ုပ်၏အမြင်အရ၊ သင်သိရန်လိုအပ်သည့် စိတ်ဝင်စားဖွယ်အကောင်းဆုံး algorithms သုံးခုဖြစ်သည်။

• Huffman coding ကြိုတင်တွက်ချက်ထားသောကုဒ်ဖြင့် အလွန်မြန်ဆန်ပြီး ကောင်းမွန်သောရလဒ်များကို ထုတ်ပေးနိုင်သည်။ Quake3 ကွန်ရက်ချိတ်ဆက်မှုအင်ဂျင်ရှိ ပက်ကေ့ခ်ျများကို ချုံ့ရန် အသုံးပြုခဲ့သည်။
• zlib ဒေတာပမာဏကို ဘယ်တော့မှ မတိုးစေမယ့် ယေဘုယျရည်ရွယ်ချက် ဖိသိပ်မှု algorithm တစ်ခုပါ။ ဘယ်လိုမြင်လဲ။ ဒီမှာ၎င်းကို application အမျိုးမျိုးတွင်အသုံးပြုထားသည်။ ပြည်နယ်များကို အပ်ဒိတ်လုပ်ရန် မလိုအပ်တော့ပါ။ သို့သော် သင်သည် ပိုင်ဆိုင်မှုများ၊ ရှည်လျားသောစာတိုများ သို့မဟုတ် တည်နေရာကို ဆာဗာမှ သုံးစွဲသူများထံ ပေးပို့ရန် လိုအပ်ပါက ၎င်းသည် အသုံးဝင်နိုင်သည်။
• အတိုအရှည် ကူးယူခြင်း။ - ၎င်းသည် အရိုးရှင်းဆုံး ဖိသိပ်မှု အယ်လဂိုရီသမ် ဖြစ်နိုင်သည်၊ သို့သော် အချို့သော ဒေတာ အမျိုးအစားများအတွက် အလွန်ထိရောက်ပြီး zlib မတိုင်မီ အကြိုလုပ်ဆောင်မှု အဆင့်အဖြစ် အသုံးပြုနိုင်သည်။ ကပ်လျက်ဒြပ်စင်များစွာကို ထပ်ခါထပ်ခါပြုလုပ်သည့် အကွက်များ သို့မဟုတ် voxels များဖြင့် ဖွဲ့စည်းထားသော မြေပြင်ကို ချုံ့ရန်အတွက် အထူးသင့်လျော်သည်။

မြစ်ဝကျွန်းပေါ်ဒေသ နှိမ်သည်။

နောက်ဆုံးချုံ့နည်းပညာမှာ delta compression ဖြစ်သည်။ လက်ရှိဂိမ်းအခြေအနေနှင့် ကလိုင်းယင့်မှလက်ခံရရှိသည့် နောက်ဆုံးအခြေအနေကြားမှ ကွာခြားချက်များကိုသာ ထုတ်လွှင့်ခြင်းတွင် ပါဝင်သည်။

၎င်းကို Quake3 ကွန်ရက်အင်ဂျင်တွင် ပထမဆုံးအသုံးပြုခဲ့သည်။ ဤသည်မှာ ၎င်းကို အသုံးပြုပုံကို ရှင်းပြထားသော ဆောင်းပါးနှစ်ပုဒ်ဖြစ်သည်။

• Quake3 ကွန်ရက်ချိတ်ဆက်မှုပုံစံ Brian Hook
• Quake 3 အရင်းအမြစ်ကုဒ်ပြန်လည်သုံးသပ်ခြင်း- ကွန်ရက်ပုံစံ Fabien Sanglars [ဘာသာပြန်ချက် Habre ဆောင်းပါးများ၊ ကဏ္ဍ "ကွန်ရက်မော်ဒယ်"] ကိုကြည့်ပါ

Glenn Fiedler သည် ၎င်း၏ ဆောင်းပါး၏ ဒုတိယအပိုင်းတွင်လည်း ၎င်းကို အသုံးပြုခဲ့သည်။ Snapshot Compression.

စာဝှက်ခြင်း

ထို့အပြင်၊ သင်သည် clients နှင့် server အကြား သတင်းအချက်အလက်လွှဲပြောင်းမှုကို စာဝှက်ထားရန် လိုအပ်နိုင်သည်။ ဤအတွက် အကြောင်းရင်းများစွာ ရှိပါသည်။

• ကိုယ်ရေးကိုယ်တာ/လျှို့ဝှက်မှု- မက်ဆေ့ချ်များကို လက်ခံသူမှသာ ဖတ်နိုင်မည်ဖြစ်ပြီး ကွန်ရက်ကို အနံ့ခံသော အခြားသူတစ်ဦးမှ ၎င်းတို့ကို ဖတ်နိုင်မည်မဟုတ်ပေ။
• စစ်မှန်ကြောင်းအထောက်အထားပြခြင်း- ကစားသမားတစ်ဦး၏အခန်းကဏ္ဍကိုကစားလိုသူသည်သူ၏သော့ကိုသိရပါမည်။
• လိမ်လည်ခြင်းကို ကာကွယ်ခြင်း- အန္တရာယ်ရှိသော ကစားသမားများသည် ၎င်းတို့၏ ကိုယ်ပိုင် ခိုးယူမှု ပက်ကေ့ဂျ်များကို ဖန်တီးရန် ပိုမိုခက်ခဲလိမ့်မည်၊ ၎င်းတို့သည် ကုဒ်ဝှက်ခြင်း အစီအစဉ်ကို ပြန်လည်ထုတ်လုပ်ရန်နှင့် သော့ကို ရှာဖွေရလိမ့်မည် (ချိတ်ဆက်မှုတစ်ခုစီတွင် ပြောင်းလဲသွားသည်)။

ဤအတွက် စာကြည့်တိုက်ကို အသုံးပြုရန် ကျွန်ုပ် အထူးအကြံပြုလိုပါသည်။ သုံးဖို့ အကြံပြုပါတယ်။ libsodiumအထူးသဖြင့် ရိုးရှင်းပြီး အလွန်ကောင်းမွန်သော သင်ခန်းစာများ ပါရှိသောကြောင့် ဖြစ်သည်။ အထူးစိတ်ဝင်စားဖို့ကောင်းတာက ကျူတိုရီရယ်ပါ။ သော့လဲလှယ်ချိတ်ဆက်မှုအသစ်တစ်ခုစီဖြင့် သော့အသစ်များကို ထုတ်လုပ်ခွင့်ပြုသည်။

လျှောက်လွှာပရိုတိုကော- နိဂုံး

၎င်းသည် ကျွန်ုပ်တို့၏လျှောက်လွှာပရိုတိုကောကို အဆုံးသတ်သည်။ Compression သည် လုံးဝရွေးချယ်ခွင့်ရှိပြီး ၎င်းကိုအသုံးပြုရန် ဆုံးဖြတ်ချက်သည် ဂိမ်းနှင့် လိုအပ်သော bandwidth ပေါ်တွင်သာ မူတည်သည်ဟု ကျွန်တော်ယုံကြည်ပါသည်။ လျှို့ဝှက်ကုဒ်သွင်းခြင်းသည် မဖြစ်မနေလိုအပ်သော်လည်း ပထမပုံစံတွင် ၎င်းမပါဘဲ သင်လုပ်ဆောင်နိုင်သည်။

လျှောက်လွှာယုတ္တိ

ယခုအခါ ကျွန်ုပ်တို့သည် ကလိုင်းယင့်ရှိ အခြေအနေအား အပ်ဒိတ်လုပ်နိုင်သော်လည်း latency ပြဿနာများနှင့် ရင်ဆိုင်ရနိုင်သည်။ ပလေယာသည် ထည့်သွင်းမှုကို ပြီးမြောက်ပြီးနောက်၊ ၎င်းသည် ကမ္ဘာပေါ်ရှိ အကျိုးသက်ရောက်မှုကို သိရှိရန် ဆာဗာမှ ဂိမ်းအခြေအနေအား အပ်ဒိတ်လုပ်ရန် စောင့်ဆိုင်းရန် လိုအပ်သည်။

ထို့အပြင်၊ ပြည်နယ်အဆင့်မြှင့်တင်မှုနှစ်ခုကြားတွင် ကမ္ဘာကြီးသည် လုံးဝတည်ငြိမ်နေသည်။ ပြည်နယ်အဆင့်မြှင့်တင်မှုနှုန်း နိမ့်ပါက၊ လှုပ်ရှားမှုများသည် အလွန်တုန်လှုပ်သွားမည်ဖြစ်သည်။

ဤပြဿနာ၏သက်ရောက်မှုကို လျှော့ချရန် နည်းလမ်းများစွာရှိပြီး၊ ၎င်းတို့ကို နောက်အပိုင်းတွင် ဖော်ပြပါမည်။

Latency Smoothing နည်းပညာများ

ဤကဏ္ဍတွင်ဖော်ပြထားသည့် နည်းပညာအားလုံးကို စီးရီးတွင် အသေးစိတ်ဆွေးနွေးထားသည်။ လျင်မြန်သောကစားသူအများအပြား Gabriel Gambetta ဤအလွန်ကောင်းမွန်သော ဆောင်းပါးတွဲများကို ဖတ်ရန် အထူးအကြံပြုလိုပါသည်။ ၎င်းတွင် ဤနည်းပညာများသည် လက်တွေ့တွင် မည်သို့အလုပ်လုပ်သည်ကို သင်မြင်နိုင်စေသည့် အပြန်အလှန်အကျိုးသက်ရောက်မှုရှိသော ဒီမိုတစ်ခုလည်း ပါဝင်သည်။

ပထမနည်းလမ်းမှာ ဆာဗာထံမှ တုံ့ပြန်မှုကို မစောင့်ဆိုင်းဘဲ ထည့်သွင်းခြင်းရလဒ်ကို တိုက်ရိုက်အသုံးပြုခြင်းဖြစ်သည်။ အဲ့ဒါကိုခေါ်တယ် client-side ခန့်မှန်းချက်. သို့သော်၊ ကလိုင်းယင့်သည် ဆာဗာမှ အပ်ဒိတ်တစ်ခုကို လက်ခံရရှိသောအခါ၊ ၎င်း၏ ခန့်မှန်းချက်သည် မှန်ကန်ကြောင်း အတည်ပြုရပါမည်။ ထိုသို့မဟုတ်ပါက ဆာဗာသည် အာဏာရှင်ဆန်သောကြောင့် ဆာဗာမှရရှိသည့်အရာအတိုင်း သူ၏ပြည်နယ်ကို ပြောင်းလဲရန် လိုအပ်ပါသည်။ ဤနည်းပညာကို Quake တွင်ပထမဆုံးအသုံးပြုခဲ့သည်။ ၎င်းအကြောင်းကို ဆောင်းပါးတွင် သင်ပိုမိုဖတ်ရှုနိုင်ပါသည်။ Quake Engine ကုဒ်ပြန်လည်သုံးသပ်ခြင်း။ Fabien Sanglars [ဘာသာပြန်ချက် Habre] ပေါ်တွင်။

အဆင့်မြှင့်တင်မှုနှစ်ခုကြားရှိ အခြားအရာများ၏ ရွေ့လျားမှုကို ချောမွေ့စေရန် ဒုတိယနည်းလမ်းများကို အသုံးပြုသည်။ ဤပြဿနာကိုဖြေရှင်းရန် နည်းလမ်းနှစ်ခုရှိသည်။ ပေါင်းစည်းခြင်းကိစ္စတွင်၊ နောက်ဆုံးပြည်နယ်နှစ်ခုကို ယူထားပြီး တစ်ခုမှတစ်ခုသို့ ကူးပြောင်းခြင်းကို ပြသထားသည်။ ၎င်း၏အားနည်းချက်မှာ ဖောက်သည်သည် ယခင်ကဖြစ်ပျက်ခဲ့သည်များကို အမြဲမြင်နေရသောကြောင့် နှောင့်နှေးမှုအနည်းငယ်ကို ဖြစ်စေပါသည်။ Extrapolation သည် client မှလက်ခံရရှိသောနောက်ဆုံးအခြေအနေအပေါ်အခြေခံ၍ entities များယခုမည်သည့်နေရာတွင်ရှိသင့်သည်ကိုခန့်မှန်းခြင်းအကြောင်းဖြစ်သည်။ ၎င်း၏အားနည်းချက်မှာ အဖွဲ့အစည်းသည် ရွေ့လျားမှုလမ်းကြောင်းကို လုံးဝပြောင်းလဲသွားပါက၊ ခန့်မှန်းချက်နှင့် ပကတိအနေအထားကြားတွင် ကြီးမားသောအမှားအယွင်းတစ်ခု ရှိလာမည်ဖြစ်သည်။

FPS တွင်သာ အသုံးဝင်သော နောက်ဆုံးပေါ်၊ အဆင့်မြင့်ဆုံးနည်းပညာဖြစ်သည်။ နောက်ကျလျော်ကြေး. lag လျော်ကြေးငွေကိုအသုံးပြုသောအခါ၊ ဆာဗာသည် ပစ်မှတ်ကိုပစ်သောအခါ client ၏နှောင့်နှေးမှုများကို ထည့်သွင်းစဉ်းစားသည်။ ဥပမာအားဖြင့်၊ ကစားသမားတစ်ဦးသည် ၎င်းတို့၏စခရင်ပေါ်တွင် ခေါင်းရိုက်ချက်တစ်ခု ပြုလုပ်ခဲ့သော်လည်း အမှန်တကယ်တွင် ၎င်းတို့၏ပစ်မှတ်သည် နှောင့်နှေးမှုကြောင့် အခြားနေရာတစ်ခု၌ ရှိနေပါက၊ နှောင့်နှေးမှုကြောင့် ကစားသမားအား သတ်ပိုင်ခွင့်ကို ငြင်းပယ်ခြင်းသည် တရားမျှတမည်မဟုတ်ပေ။ ထို့ကြောင့်၊ ကစားသမားသည် ၎င်းတို့၏ဖန်သားပြင်ပေါ်တွင် ကစားသမားမြင်သောအရာကို အတုယူရန်နှင့် ၎င်းတို့၏ပစ်မှတ်နှင့် ပစ်မှတ်ကြားတွင် တိုက်မိခြင်းရှိမရှိ စစ်ဆေးရန် ဆာဗာသည် အချိန်ကို ပြန်ပြန်လှည့်သည်။

Glenn Fiedler သည် ၂၀၀၄ ခုနှစ်တွင် ဆောင်းပါးတစ်ပုဒ်ရေးခဲ့သည်။ ကွန်ရက်ရူပဗေဒ (၂၀၀၄)၊ဆာဗာနှင့် client အကြား ရူပဗေဒဆိုင်ရာ သရုပ်ဖော်မှုများကို ထပ်တူပြုခြင်းအတွက် အုတ်မြစ်ချခဲ့သည်။ 2014 ခုနှစ်တွင်သူသည်စီးရီးအသစ်ဆောင်းပါးများရေးသားခဲ့သည်။ Networking Physicsရူပဗေဒစဥ်းစားမှုများကို ထပ်တူပြုခြင်းအတွက် အခြားနည်းပညာများကို ဖော်ပြထားပါသည်။

Valve wiki တွင် ဆောင်းပါးနှစ်ပုဒ်လည်း ရှိပါသည်။ ရင်းမြစ် Multiplayer Networking и Latency Compensating Methods များတွင် Client/Server In-game Protocol Design and Optimization နှောင့်နှေးမှုအတွက် လျော်ကြေးပေးရန် စဉ်းစားသည်။

လှည့်စားခြင်းမှ ကာကွယ်ခြင်း။

လိမ်လည်ခြင်းကို ကာကွယ်ရန် အဓိက နည်းလမ်း နှစ်ခုရှိသည်။

ပထမအချက်- လှည့်စားသူများသည် အန္တရာယ်ရှိသော ထုပ်ပိုးမှုများကို ပေးပို့ရန် ပိုမိုခက်ခဲစေသည်။ အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ ၎င်းကိုအကောင်အထည်ဖော်ရန် နည်းလမ်းကောင်းမှာ ကုဒ်ဝှက်ခြင်းဖြစ်ပါသည်။

ဒုတိယ- အာဏာရှင်ဆာဗာသည် အမိန့်များ/ထည့်သွင်းမှု/လုပ်ဆောင်ချက်များကိုသာ လက်ခံသင့်သည်။ ထည့်သွင်းပေးပို့ခြင်းမှလွဲ၍ သုံးစွဲသူသည် ဆာဗာပေါ်ရှိ အခြေအနေအား ပြောင်းလဲနိုင်မည်မဟုတ်ပေ။ ထို့နောက် ဆာဗာမှ ထည့်သွင်းမှုကို လက်ခံရရှိသည့်အခါတိုင်း၊ ၎င်းကို အသုံးမပြုမီ ၎င်းသည် မှန်ကန်မှုရှိမရှိ စစ်ဆေးရပါမည်။

အသုံးချယုတ္တိဗေဒ- နိဂုံးချုပ်

client နှင့် server သည် တူညီသောကွန်ပျူတာပေါ်တွင် အလုပ်လုပ်နေချိန်၌ပင် သင့်ဂိမ်း၏အပြုအမူကို မကောင်းသောအခြေအနေများတွင် စမ်းသပ်နိုင်စေရန် မြင့်မားသော latency နှင့် low refresh rate များကို အတုယူရန် နည်းလမ်းတစ်ခုကို အကောင်အထည်ဖော်ရန် အကြံပြုလိုပါသည်။ ၎င်းသည် နှောင့်နှေးချောမွေ့စေသည့် နည်းပညာများကို အကောင်အထည်ဖော်ရာတွင် များစွာရိုးရှင်းစေသည်။

အခြားအထောက်အကူဖြစ်စေသောအရင်းအမြစ်များ

ကွန်ရက်မော်ဒယ်များတွင် အခြားအရင်းအမြစ်များကို ရှာဖွေလိုပါက ၎င်းတို့ကို ဤနေရာတွင် ရှာတွေ့နိုင်သည်-

• Glenn Fiedler ၏ဘလော့ - သူ့ဘလော့ဂ်တစ်ခုလုံး ဖတ်ရကျိုးနပ်ပါတယ်၊ အဲဒီမှာ ဆောင်းပါးကောင်းတွေ အများကြီးရှိတယ်။ ဒါဟာဖြစ်ပါတယ် ကွန်ရက်နည်းပညာဆိုင်ရာ ဆောင်းပါးများအားလုံးကို စုစည်းထားသည်။
• အမိုက်စားဂိမ်းကွန်ရက်ချိတ်ဆက်ခြင်း။ M. Fatih MAR မှ အွန်လိုင်းဗီဒီယိုဂိမ်းအင်ဂျင်များပေါ်ရှိ ပြည့်စုံသော ဆောင်းပါးများနှင့် ဗီဒီယိုများစာရင်းဖြစ်သည်။
• В r/gamedev subreddit ၏ wiki အသုံးဝင်တဲ့ link တွေလည်း အများကြီးရှိပါတယ်။

source: www.habr.com