ڪيئن اسان هڪ نيٽ ورڪ ويڪرائي معاوضي الورورٿم سان هڪ موبائل شوٽر لاءِ بيلسٽڪ حسابن جي ميڪنڪس کي وڌايو

هيلو، مان نيڪيتا برزڪ آهيان، Pixonic کان هڪ سرور ڊولپر. اڄ آئون ڳالهائڻ چاهيندس موبائيل ملٽي پليئر ۾ دير جي معاوضي جي باري ۾.

ڪيترائي مضمون لکيا ويا آهن سرور جي وقفي جي معاوضي بابت، بشمول روسي ۾. اها تعجب جي ڳالهه ناهي، ڇو ته هي ٽيڪنالاجي 90 جي ڏهاڪي کان وٺي multiplayer FPS جي پيدائش ۾ فعال طور تي استعمال ڪيو ويو آهي. مثال طور، توهان ياد ڪري سگهو ٿا QuakeWorld موڊ، جيڪو ان کي استعمال ڪرڻ وارن مان پهريون هو.

اسان ان کي اسان جي موبائل ملٽي پليئر شوٽر ڊينو اسڪواڊ ۾ پڻ استعمال ڪندا آهيون.

هن آرٽيڪل ۾، منهنجو مقصد اهو نه آهي ته ٻيهر ورجايو جيڪو اڳ ۾ ئي هزار ڀيرا لکيو ويو آهي، پر اهو ٻڌائڻ لاء ته اسان ڪيئن اسان جي راند ۾ وقف معاوضي تي عمل ڪيو، اسان جي ٽيڪنالاجي اسٽيڪ ۽ بنيادي راند جي خاصيتن کي حساب ۾ رکندي.

اسان جي cortex ۽ ٽيڪنالاجي جي باري ۾ چند لفظ.

ڊنو اسڪواڊ هڪ نيٽ ورڪ موبائل PvP شوٽر آهي. رانديگر مختلف قسم جي هٿيارن سان ليس ڊائناسور کي سنڀاليندا آهن ۽ 6v6 ٽيمن ۾ هڪ ٻئي سان وڙهندا آهن.

ٻئي ڪلائنٽ ۽ سرور اتحاد تي ٻڌل آهن. آرڪيٽيڪچر شوٽرن لاءِ ڪافي کلاسک آهي: سرور بااختيار آهي، ۽ ڪلائنٽ جي اڳڪٿي ڪلائنٽ تي ڪم ڪري ٿي. راند جي تخليق ان-هاؤس ECS استعمال ڪندي لکيو ويو آهي ۽ سرور ۽ ڪلائنٽ ٻنهي تي استعمال ٿيندو آهي.

جيڪڏهن اهو پهريون ڀيرو آهي ته توهان دير جي معاوضي بابت ٻڌو آهي، هتي مسئلو ۾ هڪ مختصر سفر آهي.

ملٽي پليئر FPS راندين ۾، ميچ عام طور تي ريموٽ سرور تي ٺهيل آهي. رانديگر پنهنجو انپٽ موڪليندا آهن (دٻايل چاٻين بابت معلومات) سرور ڏانهن، ۽ جواب ۾ سرور انهن کي موڪلي ٿو هڪ تازه ڪاري راند جي حالت جيڪا وصول ڪيل ڊيٽا کي مدنظر رکندي. هن رابطي واري اسڪيم سان، فارورڊ ڪيٻي کي دٻائڻ جي وچ ۾ دير ۽ پليئر جي ڪردار جي اسڪرين تي هلڻ واري لمحي هميشه پنگ کان وڌيڪ هوندي.

جڏهن ته مقامي نيٽ ورڪن تي هي دير (مشهور طور تي انپٽ ليگ سڏيو ويندو آهي) شايد قابل اطمينان نه هجي، جڏهن انٽرنيٽ ذريعي کيڏڻ دوران اهو "برف تي سلائيڊنگ" جو احساس پيدا ڪري ٿو جڏهن هڪ ڪردار کي سنڀاليندو آهي. اهو مسئلو موبائل نيٽ ورڪن لاءِ ٻيڻو لاڳاپو آهي، جتي اهو معاملو جڏهن پليئر جو پنگ 200 ايم ايس آهي تڏهن به هڪ بهترين ڪنيڪشن سمجهيو ويندو آهي. گهڻو ڪري پنگ 350، 500، يا 1000 ايم ايس ٿي سگهي ٿو. ان کان پوء اهو لڳ ڀڳ ناممڪن ٿي وڃي ٿو هڪ فاسٽ شوٽر کيڏڻ ان پٽ جي وقف سان.

