پچھلے دو ہفتوں سے میں اپنے گیم کے لیے آن لائن انجن پر کام کر رہا ہوں۔ اس سے پہلے، میں گیمز میں نیٹ ورکنگ کے بارے میں کچھ نہیں جانتا تھا، اس لیے میں نے بہت سارے مضامین پڑھے اور تمام تصورات کو سمجھنے کے لیے بہت سارے تجربات کیے اور اپنا نیٹ ورکنگ انجن لکھنے کے قابل ہوں۔
اس گائیڈ میں، میں آپ کے ساتھ ان مختلف تصورات کا اشتراک کرنا چاہوں گا جن کی آپ کو اپنا گیم انجن لکھنے سے پہلے سیکھنے کی ضرورت ہے، نیز انہیں سیکھنے کے لیے بہترین وسائل اور مضامین۔
عام طور پر، نیٹ ورک آرکیٹیکچرز کی دو اہم اقسام ہیں: پیئر ٹو پیئر اور کلائنٹ سرور۔ پیئر ٹو پیئر (p2p) فن تعمیر میں، ڈیٹا کو کسی بھی جوڑے سے منسلک کھلاڑیوں کے درمیان منتقل کیا جاتا ہے، جبکہ کلائنٹ-سرور کے فن تعمیر میں، ڈیٹا صرف پلیئرز اور سرور کے درمیان منتقل ہوتا ہے۔
اگرچہ پیئر ٹو پیئر فن تعمیر اب بھی کچھ گیمز میں استعمال کیا جاتا ہے، کلائنٹ سرور معیاری ہے: اسے نافذ کرنا آسان ہے، چینل کی چھوٹی چوڑائی کی ضرورت ہوتی ہے، اور دھوکہ دہی سے حفاظت کرنا آسان بناتا ہے۔ لہذا، اس ٹیوٹوریل میں ہم کلائنٹ سرور کے فن تعمیر پر توجہ مرکوز کریں گے۔
خاص طور پر، ہم آمرانہ سرورز میں سب سے زیادہ دلچسپی رکھتے ہیں: ایسے نظاموں میں، سرور ہمیشہ درست ہوتا ہے۔ مثال کے طور پر، اگر کوئی کھلاڑی سوچتا ہے کہ وہ کوآرڈینیٹس (10، 5) پر ہے، اور سرور اسے بتاتا ہے کہ وہ (5، 3) پر ہے، تو کلائنٹ کو اپنی پوزیشن کو سرور کی طرف سے اطلاع دی گئی پوزیشن سے بدلنا چاہیے، نہ کہ اس کے برعکس مستند سرورز کا استعمال دھوکہ بازوں کی شناخت آسان بناتا ہے۔
نیٹ ورک گیمنگ سسٹم کے تین اہم اجزاء ہوتے ہیں:
- ٹرانسپورٹ پروٹوکول: کلائنٹس اور سرور کے درمیان ڈیٹا کیسے منتقل ہوتا ہے۔
- ایپلیکیشن پروٹوکول: کلائنٹس سے سرور اور سرور سے کلائنٹس میں کیا منتقل ہوتا ہے اور کس شکل میں ہوتا ہے۔
- ایپلیکیشن منطق: کس طرح منتقل شدہ ڈیٹا کلائنٹس اور سرور کی حالت کو اپ ڈیٹ کرنے کے لیے استعمال کیا جاتا ہے۔
ہر حصے کے کردار اور ان سے جڑے چیلنجز کو سمجھنا بہت ضروری ہے۔
ٹرانسپورٹ پروٹوکول
پہلا قدم سرور اور کلائنٹس کے درمیان ڈیٹا کی نقل و حمل کے لیے ایک پروٹوکول کا انتخاب کرنا ہے۔ اس کے لیے دو انٹرنیٹ پروٹوکول ہیں: и . لیکن آپ ان میں سے کسی ایک کی بنیاد پر اپنا ٹرانسپورٹ پروٹوکول بنا سکتے ہیں یا ان کا استعمال کرنے والی لائبریری استعمال کر سکتے ہیں۔
TCP اور UDP کا موازنہ
TCP اور UDP دونوں پر مبنی ہیں۔ . آئی پی ایک پیکٹ کو ذریعہ سے وصول کنندہ تک منتقل کرنے کی اجازت دیتا ہے، لیکن اس بات کی ضمانت نہیں دیتا کہ بھیجا ہوا پیکٹ جلد یا بدیر وصول کنندہ تک پہنچ جائے گا، کہ یہ کم از کم ایک بار اس تک پہنچے گا، اور یہ کہ پیکٹ کی ترتیب صحیح طریقے سے پہنچے گی۔ ترتیب. مزید یہ کہ، ایک پیکٹ صرف ایک محدود مقدار میں ڈیٹا پر مشتمل ہو سکتا ہے، جو قدر کے حساب سے دی گئی ہے۔ .
UDP IP کے اوپر صرف ایک پتلی پرت ہے۔ لہذا، اس کی ایک ہی حدود ہیں. اس کے برعکس، TCP میں بہت سی خصوصیات ہیں۔ یہ غلطی کی جانچ کے ساتھ دو نوڈس کے درمیان ایک قابل اعتماد، منظم کنکشن فراہم کرتا ہے۔ لہذا، TCP بہت آسان ہے اور بہت سے دوسرے پروٹوکولز میں استعمال ہوتا ہے، جیسے , и . لیکن یہ تمام خصوصیات قیمت پر آتی ہیں: .
یہ سمجھنے کے لیے کہ یہ فنکشن کیوں تاخیر کا سبب بن سکتے ہیں، ہمیں یہ سمجھنا ہوگا کہ TCP کیسے کام کرتا ہے۔ جب کوئی بھیجنے والا نوڈ ایک پیکٹ کو وصول کرنے والے نوڈ میں منتقل کرتا ہے، تو اسے ایک تسلیم (ACK) موصول ہونے کی توقع ہوتی ہے۔ اگر ایک خاص وقت کے بعد اسے موصول نہیں ہوتا ہے (کیونکہ پیکٹ یا اعتراف گم ہو گیا تھا، یا کسی اور وجہ سے)، تو یہ پیکٹ کو دوبارہ بھیج دیتا ہے۔ مزید یہ کہ، TCP اس بات کی ضمانت دیتا ہے کہ پیکٹ صحیح ترتیب میں موصول ہوئے ہیں، اس لیے جب تک گم شدہ پیکٹ موصول نہیں ہو جاتا، باقی تمام پیکٹوں پر کارروائی نہیں کی جا سکتی، چاہے وہ وصول کرنے والے میزبان کو پہلے ہی موصول ہو چکے ہوں۔
لیکن جیسا کہ آپ شاید تصور کر سکتے ہیں، ملٹی پلیئر گیمز میں تاخیر بہت اہم ہے، خاص طور پر FPS جیسی ایکشن سے بھرپور انواع میں۔ یہی وجہ ہے کہ بہت سے گیمز اپنے پروٹوکول کے ساتھ UDP کا استعمال کرتے ہیں۔
مقامی UDP پر مبنی پروٹوکول مختلف وجوہات کی بناء پر TCP سے زیادہ موثر ہو سکتا ہے۔ مثال کے طور پر، یہ کچھ پیکٹوں کو قابل اعتماد اور دوسروں کو ناقابل اعتماد کے طور پر نشان زد کر سکتا ہے۔ اس لیے اسے اس بات کی کوئی پرواہ نہیں ہے کہ آیا ناقابل اعتماد پیکٹ وصول کنندہ تک پہنچتا ہے۔ یا یہ متعدد ڈیٹا اسٹریمز پر کارروائی کرسکتا ہے تاکہ ایک اسٹریم میں گم شدہ پیکٹ باقی اسٹریمز کو سست نہ کرے۔ مثال کے طور پر، پلیئر ان پٹ کے لیے ایک تھریڈ اور چیٹ پیغامات کے لیے دوسرا تھریڈ ہو سکتا ہے۔ اگر کوئی چیٹ میسج جو ضروری نہیں ہے گم ہو جاتا ہے، تو یہ ان پٹ کو سست نہیں کرے گا جو ضروری ہے۔ یا ملکیتی پروٹوکول ویڈیو گیم کے ماحول میں زیادہ موثر ہونے کے لیے TCP سے مختلف اعتبار سے عمل درآمد کر سکتا ہے۔
تو، اگر TCP بہت زیادہ بیکار ہے، تو ہم UDP کی بنیاد پر اپنا ٹرانسپورٹ پروٹوکول بنائیں گے؟
یہ تھوڑا زیادہ پیچیدہ ہے۔ اگرچہ TCP گیمنگ نیٹ ورک سسٹمز کے لیے تقریباً سب سے بہتر ہے، لیکن یہ آپ کے مخصوص گیم کے لیے کافی اچھا کام کر سکتا ہے اور آپ کا قیمتی وقت بچا سکتا ہے۔ مثال کے طور پر، ٹرن پر مبنی گیم یا ایسی گیم جو صرف LAN نیٹ ورکس پر کھیلی جا سکتی ہے، جہاں لیٹنسی اور پیکٹ کا نقصان انٹرنیٹ کے مقابلے میں بہت کم ہو سکتا ہے، تاخیر کا مسئلہ نہ ہو۔
ورلڈ آف وارکرافٹ، مائن کرافٹ اور ٹیریریا سمیت بہت سے کامیاب گیمز TCP استعمال کرتے ہیں۔ تاہم، زیادہ تر FPSs اپنے UDP پر مبنی پروٹوکول استعمال کرتے ہیں، لہذا ہم ذیل میں ان کے بارے میں مزید بات کریں گے۔
اگر آپ TCP استعمال کرنے کا فیصلہ کرتے ہیں، تو یقینی بنائیں کہ یہ غیر فعال ہے۔ ، کیونکہ یہ بھیجنے سے پہلے پیکٹوں کو بفر کرتا ہے، جس کا مطلب ہے کہ یہ تاخیر کو بڑھاتا ہے۔
ملٹی پلیئر گیمز کے تناظر میں UDP اور TCP کے درمیان فرق کے بارے میں مزید جاننے کے لیے، آپ Glenn Fiedler کا مضمون پڑھ سکتے ہیں۔ .
اپنا پروٹوکول
تو آپ اپنا ٹرانسپورٹ پروٹوکول بنانا چاہتے ہیں، لیکن نہیں جانتے کہ کہاں سے شروع کرنا ہے؟ آپ خوش قسمت ہیں کیونکہ گلین فیڈلر نے اس بارے میں دو حیرت انگیز مضامین لکھے ہیں۔ آپ کو ان میں بہت سارے سمارٹ خیالات ملیں گے۔
پہلا مضمون 2008، دوسرے سے آسان، 2016. میں تجویز کرتا ہوں کہ آپ بڑی عمر کے ساتھ شروع کریں۔
نوٹ کریں کہ Glenn Fiedler UDP پر مبنی حسب ضرورت پروٹوکول استعمال کرنے کا ایک بڑا حامی ہے۔ اور اس کے مضامین کو پڑھنے کے بعد، آپ شاید اس کی رائے کو اپنائیں گے کہ TCP میں ویڈیو گیمز میں سنگین خامیاں ہیں، اور آپ اپنا پروٹوکول خود نافذ کرنا چاہیں گے۔
لیکن اگر آپ نیٹ ورکنگ میں نئے ہیں تو اپنے آپ پر احسان کریں اور TCP یا لائبریری کا استعمال کریں۔ اپنے ٹرانسپورٹ پروٹوکول کو کامیابی سے نافذ کرنے کے لیے، آپ کو پہلے سے بہت کچھ سیکھنے کی ضرورت ہے۔
نیٹ ورک لائبریریاں
اگر آپ کو TCP سے زیادہ موثر چیز کی ضرورت ہے، لیکن آپ اپنے پروٹوکول کو لاگو کرنے اور بہت زیادہ تفصیل میں جانے کی پریشانی سے گزرنا نہیں چاہتے ہیں، تو آپ نیٹ ورکنگ لائبریری استعمال کر سکتے ہیں۔ ان میں سے بہت سے ہیں:
- گلین فیڈلر
- ، جو اب تعاون یافتہ نہیں ہے، لیکن اس کا ایک کانٹا ایسا لگتا ہے کہ یہ اب بھی فعال ہے۔
- ملٹی پلیئر FPS کے لیے بنائی گئی ایک لائبریری ہے۔
- والو
میں نے ان سب کو آزمایا نہیں ہے، لیکن میں ENet کو ترجیح دیتا ہوں کیونکہ یہ استعمال کرنا آسان اور قابل اعتماد ہے۔ اس کے علاوہ، اس میں واضح دستاویزات اور beginners کے لیے ایک سبق موجود ہے۔
ٹرانسپورٹ پروٹوکول: نتیجہ
خلاصہ کرنے کے لیے: دو اہم ٹرانسپورٹ پروٹوکول ہیں: TCP اور UDP۔ TCP میں بہت سی مفید خصوصیات ہیں: قابل اعتماد، پیکٹ آرڈر پریزرویشن، غلطی کا پتہ لگانا۔ UDP میں یہ سب کچھ نہیں ہے، لیکن TCP نے اپنی نوعیت کے لحاظ سے تاخیر میں اضافہ کیا ہے، جو کچھ گیمز کے لیے ناقابل قبول ہے۔ یعنی، کم تاخیر کو یقینی بنانے کے لیے، آپ UDP پر مبنی اپنا پروٹوکول بنا سکتے ہیں یا ایسی لائبریری کا استعمال کر سکتے ہیں جو UDP پر ٹرانسپورٹ پروٹوکول کو لاگو کرتی ہے اور اسے ملٹی پلیئر ویڈیو گیمز کے لیے موافق بنایا گیا ہے۔
TCP، UDP اور لائبریری کے درمیان انتخاب کئی عوامل پر منحصر ہے۔ سب سے پہلے، کھیل کی ضروریات سے: کیا اسے کم تاخیر کی ضرورت ہے؟ دوم، ایپلیکیشن پروٹوکول کی ضروریات سے: کیا اسے قابل اعتماد پروٹوکول کی ضرورت ہے؟ جیسا کہ ہم اگلے حصے میں دیکھیں گے، ایسا ایپلیکیشن پروٹوکول بنانا ممکن ہے جس کے لیے ایک ناقابل اعتماد پروٹوکول کافی موزوں ہے۔ آخر میں، آپ کو نیٹ ورک انجن ڈویلپر کے تجربے کو بھی مدنظر رکھنا ہوگا۔
میرے پاس دو مشورے ہیں:
- ٹرانسپورٹ پروٹوکول کو جتنا ممکن ہو سکے باقی ایپلیکیشن سے خلاصہ کریں تاکہ تمام کوڈ کو دوبارہ لکھے بغیر اسے آسانی سے تبدیل کیا جا سکے۔
- ضرورت سے زیادہ اصلاح نہ کریں۔ اگر آپ نیٹ ورکنگ کے ماہر نہیں ہیں اور آپ کو اس بات کا یقین نہیں ہے کہ آیا آپ کو اپنی مرضی کے مطابق UDP پر مبنی ٹرانسپورٹ پروٹوکول کی ضرورت ہے، تو آپ TCP یا ایسی لائبریری کے ساتھ شروع کر سکتے ہیں جو قابل اعتماد فراہم کرتی ہو، اور پھر کارکردگی کی جانچ اور پیمائش کریں۔ اگر مسائل پیدا ہوتے ہیں اور آپ کو یقین ہے کہ اس کی وجہ ٹرانسپورٹ پروٹوکول ہے، تو یہ وقت ہو سکتا ہے کہ آپ اپنا ٹرانسپورٹ پروٹوکول بنائیں۔
اس حصے کے آخر میں، میں تجویز کرتا ہوں کہ آپ پڑھیں برائن ہک کی طرف سے، جس میں یہاں زیر بحث بہت سے موضوعات کا احاطہ کیا گیا ہے۔
درخواست پروٹوکول
اب جبکہ ہم کلائنٹس اور سرور کے درمیان ڈیٹا کا تبادلہ کر سکتے ہیں، ہمیں یہ فیصلہ کرنے کی ضرورت ہے کہ کون سا ڈیٹا منتقل کرنا ہے اور کس فارمیٹ میں۔
کلاسک اسکیم یہ ہے کہ کلائنٹ سرور کو ان پٹ یا ایکشن بھیجتے ہیں، اور سرور کلائنٹس کو موجودہ گیم اسٹیٹ بھیجتا ہے۔
سرور پوری حالت نہیں بلکہ ایک فلٹر شدہ حالت بھیجتا ہے جو پلیئر کے قریب واقع ہے۔ وہ تین وجوہات کی بنا پر ایسا کرتا ہے۔ سب سے پہلے، مکمل حالت اتنی بڑی ہو سکتی ہے کہ ہائی فریکوئنسی پر منتقل نہ ہو سکے۔ دوم، کلائنٹس بنیادی طور پر بصری اور آڈیو ڈیٹا میں دلچسپی رکھتے ہیں، کیونکہ گیم کی زیادہ تر منطق گیم سرور پر بنائی جاتی ہے۔ تیسرا، کچھ گیمز میں کھلاڑی کو کچھ ڈیٹا جاننے کی ضرورت نہیں ہوتی، مثال کے طور پر، نقشے کے دوسری طرف دشمن کی پوزیشن، بصورت دیگر وہ پیکٹ سونگھ سکتا ہے اور یہ جان سکتا ہے کہ اسے مارنے کے لیے کہاں جانا ہے۔
سیریلائزیشن
پہلا قدم اس ڈیٹا کو تبدیل کرنا ہے جسے ہم بھیجنا چاہتے ہیں (ان پٹ یا گیم اسٹیٹ) ٹرانسمیشن کے لیے موزوں فارمیٹ میں۔ اس عمل کو کہتے ہیں۔ .
جو سوچ فوراً ذہن میں آتی ہے وہ ہے انسانی پڑھنے کے قابل فارمیٹ، جیسے JSON یا XML کا استعمال کرنا۔ لیکن یہ مکمل طور پر غیر موثر ہو گا اور چینل کا بیشتر حصہ ضائع کر دے گا۔
اس کی بجائے بائنری فارمیٹ استعمال کرنے کی سفارش کی جاتی ہے، جو کہ بہت زیادہ کمپیکٹ ہے۔ یعنی پیکٹ صرف چند بائٹس پر مشتمل ہوں گے۔ یہاں ایک مسئلہ غور طلب ہے۔ ، جو مختلف کمپیوٹرز پر مختلف ہو سکتے ہیں۔
ڈیٹا کو سیریلائز کرنے کے لیے، آپ لائبریری استعمال کر سکتے ہیں، مثال کے طور پر:
- گوگل
- ریت کے طوفان کی کمپنی
- شین گرانٹ اور رینڈولف وورہیز
بس اس بات کو یقینی بنائیں کہ لائبریری پورٹیبل آرکائیوز بناتی ہے اور اس کی پرواہ کرتی ہے۔
ایک متبادل حل یہ ہے کہ اسے خود نافذ کیا جائے؛ یہ خاص طور پر مشکل نہیں ہے، خاص طور پر اگر آپ اپنے کوڈ کے لیے ڈیٹا سینٹرک اپروچ استعمال کرتے ہیں۔ اس کے علاوہ، یہ آپ کو ایسی اصلاح کرنے کی اجازت دے گا جو لائبریری استعمال کرتے وقت ہمیشہ ممکن نہیں ہوتیں۔
گلین فیڈلر نے سیریلائزیشن کے بارے میں دو مضامین لکھے: и .
کمپریشن
کلائنٹس اور سرور کے درمیان منتقل کردہ ڈیٹا کی مقدار چینل کی بینڈوتھ کے ذریعہ محدود ہے۔ ڈیٹا کمپریشن آپ کو ہر اسنیپ شاٹ میں مزید ڈیٹا منتقل کرنے، اپ ڈیٹ کی فریکوئنسی بڑھانے، یا صرف چینل کی ضروریات کو کم کرنے کی اجازت دے گا۔
بٹ پیکیجنگ
پہلی تکنیک بٹ پیکنگ ہے۔ یہ بٹس کی بالکل تعداد استعمال کرنے پر مشتمل ہے جو مطلوبہ قدر کو بیان کرنے کے لیے ضروری ہیں۔ مثال کے طور پر، اگر آپ کے پاس ایک اینوم ہے جس کی 16 مختلف قدریں ہوسکتی ہیں، تو پورے بائٹ (8 بٹس) کے بجائے، آپ صرف 4 بٹس استعمال کرسکتے ہیں۔
Glenn Fiedler مضمون کے دوسرے حصے میں اس کو نافذ کرنے کا طریقہ بتاتے ہیں۔ .
بٹ پیکنگ نمونے لینے کے ساتھ خاص طور پر اچھی طرح سے کام کرتی ہے، جو اگلے حصے کا موضوع ہو گا۔
نمونے لینے
ایک نقصان دہ کمپریشن تکنیک ہے جو کسی قدر کو انکوڈ کرنے کے لیے ممکنہ اقدار کا صرف ذیلی سیٹ استعمال کرتی ہے۔ ڈسکریٹائزیشن کو لاگو کرنے کا سب سے آسان طریقہ فلوٹنگ پوائنٹ نمبروں کو گول کرنا ہے۔
Glenn Fiedler (دوبارہ!) اپنے مضمون میں نمونے لینے کو عملی جامہ پہنانے کا طریقہ دکھاتا ہے۔ .
کمپریشن الگورتھم
اگلی تکنیک نقصان کے بغیر کمپریشن الگورتھم ہوگی۔
یہاں، میری رائے میں، تین سب سے دلچسپ الگورتھم ہیں جو آپ کو جاننے کی ضرورت ہے:
- پہلے سے گنتی والے کوڈ کے ساتھ، جو کہ انتہائی تیز ہے اور اچھے نتائج دے سکتا ہے۔ یہ Quake3 نیٹ ورکنگ انجن میں پیکٹوں کو کمپریس کرنے کے لیے استعمال کیا جاتا تھا۔
- ایک عام مقصد کا کمپریشن الگورتھم ہے جو کبھی بھی ڈیٹا کی مقدار میں اضافہ نہیں کرتا ہے۔ آپ کیسے دیکھ سکتے ہیں ، یہ متعدد ایپلی کیشنز میں استعمال کیا گیا ہے۔ ریاستوں کو اپ ڈیٹ کرنے کے لیے یہ بے کار ہو سکتا ہے۔ لیکن یہ مفید ہو سکتا ہے اگر آپ کو سرور سے کلائنٹس کو اثاثے، طویل متن یا خطہ بھیجنے کی ضرورت ہو۔
- - یہ شاید سب سے آسان کمپریشن الگورتھم ہے، لیکن یہ کچھ مخصوص قسم کے ڈیٹا کے لیے بہت موثر ہے، اور اسے zlib سے پہلے ایک پری پروسیسنگ قدم کے طور پر استعمال کیا جا سکتا ہے۔ یہ خاص طور پر ٹائلوں یا ووکسلز پر مشتمل خطوں کو سکیڑنے کے لیے موزوں ہے جس میں بہت سے ملحقہ عناصر کو دہرایا جاتا ہے۔
ڈیلٹا کمپریشن
آخری کمپریشن تکنیک ڈیلٹا کمپریشن ہے۔ یہ اس حقیقت پر مشتمل ہے کہ صرف موجودہ گیم کی حالت اور کلائنٹ کو موصول ہونے والی آخری حالت کے درمیان فرق ہی منتقل کیا جاتا ہے۔
یہ سب سے پہلے Quake3 نیٹ ورک انجن میں استعمال ہوا تھا۔ اسے استعمال کرنے کا طریقہ بتانے والے دو مضامین یہ ہیں:
- برائن ہک
- فیبین سانگلرز [ Habré پر مضامین، سیکشن "نیٹ ورک ماڈل" دیکھیں]
گلین فیڈلر نے اسے اپنے مضمون کے دوسرے حصے میں بھی استعمال کیا۔ .
خفیہ کاری۔
اس کے علاوہ، آپ کو کلائنٹس اور سرور کے درمیان معلومات کی منتقلی کو خفیہ کرنے کی ضرورت پڑ سکتی ہے۔ اس کی کئی وجوہات ہیں:
- رازداری/رازداری: پیغامات صرف وصول کنندہ ہی پڑھ سکتے ہیں، اور نیٹ ورک کو سونگھنے والا کوئی دوسرا شخص انہیں پڑھ نہیں سکے گا۔
- توثیق: جو شخص کھلاڑی کا کردار ادا کرنا چاہتا ہے اسے اس کی کلید جاننی چاہیے۔
- دھوکہ دہی کی روک تھام: بدنیتی پر مبنی کھلاڑیوں کے لیے اپنے دھوکہ دہی کے پیکجز بنانا بہت زیادہ مشکل ہوگا، انہیں انکرپشن اسکیم کو دوبارہ تیار کرنا ہوگا اور کلید تلاش کرنی ہوگی (جو ہر کنکشن کے ساتھ تبدیل ہوتی ہے)۔
میں اس کے لیے لائبریری استعمال کرنے کی سختی سے سفارش کرتا ہوں۔ میں استعمال کرنے کی تجویز کرتا ہوں۔ کیونکہ یہ خاص طور پر آسان ہے اور اس میں بہترین سبق ہیں۔ پر ٹیوٹوریل خاص طور پر دلچسپ ہے۔ ، جو آپ کو ہر نئے کنکشن کے ساتھ نئی کلیدیں بنانے کی اجازت دیتا ہے۔
درخواست پروٹوکول: نتیجہ
یہ ہمارے ایپلیکیشن پروٹوکول کو ختم کرتا ہے۔ مجھے یقین ہے کہ کمپریشن مکمل طور پر اختیاری ہے اور اسے استعمال کرنے کا فیصلہ صرف گیم اور مطلوبہ بینڈوتھ پر منحصر ہے۔ خفیہ کاری، میری رائے میں، لازمی ہے، لیکن پہلے پروٹو ٹائپ میں آپ اس کے بغیر کر سکتے ہیں۔
درخواست کی منطق
اب ہم کلائنٹ میں حالت کو اپ ڈیٹ کرنے کے قابل ہیں، لیکن تاخیر کے مسائل کا شکار ہو سکتے ہیں۔ کھلاڑی، ان پٹ کو مکمل کرنے کے بعد، یہ دیکھنے کے لیے کہ اس کا دنیا پر کیا اثر پڑا ہے، سرور سے گیم اسٹیٹ کے اپ ڈیٹ ہونے کا انتظار کرنا ہوگا۔
مزید یہ کہ، دو ریاستی اپڈیٹس کے درمیان، دنیا مکمل طور پر جامد ہے۔ اگر ریاست کی تازہ کاری کی شرح کم ہے، تو تحریکیں بہت دھچکے سے ہوں گی۔
اس مسئلے کے اثرات کو کم کرنے کے لیے کئی تکنیکیں ہیں، اور میں اگلے حصے میں ان کا احاطہ کروں گا۔
لیٹنسی ہموار کرنے کی تکنیک
اس سیکشن میں بیان کردہ تمام تکنیکوں پر سیریز میں تفصیل سے بحث کی گئی ہے۔ گیبریل گیمبیٹا۔ میں مضامین کی اس عمدہ سیریز کو پڑھنے کی انتہائی سفارش کرتا ہوں۔ اس میں ایک انٹرایکٹو ڈیمو بھی شامل ہے جو آپ کو یہ دیکھنے دیتا ہے کہ یہ تکنیک عملی طور پر کیسے کام کرتی ہے۔
پہلی تکنیک سرور سے جواب کا انتظار کیے بغیر براہ راست ان پٹ کے نتائج کو لاگو کرنا ہے۔ یہ کہا جاتا ہے کلائنٹ سائڈ کی پیشن گوئی. تاہم، جب کلائنٹ کو سرور سے اپ ڈیٹ موصول ہوتا ہے، تو اسے اس بات کی تصدیق کرنی چاہیے کہ اس کی پیشین گوئی درست تھی۔ اگر ایسا نہیں ہے، تو اسے صرف اس کے مطابق اپنی حالت تبدیل کرنے کی ضرورت ہے جو اسے سرور سے ملا ہے، کیونکہ سرور آمرانہ ہے۔ یہ تکنیک سب سے پہلے زلزلے میں استعمال کی گئی تھی۔ آپ مضمون میں اس کے بارے میں مزید پڑھ سکتے ہیں۔ فیبین سانگلرز [ Habré پر]۔
تکنیک کا دوسرا سیٹ دو ریاستی اپڈیٹس کے درمیان دیگر اداروں کی نقل و حرکت کو ہموار کرنے کے لیے استعمال کیا جاتا ہے۔ اس مسئلے کو حل کرنے کے دو طریقے ہیں: انٹرپولیشن اور ایکسٹراپولیشن۔ انٹرپولیشن کی صورت میں، آخری دو حالتیں لی جاتی ہیں اور ایک سے دوسری میں منتقلی دکھائی جاتی ہے۔ اس کا نقصان یہ ہے کہ اس میں تھوڑی سی تاخیر ہوتی ہے کیونکہ کلائنٹ ہمیشہ یہ دیکھتا ہے کہ ماضی میں کیا ہوا تھا۔ Extrapolation یہ پیشین گوئی کرنے کے بارے میں ہے کہ ہستیوں کو اب کلائنٹ کی طرف سے موصول ہونے والی آخری حالت پر مبنی ہونا چاہیے۔ اس کا نقصان یہ ہے کہ اگر ہستی مکمل طور پر حرکت کی سمت کو تبدیل کرتی ہے، تو پیشن گوئی اور اصل پوزیشن کے درمیان ایک بڑی خرابی ہو گی۔
جدید ترین، جدید ترین تکنیک صرف FPS میں مفید ہے۔ وقفہ معاوضہ. وقفے کے معاوضے کا استعمال کرتے وقت، سرور ہدف پر گولی مارنے پر کلائنٹ کی تاخیر کو مدنظر رکھتا ہے۔ مثال کے طور پر، اگر کسی کھلاڑی نے اپنی اسکرین پر ہیڈ شاٹ کیا، لیکن حقیقت میں ان کا ہدف تاخیر کی وجہ سے مختلف جگہ پر تھا، تو تاخیر کی وجہ سے کھلاڑی کو مارنے کے حق سے انکار کرنا ناانصافی ہوگی۔ لہذا، سرور اس لمحے کو واپس لے جاتا ہے جب کھلاڑی نے اپنی اسکرین پر جو کچھ دیکھا اس کی نقالی کرنے کے لیے اور اس کے شاٹ اور ہدف کے درمیان ٹکراؤ کی جانچ کرنے کے لیے کھلاڑی نے فائر کیا تھا۔
گلین فیڈلر (ہمیشہ کی طرح!) نے 2004 میں ایک مضمون لکھا ، جس میں اس نے سرور اور کلائنٹ کے مابین طبیعیات کے تخروپن کو ہم آہنگ کرنے کی بنیاد رکھی۔ 2014 میں انہوں نے مضامین کا ایک نیا سلسلہ لکھا ، جس نے طبیعیات کے تخروپن کو ہم آہنگ کرنے کے لئے دیگر تکنیکوں کو بیان کیا۔
والو ویکی پر دو مضامین بھی ہیں، и جو تاخیر کے معاوضے پر غور کرتے ہیں۔
دھوکہ دہی کی روک تھام
دھوکہ دہی کو روکنے کے لیے دو اہم تکنیکیں ہیں۔
پہلا: دھوکہ بازوں کے لیے نقصان دہ پیکٹ بھیجنا مزید مشکل بنانا۔ جیسا کہ اوپر بتایا گیا ہے، اس کو نافذ کرنے کا ایک اچھا طریقہ خفیہ کاری ہے۔
دوسرا: ایک آمرانہ سرور کو صرف کمانڈز/ان پٹ/ایکشن وصول کرنا چاہیے۔ کلائنٹ کو ان پٹ بھیجنے کے علاوہ سرور پر حالت تبدیل کرنے کے قابل نہیں ہونا چاہئے۔ پھر، جب بھی سرور کو ان پٹ موصول ہوتا ہے، اسے استعمال کرنے سے پہلے یہ چیک کرنا چاہیے کہ آیا یہ درست ہے یا نہیں۔
درخواست کی منطق: نتیجہ
میں تجویز کرتا ہوں کہ آپ اعلی لیٹنسیز اور کم ریفریش ریٹس کی تقلید کرنے کا طریقہ نافذ کریں تاکہ آپ خراب حالات میں اپنے گیم کے رویے کی جانچ کر سکیں، یہاں تک کہ جب کلائنٹ اور سرور ایک ہی کمپیوٹر پر چل رہے ہوں۔ یہ تاخیر کو ہموار کرنے کی تکنیکوں کے نفاذ کو بہت آسان بنا دے گا۔
دیگر مددگار وسائل
اگر آپ نیٹ ورک ماڈلز پر دیگر وسائل کو تلاش کرنا چاہتے ہیں، تو آپ انہیں یہاں تلاش کر سکتے ہیں:
- - اس کا پورا بلاگ پڑھنے کے قابل ہے، وہاں بہت سارے عظیم مضامین موجود ہیں۔ نیٹ ورک ٹیکنالوجیز پر تمام مضامین جمع کیے گئے ہیں۔
- بذریعہ M. Fatih MAR آن لائن ویڈیو گیم انجنوں پر مضامین اور ویڈیوز کی ایک جامع فہرست ہے۔
- В بہت سے مفید لنکس بھی ہیں۔
ماخذ: www.habr.com