نت کد

نت کد اصطلاحی است که معمولاً توسط گیمرها در ارتباط با شبکه در بازی‌های آنلاین استفاده می‌شود و اغلب به مشکلات همگام‌سازی بین کلاینت‌ها و سرورها اشاره دارد. بازیکنان معمولاً هنگامی که با تاخیر مواجه می شوند یا زمانی که ورودی های آنها حذف می شود، "شبکه های بد" را استنباط می کنند. نت کدها ممکن است برای حفظ یک تجربه همزمان و یکپارچه بین کاربران با وجود این چالش های شبکه طراحی شوند.

انواع نت کد

فلوچارت ساخته شده با استفاده از تجسم Creately فرآیند پشت اجرا و همگام سازی ورودی های دو بازیکن (با پینگ 90 میلی ثانیه بین آنها) در یک بازی آنلاین که از نت کد مبتنی بر تاخیر در یک مدل مشابه استفاده می کند.

برخلاف یک بازی محلی که در آن ورودی‌های همه بازیکنان بلافاصله در همان شبیه‌سازی یا نمونه بازی اجرا می‌شود، در یک بازی آنلاین چندین شبیه‌سازی موازی وجود دارد (یکی برای هر بازیکن) که در آن ورودی‌های بازیکنان مربوطه آنها بلافاصله دریافت می‌شود. ورودی‌های همان فریم از بازیکنان دیگر با تأخیر مشخصی می‌رسند. دو راه حل اصلی برای حل این تضاد و اجرای روان بازی وجود دارد:

مبتنی بر تاخیر

نمودار اجرا و همگام سازی ورودی های دو بازیکن در یک بازی آنلاین که از نت کد مبتنی بر تاخیر در مدل همتا به همتا استفاده می کند.

راه حل کلاسیک برای این مشکل استفاده از یک نت کد مبتنی بر تاخیر است. هنگامی که ورودی های یک پخش کننده از راه دور دیر می رسد، بازی ورودی های بازیکن محلی را به تعویق می اندازد تا دو ورودی را همگام سازی کند و آنها را به طور همزمان اجرا کند. این تأخیر اضافه می تواند برای بازیکنان مختل کننده باشد (مخصوصاً زمانی که تأخیر زیاد است)، اما در کل تغییر چندان محسوس نیست. اگر تاخیر بین بازیکنان از یک پنجره بافر تعیین شده برای بازیکن راه دور بیشتر شود، بازی باید منتظر بماند و باعث "یخ زدن" صفحه نمایش شود. این به این دلیل اتفاق می‌افتد که یک نت کد مبتنی بر تاخیر اجازه نمی‌دهد شبیه‌سازی تا زمانی که ورودی‌ها را از تمام بازیکنان در فریم مورد نظر دریافت کند، ادامه پیدا کند.

بازگشت به عقب

نمودار اجرا و همگام سازی ورودی های دو بازیکن در یک بازی آنلاین که از کد شبکه بازگشتی در مدل همتا به همتا استفاده می کند.

یک سیستم جایگزین برای نت کد قبلی، نت کد بازگشتی است. این سیستم بلافاصله ورودی های پخش کننده محلی را اجرا می کند (به گونه ای که مانند نت کد مبتنی بر تاخیر با تأخیر مواجه نشوند) گویی یک بازی آفلاین است و ورودی های بازیکن یا بازیکنان از راه دور را به جای منتظر ماندن (با فرض) پیش بینی می کند. آنها همان ورودی تیک قبلی را ایجاد می کنند). هنگامی که این ورودی‌های راه دور وارد می‌شوند (مثلاً 45 میلی‌ثانیه بعد)، بازی می‌تواند به دو صورت عمل کند: اگر پیش‌بینی درست باشد، بازی به‌طور کاملاً پیوسته ادامه می‌یابد. اگر پیش‌بینی نادرست بود، حالت بازی برگردانده می‌شود و گیم‌پلی از حالت تصحیح شده ادامه می‌یابد که به عنوان یک «پرش» به بازیکن یا بازیکنان دیگر دیده می‌شود. برخی از بازی‌ها از یک راه‌حل ترکیبی برای پنهان کردن این «پرش‌ها» استفاده می‌کنند با تاخیر ورودی ثابت و سپس استفاده از بازگشت بازگشت. . بازگشت به عقب در پنهان کردن لگ اسپایک یا سایر مسائل مربوط به ناهماهنگی در اتصالات کاربران کاملاً مؤثر است، زیرا پیش‌بینی‌ها اغلب درست هستند و بازیکنان حتی متوجه نمی‌شوند. با این وجود، این سیستم می تواند هر زمان که بازی مشتری کند شود (معمولاً به دلیل گرمای بیش از حد) مشکل ساز باشد، زیرا مشکلات شکاف می تواند منجر به مبادله بلیط بین ماشین ها با نرخ های نابرابر شود.