ھن مسئلي جو حل آھي ڪلائنٽ-سائيڊ سموليشن اڳڪٿي. هتي ڪلائنٽ پاڻ ان پٽ کي پليئر جي ڪردار تي لاڳو ڪري ٿو، بغير سرور جي جواب جي انتظار ۾. ۽ جڏهن جواب ملي ٿو، اهو صرف نتيجن جو مقابلو ڪري ٿو ۽ مخالفين جي پوزيشن کي اپڊيٽ ڪري ٿو. هن معاملي ۾ هڪ چيڪ کي دٻائڻ ۽ اسڪرين تي نتيجو ڏيکارڻ جي وچ ۾ دير گهٽ ۾ گهٽ آهي.

اهو ضروري آهي ته هتي nuance کي سمجهڻ: ڪلائنٽ هميشه پنهنجي آخري ان پٽ جي مطابق پاڻ کي ڇڪيندو آهي، ۽ دشمنن - نيٽ ورڪ جي دير سان، سرور جي ڊيٽا جي پوئين حالت جي مطابق. اهو آهي، جڏهن هڪ دشمن تي فائرنگ ڪري، پليئر کيس ماضي ۾ پاڻ سان واسطو رکي ٿو. ڪلائنٽ جي اڳڪٿي بابت وڌيڪ اسان اڳ ۾ لکيو آهي.

اهڙيء طرح، ڪلائنٽ جي اڳڪٿي هڪ مسئلو حل ڪري ٿو، پر ٻيو پيدا ڪري ٿو: جيڪڏهن هڪ پليئر ان نقطي تي فائرنگ ڪري ٿو جتي دشمن ماضي ۾ هو، سرور تي جڏهن ساڳئي نقطي تي شوٽنگ ڪري، دشمن شايد ان جاء تي نه هجي. سرور وقف معاوضي هن مسئلي کي حل ڪرڻ جي ڪوشش ڪري ٿو. جڏهن هڪ هٿيار فائر ڪيو ويندو آهي، سرور راند جي حالت کي بحال ڪري ٿو ته پليئر شاٽ جي وقت مقامي طور تي ڏٺو، ۽ چيڪ ڪري ٿو ته ڇا هو واقعي دشمن کي ماري سگهي ٿو. جيڪڏهن جواب آهي "ها،" هٽ ڳڻيو ويندو آهي، جيتوڻيڪ دشمن ان وقت سرور تي نه آهي.

هن علم سان هٿياربند، اسان ڊنو اسڪواڊ ۾ سرور لئگ معاوضي تي عمل ڪرڻ شروع ڪيو. سڀ کان پهريان، اسان کي اهو سمجهڻو پوندو ته سرور تي ڪيئن بحال ڪجي ته ڪلائنٽ ڇا ڏٺو؟ ۽ ڇا واقعي بحال ڪرڻ جي ضرورت آهي؟ اسان جي راند ۾، هٿيارن ۽ قابليتن جي مارن کي ريڪاسٽ ۽ اوورليز ذريعي ڳڻيو ويندو آهي - اهو آهي، دشمن جي جسماني ٽڪرين سان رابطي جي ذريعي. ان جي مطابق، اسان کي انهن ٽڪرين جي پوزيشن کي ٻيهر پيدا ڪرڻ جي ضرورت آهي، جيڪو پليئر "ڏٺو" مقامي طور تي، سرور تي. ان وقت اسان يونٽي ورزن 2018.x استعمال ڪري رهيا هئاسين. فزڪس API اتي جامد آهي، جسماني دنيا هڪ واحد ڪاپي ۾ موجود آهي. ان جي رياست کي بچائڻ ۽ پوء ان کي دٻي مان بحال ڪرڻ جو ڪو طريقو ناهي. پوءِ ڇا ڪجي؟

حل مٿاڇري تي هو؛ ان جا سڀئي عنصر اڳ ۾ ئي اسان طرفان استعمال ڪيا ويا هئا ٻين مسئلن کي حل ڪرڻ لاء:

1. هر ڪلائنٽ لاء، اسان کي ڄاڻڻ جي ضرورت آهي ته هن وقت هن مخالفين کي ڏٺو جڏهن هن چابيون کي دٻايو. اسان اڳ ۾ ئي هن معلومات کي ان پٽ پيڪيج ۾ لکيو آهي ۽ ان کي استعمال ڪيو آهي ڪلائنٽ جي اڳڪٿي کي ترتيب ڏيڻ لاءِ.
2. اسان کي راندين جي رياستن جي تاريخ کي ذخيرو ڪرڻ جي ضرورت آهي. اهو ان ۾ آهي ته اسان پنهنجن مخالفن جي پوزيشن کي رکون ٿا (۽ تنهن ڪري انهن جي ٽوليندڙ). اسان وٽ اڳ ۾ ئي سرور تي رياست جي تاريخ هئي، اسان ان کي تعمير ڪرڻ لاء استعمال ڪيو ڊيلٽا. صحيح وقت ڄاڻڻ سان، اسان تاريخ ۾ صحيح رياست کي آساني سان ڳولي سگهون ٿا.
3. هاڻي ته اسان وٽ تاريخ کان راند جي رياست هٿ ۾ آهي، اسان کي پليئر ڊيٽا کي جسماني دنيا جي حالت سان هم وقت سازي ڪرڻ جي ضرورت آهي. موجوده ٽوليندڙ - ھلڻ، غائب آھن - ٺاھيو، غير ضروري آھن - تباھ. هي منطق اڳ ۾ ئي لکيو ويو هو ۽ ڪيترن ئي ECS سسٽم تي مشتمل هو. اسان ان کي استعمال ڪيو ڪيترن ئي راندين جا ڪمرا ھڪڙي اتحاد جي عمل ۾. ۽ جيئن ته جسماني دنيا هڪ في عمل آهي، ان کي ڪمرن جي وچ ۾ ٻيهر استعمال ڪرڻو پوندو. تخليق جي هر ٽڪ کان اڳ، اسان جسماني دنيا جي حالت کي "ري سيٽ" ڪيو ۽ ان کي موجوده ڪمري جي ڊيٽا سان ٻيهر شروع ڪيو، ڪوشش ڪري رهيا آهيون يونٽي راند جي شين کي وڌيڪ استعمال ڪرڻ جي ڪوشش هڪ چالاڪ پولنگ سسٽم ذريعي. اهو سڀ ڪجهه رهي رهيو هو ته ماضي کان راند جي رياست لاءِ ساڳئي منطق کي دعوت ڏيڻ.

انهن سڀني عنصرن کي گڏ ڪرڻ سان، اسان کي هڪ "ٽائم مشين" ملي ٿي جيڪا جسماني دنيا جي حالت کي صحيح وقت ڏانهن واپس آڻي سگهي ٿي. ڪوڊ سادو نڪتو:

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;
     }
}

اهو سڀ ڪجهه اهو معلوم ڪرڻ هو ته هن مشين کي آساني سان شاٽ ۽ قابليت جي معاوضي لاءِ ڪيئن استعمال ڪجي.

سادي صورت ۾، جڏهن ميڪيڪل هڪ واحد هٽ اسڪين تي ٻڌل هوندا آهن، هر شي واضح ٿيڻ لڳي: پليئر شوٽ ڪرڻ کان اڳ، هن کي جسماني دنيا کي گهربل حالت ڏانهن موٽڻ جي ضرورت آهي، ري ڪاسٽ ڪرڻ، هٽ يا مس کي ڳڻڻ، ۽ دنيا کي شروعاتي حالت ڏانهن واپس آڻيو.

پر ڊنو اسڪواڊ ۾ تمام ٿورڙا اهڙا ميڪيڪل آهن! راند ۾ اڪثر هٿيار پروجيڪٽائل ٺاهيندا آهن - ڊگھي زندگي واريون گوليون جيڪي ڪيترن ئي نقلي ٽڪن لاءِ اڏامندا آهن (ڪجهه ڪيسن ۾، درجن جي تعداد ۾). انهن سان ڇا ڪجي، اهي ڪهڙي وقت پرواز ڪن؟