این باعث ایجاد اشکالات بصری می شود که گیم پلی آن دسته از بازیکنانی را که ورودی ها را با سرعت کمتری دریافت می کنند، مختل می کند، در حالی که بازیکنی که سرعت بازی او کاهش یافته است با دریافت ورودی از دیگران با نرخ معمولی نسبت به بقیه برتری خواهد داشت (این به عنوان یک عقبگرد یک طرفه).

اگرچه این سیستم اغلب با معماری همتا به همتا و بازی های مبارزه ای مرتبط است، اشکالی از شبکه بازگشتی وجود دارد که معمولاً در معماری های سرویس گیرنده-سرور نیز استفاده می شود.

علل بالقوه مشکلات نت کد

تاخیر

تأخیر در بازی‌های آنلاین اجتناب‌ناپذیر است و کیفیت تجربه بازیکن به شدت با این موضوع مرتبط است. اینکه تأخیر شبکه بازیکنان تنها عامل مورد بحث نیست، بلکه تأخیر ذاتی در نحوه اجرای شبیه‌سازی‌های بازی است. چندین روش جبران تاخیر وجود دارد که برای پنهان کردن یا مقابله با تاخیر (مخصوصاً با مقادیر تاخیر بالا) استفاده می شود.

تیک ریت

به روز رسانی یک شبیه سازی بازی به عنوان تیک شناخته می شود. سرعت اجرای شبیه سازی روی سرور اغلب به عنوان تیک سرور نامیده می شود. این اساساً معادل سرور نرخ فریم مشتری است، بدون هر گونه سیستم رندر. Tickrate با مدت زمانی که برای اجرای شبیه‌سازی طول می‌کشد محدود می‌شود، و اغلب به عمد بیشتر برای کاهش بی‌ثباتی ایجاد شده توسط یک تیک نوسان و کاهش هزینه‌های CPU و انتقال داده محدود می‌شود. تیک تیک کمتر تاخیر در همگام سازی شبیه سازی بازی بین سرور و کلاینت ها را افزایش می دهد.

به دلیل محدودیت در مقدار پهنای باند در دسترس و زمان CPU که توسط ارتباطات شبکه گرفته می شود، برخی از بازی ها ارتباطات حیاتی خاصی را در اولویت قرار می دهند در حالی که فرکانس و اولویت اطلاعات کمتر مهم را محدود می کنند. همانند Tikrate، این به طور موثر تاخیر همگام سازی را افزایش می دهد. موتورهای بازی ممکن است تعداد دفعاتی را که به‌روزرسانی‌ها (شبیه‌سازی) به یک کلاینت خاص و/یا اشیاء خاص در دنیای بازی ارسال می‌شوند، محدود کنند.

اشکالات نرم افزاری

خطاهای مختلف همگام سازی شبیه سازی بین ماشین ها نیز می توانند تحت پوشش "مشکلات netcode" قرار گیرند. اینها ممکن است شامل اشکالاتی باشند که باعث می‌شوند شبیه‌سازی در یک ماشین متفاوت از ماشین دیگر پیش برود، یا باعث می‌شود که برخی چیزها زمانی که کاربر درک می‌کند که باید انجام شود، منتقل نمی‌شوند.

پروتکل لایه انتقال و کد ارتباطی: TCP و UDP

انتخاب پروتکل لایه انتقال توسط یک بازی نیز می‌تواند بر مشکلات شبکه‌ای تأثیر بگذارد.

اگر یک بازی از پروتکل کنترل انتقال (TCP) استفاده کند، تاخیر بین بازیکنان افزایش می یابد. این پروتکل مبتنی بر ارتباط بین دو ماشین است که در آن آنها می توانند داده ها را مبادله کرده و بخوانند. این نوع اتصالات بسیار قابل اعتماد، پایدار، منظم و آسان برای پیاده سازی هستند و تقریباً در هر عملیاتی که ما در اینترنت انجام می دهیم استفاده می شود. با این حال، این اتصالات برای سرعت شبکه ای که بازی های سریع-اکشن به آن نیاز دارند، کاملاً مناسب نیستند، زیرا این نوع پروتکل به طور خودکار داده ها را در بسته هایی گروه بندی می کند (که تا زمانی که حجم مشخصی از اطلاعات به دست نیاید، ارسال نمی شوند. ، مگر اینکه این الگوریتم - الگوریتم ناگل - غیرفعال باشد) که از طریق ارتباط برقرار شده بین ماشین ها ارسال می شود و نه مستقیم.

اگر بازی به جای آن از پروتکل User Datagram (UDP) استفاده کند، ارتباط بین ماشین ها بسیار سریع خواهد بود، زیرا به جای ایجاد ارتباط بین آنها، داده ها مستقیما ارسال و دریافت می شوند. این پروتکل بسیار ساده‌تر از پروتکل قبلی است، اما فاقد قابلیت اطمینان و پایداری است و نیاز به پیاده‌سازی کد شخصی برای مدیریت توابع ضروری برای ارتباط بین ماشین‌هایی دارد که توسط TCP مدیریت می‌شوند.

همچنین ببینید

• بازی آنلاین
• تاخیر (بازی آنلاین)