В قديم مضمون هاف لائف نيٽ ورڪ اسٽيڪ جي باري ۾، والو جي ماڻهن هڪ ئي سوال پڇيو، ۽ انهن جو جواب هي هو: پروجيڪٽ ليگ معاوضو مسئلو آهي، ۽ ان کان بچڻ بهتر آهي.

اسان وٽ هي اختيار نه هو: پروجيڪٽ تي ٻڌل هٿيار راند جي ڊيزائن جي هڪ اهم خصوصيت هئي. تنهنڪري اسان کي ڪجهه وٺڻو پيو. ٿورڙي دماغي طوفان کان پوء، اسان ٻه اختيار ٺاهيا جيڪي ڪم ڪرڻ لڳي:

1. اسان پروجيڪٽ کي پليئر جي وقت سان ڳنڍيندا آهيون جيڪو ان کي پيدا ڪيو. سرور سموليشن جي هر ٽڪ، هر پليئر جي هر بلٽ لاءِ، اسان جسماني دنيا کي ڪلائنٽ اسٽيٽ ڏانهن واپس آڻينداسين ۽ ضروري حساب ڪتاب ڪندا آهيون. هن طريقي سان اهو ممڪن ٿيو ته سرور تي ورهايل لوڊ ۽ پروجيڪٽ جي متوقع پرواز جو وقت. اڳڪٿي ڪرڻ خاص طور تي اسان لاءِ اهم هئي، ڇاڪاڻ ته اسان وٽ سڀ پروجيڪٽ آهن، جن ۾ دشمن جي پروجيڪٽس شامل آهن، ڪلائنٽ تي اڳڪٿي ڪئي وئي آهي.

تصوير ۾، ٽڪ 30 تي پليئر توقع ۾ هڪ ميزائل فائر ڪري ٿو: هو ڏسي ٿو ته دشمن ڪهڙي طرف هلي رهيو آهي ۽ ميزائل جي لڳ ڀڳ رفتار کي ڄاڻي ٿو. مقامي طور تي هو ڏسي ٿو ته هن ٽارگيٽ کي 33 هين ٽڪ تي ماريو. دير جي معاوضي جي مهرباني، اهو پڻ سرور تي ظاهر ٿيندو

2. اسان سڀ ڪجھ ائين ئي ڪندا آهيون جيئن پهرين آپشن ۾ ڪيو ويو آهي، پر، بلٽ سميوليشن جي هڪ ٽڪ ڳڻڻ کان پوءِ، اسان نه روڪيون ٿا، پر ان جي اڏام کي هڪ ئي سرور ٽڪ جي اندر سميوليٽ ڪرڻ جاري رکون ٿا، هر ڀيري پنهنجو وقت سرور جي ويجهو آڻيندي. هڪ هڪ ڪري ٽڪ ۽ تازه ڪاري ڪرڻ واري پوزيشن. اسان اهو ڪندا آهيون جيستائين ٻن شين مان هڪ ٿئي ٿي:

• گولي ختم ٿي وئي آهي. ان جو مطلب اهو ٿيو ته حساب ختم ٿي چڪو آهي، اسان هڪ مس يا هٽ کي ڳڻپ ڪري سگهون ٿا. ۽ هي ان ئي ٽڪر تي آهي جنهن ۾ گوليون هلايون ويون هيون! اسان لاءِ هي پلس ۽ مائنس ٻئي هو. هڪ پلس - ڇاڪاڻ ته شوٽنگ پليئر لاءِ ، هن خاص طور تي مار ۽ دشمن جي صحت ۾ گهٽتائي جي وچ ۾ دير کي گهٽائي ڇڏيو. نقصان اهو آهي ته اهو ساڳيو اثر ڏٺو ويو جڏهن مخالفين پليئر تي فائرنگ ڪئي: دشمن، اهو لڳي ٿو، صرف هڪ سست راڪيٽ فائر ڪيو، ۽ نقصان اڳ ۾ ئي شمار ڪيو ويو آهي.
• بلٽ سرور وقت تي پهچي چڪو آهي. انهي صورت ۾، ان جي تخليق ايندڙ سرور ۾ بغير ڪنهن دير جي معاوضي جي جاري رهندي. سست پروجيڪٽائلز لاءِ، هي نظرياتي طور تي پهرين آپشن جي مقابلي ۾ فزڪس رول بيڪ جو تعداد گهٽائي سگهي ٿو. ساڳئي وقت، سموليشن تي اڻ برابري لوڊ وڌي وئي: سرور يا ته بيڪار هو، يا هڪ سرور ٽِڪ ۾ اهو ڪيترن ئي گولن لاءِ درجن جي سميوليشن ٽڪ جو حساب ڪري رهيو هو.

ساڳيو منظر جيئن پوئين تصوير ۾، پر ٻئي منصوبي جي حساب سان. ميزائل ”پڪڙجي ويو“ سرور وقت سان گڏ ساڳئي ٽِڪ تي جنهن شاٽ لڳي، ۽ مار کي ايندڙ ٽِڪ جي شروعات ۾ شمار ڪري سگهجي ٿو. 31 هين ٽڪ تي، هن معاملي ۾، دير جو معاوضو هاڻي لاڳو ناهي

اسان جي عمل ۾، اهي ٻه طريقا صرف ڪوڊ جي ٻن لائينن ۾ مختلف هئا، تنهنڪري اسان ٻنهي کي ٺاهيو، ۽ هڪ ڊگهي وقت تائين اهي متوازي طور تي موجود هئا. هٿيارن جي ميخانيات ۽ گولي جي رفتار تي مدار رکندي، اسان هر ڊائناسور لاء هڪ يا ٻيو اختيار چونڊيو آهي. هتي جو موڙ اهو هو ته ميڪنڪس جي راند ۾ ظاهر ٿيو جيئن ”جيڪڏهن توهان دشمن کي ڪيترائي ڀيرا اهڙي ۽ اهڙي وقت ۾ ماريو ته فلاڻي ۽ اهڙي بونس حاصل ڪريو. ڪنهن به ميڪيڪل جتي پليئر دشمن کي مارڻ وقت هڪ اهم ڪردار ادا ڪيو، ٻئي طريقي سان ڪم ڪرڻ کان انڪار ڪيو. تنهنڪري اسان پهرين اختيار سان وڃڻ ختم ڪيو، ۽ اهو هاڻي لاڳو ٿئي ٿو سڀني هٿيارن ۽ راند ۾ سڀني فعال صلاحيتن تي.

الڳ الڳ، اهو ڪارڪردگي جي مسئلي کي وڌائڻ جي قابل آهي. جيڪڏهن توهان سوچيو ته اهو سڀ شيون سست ٿي وينديون، مان جواب ڏيان ٿو: اهو آهي. اتحاد colliders کي حرڪت ۾ ۽ انهن کي بند ڪرڻ ۽ بند ڪرڻ ۾ ڪافي سست آهي. ڊنو اسڪواڊ ۾، ”بدترين صورت“ واري صورتحال ۾، جنگ ۾ هڪ ئي وقت ڪيترائي سو پروجائل موجود هوندا. هر پروجيڪٽ کي انفرادي طور تي ڳڻڻ لاءِ ڪليڊر کي منتقل ڪرڻ هڪ ناقابل برداشت عيش آهي. تنهن ڪري، اهو بلڪل ضروري هو ته اسان فزڪس جي "رول بيڪ" جي تعداد کي گھٽائڻ لاء. هن کي ڪرڻ لاء، اسان ECS ۾ هڪ الڳ جزو ٺاهيو جنهن ۾ اسان پليئر جي وقت کي رڪارڊ ڪيو. اسان ان کي سڀني ادارن ۾ شامل ڪيو جن کي دير جي معاوضي جي ضرورت آهي (منصوبا، قابليت، وغيره). ان کان اڳ جو اسان اهڙن ادارن کي پروسيس ڪرڻ شروع ڪريون، اسان انهن کي هن وقت تائين ڪلستر ڪريون ٿا ۽ انهن کي گڏ ڪريون ٿا، هر ڪلستر لاء هڪ ڀيرو جسماني دنيا کي واپس آڻيندي.

هن مرحلي تي اسان وٽ عام طور تي ڪم ڪندڙ نظام آهي. ان جو ڪوڊ ڪجھ آسان فارم ۾:

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);
               }
          }
     }
}

باقي رهيل تفصيلن کي ترتيب ڏيڻ لاءِ:

1. سمجھو ته وقت ۾ حرڪت جي وڌ ۾ وڌ فاصلي کي ڪيترو محدود ڪيو وڃي.

اهو ضروري هو ته اسان جي لاءِ راند کي ممڪن حد تائين پهچندڙ موبائيل نيٽ ورڪن جي خراب حالتن ۾، ان ڪري اسان ڪهاڻي کي 30 ٽِڪس جي مارجن سان محدود ڪيو (20 هز جي ٽِڪ جي شرح سان). هي رانديگرن کي مخالفن کي مارڻ جي اجازت ڏئي ٿو جيتوڻيڪ تمام تيز پنگ تي.

2. اندازو لڳايو ته ڪهڙيون شيون وقت ۾ منتقل ٿي سگهن ٿيون ۽ ڪهڙيون نه ٿيون.

اسان، يقينا، اسان جي مخالفين کي منتقل ڪري رهيا آهيون. پر انسٽال ٿيل توانائي ڍال، مثال طور، نه آهن. اسان فيصلو ڪيو ته اهو بهتر هو ته دفاعي صلاحيت کي ترجيح ڏني وڃي، جيئن اڪثر آن لائن شوٽرز ۾ ڪيو ويندو آهي. جيڪڏهن پليئر اڳ ۾ ئي شيلڊ رکي ڇڏيو آهي، ماضي کان وقفي معاوضي واريون گوليون ان ذريعي نه اڏڻ گهرجن.

3. فيصلو ڪيو ته ڇا اهو ضروري آهي ته ڊائناسور جي قابليت کي معاوضو ڏيڻ: ڪنگڻ، دم جي هڙتال، وغيره. اسان فيصلو ڪيو ته ڪهڙي ضرورت هئي ۽ انهن کي گولين وانگر ساڳيو قاعدن مطابق عمل ڪيو.

4. طئي ڪيو ته ڇا ڪجي پليئر جي ڪليڊرز سان جن لاءِ وقفو معاوضو ادا ڪيو پيو وڃي. سٺي طريقي سان، انهن جي پوزيشن ماضي ۾ تبديل نه ٿيڻ گهرجي: پليئر پاڻ کي ساڳئي وقت ڏسڻ گهرجي جنهن ۾ هو هاڻي سرور تي آهي. تنهن هوندي، اسان شوٽنگ پليئر جي ٽڪرين کي به واپس آڻينداسين، ۽ هن جا ڪيترائي سبب آهن.

پهريون، اهو ڪلسترنگ کي بهتر بڻائي ٿو: اسان سڀني رانديگرن لاءِ ساڳي جسماني حالت استعمال ڪري سگهون ٿا ويجهي پنگ سان.

ٻيو، سڀني رينڪاسٽس ۽ اوورليپ ۾ اسان هميشه پليئر جي ٽڪرين کي خارج ڪندا آهيون جيڪي قابليت يا پروجيڪٽ جو مالڪ آهن. ڊينو اسڪواڊ ۾، رانديگر ڊائناسورن کي سنڀاليندا آهن، جن وٽ شوٽر معيارن جي بجاءِ غير معياري جاميٽري هوندي آهي. توڙي جو رانديگر هڪ غير معمولي زاويه تي گول ڪري ٿو ۽ گولي جو پيچرو پليئر جي ڊائناسور ڪليڊر مان گذري ٿو، گولي ان کي نظر انداز ڪندي.

ٽيون، اسان ڊيناسور جي هٿيارن جي پوزيشن يا اي سي ايس جي ڊيٽا کي استعمال ڪرڻ جي صلاحيت جي نقطي جو اندازو لڳايو، جيتوڻيڪ دير جي معاوضي جي شروعات کان اڳ.

نتيجي طور، لانگ معاوضي واري پليئر جي ٽڪرين جي حقيقي پوزيشن اسان لاء غير ضروري آهي، تنهنڪري اسان هڪ وڌيڪ پيداوار ۽ ساڳئي وقت آسان رستو اختيار ڪيو.

نيٽ ورڪ جي ويڪرائي کي آساني سان ختم نٿو ڪري سگهجي، اهو صرف نقاب ٿي سگهي ٿو. لڪائڻ جي ڪنهن ٻئي طريقي وانگر، سرور جي وقفي جي معاوضي ۾ ان جا واپار آهن. اهو پليئر جي گیمنگ تجربو کي بهتر بڻائي ٿو جيڪو شوٽنگ ڪري رهيو آهي پليئر جي خرچ تي شاٽ ٿيڻ تي. ڊينو اسڪواڊ لاءِ، جيتوڻيڪ، هتي جو انتخاب واضح هو.

يقينن، اهو سڀ ڪجهه ادا ڪرڻو پوندو هو مجموعي طور تي سرور ڪوڊ جي وڌندڙ پيچيدگي جي ڪري - ٻئي پروگرامرز ۽ گيم ڊيزائنرز لاءِ. جيڪڏهن اڳ ۾ سموليشن سسٽم جي هڪ سادي ترتيب واري ڪال هئي، پوء دير جي معاوضي سان، ان ۾ نسٽڊ لوپ ۽ شاخون ظاهر ٿيا. اسان ان سان گڏ ڪم ڪرڻ آسان بڻائڻ لاءِ تمام گهڻي ڪوشش پڻ ڪئي.

2019 ورزن ۾ (۽ شايد ٿورو اڳ)، اتحاد شامل ڪيو مڪمل سپورٽ آزاد جسماني مناظر لاءِ. اسان انهن کي سرور تي لڳ ڀڳ فوري طور تي اپڊيٽ ڪرڻ کان پوءِ لاڳو ڪيو، ڇاڪاڻ ته اسان چاهيون ٿا ته جلدي جسماني دنيا کان نجات حاصل ڪرڻ لاءِ سڀني ڪمرن لاءِ عام.

اسان هر راند جي ڪمري کي ان جو پنهنجو جسماني منظر ڏنو ۽ اهڙيءَ طرح تخليق کي ڳڻڻ کان اڳ پاڙيسري ڪمري جي ڊيٽا مان منظر کي ”صاف“ ڪرڻ جي ضرورت کي ختم ڪيو. پهرين، ان جي پيداوار ۾ هڪ اهم اضافو ڏنو. ٻيو، اهو ممڪن ڪيو ته پوري طبقي جي ڪيڙن مان نجات حاصل ڪرڻ لاء، جيڪو پيدا ٿيو ته پروگرامر منظر صاف ڪرڻ واري ڪوڊ ۾ غلطي ڪئي جڏهن نئين راند عناصر شامل ڪيو. اهڙين غلطين کي ڊيبگ ڪرڻ ڏکيو هو، ۽ اهي اڪثر ڪري جسماني شيون جي حالت جي نتيجي ۾ هڪ ڪمري جي منظر ۾ "ٻئي" ٻئي ڪمري ۾.

ان کان علاوه، اسان ڪجھ تحقيق ڪئي ته ڇا جسماني منظر جسماني دنيا جي تاريخ کي ذخيرو ڪرڻ لاء استعمال ڪري سگھجن ٿيون. يعني مشروط طور تي، هر ڪمري ۾ هڪ منظر نه، پر 30 منظر، ۽ انهن مان هڪ سائيڪل بفر ٺاهيو، جنهن ۾ ڪهاڻي کي محفوظ ڪيو وڃي. عام طور تي، اختيار ڪم ڪري رهيو آهي، پر اسان ان تي عمل نه ڪيو: اهو پيداوار ۾ ڪا به چريو واڌ نه ڏيکاري، بلڪه خطرناڪ تبديلين جي ضرورت آهي. اهو اڳڪٿي ڪرڻ ڏکيو هو ته سرور ڪيئن ڪم ڪندو جڏهن ڪيترن ئي منظرن سان هڪ ڊگهي وقت تائين ڪم ڪندو. تنهن ڪري، اسان قاعدي جي پيروي ڪئي: "جيڪڏھن اھو ٽٽي نه آھي ، ان کي درست نه ڪريو».

جو ذريعو: www.habr.com