آموزش ساخت بازی چندنفره: مفاهیم اوّلیّه

مبارزه با شرایط نامطلوب شبکه

برای به حدّاقل رساندن مشکل پهنای باند و packet loss، موتور چندنفره داده‌ها را حدّاکثر تا 30 بار در ثانیه، یعنی نصف نرخ فریم بازی در حالت عادی، انتقال می‌دهد.

برای پیرها

به خاطر این‌که اطّلاعاتی مثل مختصّات اشیاء فریم در میان ارسال می‌شوند، ممکن است بازی تکّه‌تکّه اجرا شود و اشیاء نامنظم حرکت کنند، و مشکلاتی با PDV و packet loss داشته باشیم.

برای بهبود روند بازی، موتور چندنفره بین مقادیر ارسالی را درون‌یابی می‌کند (مقدار بین دو داده‌ی متوالی مثل مختصّات X و Y را حدس می‌زند). این درون‌یابی در مورد مکان اشیاء به صورت خطّی انجام می‌شود. برای مثال در یکی از فریم‌های بازی مختصّات شیء دریافت می‌شود، در فریم بعدی مختصّاتی دریافت نمی‌شود و در فریم بعد از آن مختصّات جدید دریافت می‌شود، در آن فریمی که مختصّاتی دریافت نشد، موتور چندنفره میانگین آن دو مختصّات دیگر را به شیء نسبت می‌دهد. در نتیجه بدون نیاز به هیچ داده‌ی بیشتری باز هم حرکت شیء مورد نظر نرم خواهد بود.

امّا موقع رندر شدن یک فریم درون‌یابی شده، موتور چندنفره هنوز نمی‌داندکه مقدار بعدی چه چیزی است، چون آن مقدار در آینده خواهد رسید! به جای استفاده از ماشین زمان، موتور چند نفره این مشکل را با افزودن یک تأخیر 80 میلی‌ثانیه‌ای برای پیرها مرتفع کرده‌است. این یعنی موتور چندنفره از چند به روز رسانی قبل از این‌که رندر شوند پیشاپیش باخبر است. حتّی اگر به خاطر packet loss به روز رسانی بعدی دریافت نشود، موتور چندنفره از به روزرسانی‌های بعد از آن استفاده کرده و چند فریم را پشت سر هم درون‌یابی می‌کند. حتّی اگر وضعیّت شبکه آن قدر خراب باشد که برای 80 میلی‌ثانیه هیچ به‌روزرسانی‌ای دریافت نشود، موتور چندنفره از 2 به‌روزرسانی قبلی کمک گرفته و شیء را در همان راستا در فریم جدید حرکت می‌دهد. البتّه این یک کار حدسی است، ممکن است در همان زمان شیء مورد نظر ناپدید شده و در مکانی دیگر ظاهر شود، و درون‌یابی اشتباه شود.

برای درون‌یابی مقادیر، موتور چندنفره به شما اجازه می‌دهد تا یکی از سه حالت زیر را انتخاب کنید: خطّی[1] (مثل مختصّات اشیاء)، زاویه‌ای[2] (مثل زاویه‌ی اشیاء)، و هیچ[3] (برای داده‌هایی که نباید درون‌یابی شوند، مثل یک مقدار بولی که نشان می‌دهد آیا لیزر روشن است یا نه)

بی‌ثباتیِ Latency

همان‌طور که گفتیم Latency می‌تواند تغییر کند. گاهی اوقات Latency در یک دقیقه‌ی اوّل تدریجاً بهبود می‌یابد یا پس از اتّصال، مسیریابی به تدریج اتّصال را بهینه‌سازی می‌کند و روترها سریع‌ترین مسیر ممکن را تشخیص می‌دهند. Latency به طور ثابت اندازه‌گیری می‌شود تا چنین بی‌ثباتی‌هایی تشخیص داده شوند.

اگر Latency کاهش پیدا کند، موتور چندنفره به طور موقّت بازی را کمی سریع‌تر به جلو پیش می‌برد، زیرا کاهش Latency باعث می‌شود که سریع‌تر وقایع بازی را ببینید. از طرف دیگر، اگر Latency افزایش پیدا کند، سرعت حرکت اشیاء بازی کمی کاهش می‌یابد، زیرا افزایش Latency باعث می‌شود وقایع بازی را دیرتر ببینید. این کار برای جلوگیری از تکّه‌تکّه اجرا شدن بازی و این‌که تأخیر بیش از 80 میلی‌ثانیه باعث حرکت نامنظّم اشیاء نشود، ضروری است. این کارها باید به قدری نرم انجام شوند که تقریباً نامحسوس باشند. این ویژگی‌ها باعث می‌شوند که مطمئن شویم در شرایط مختلف اتّصال بهترین عملکرد را دارا خواهیم بود.

برای هاست

هاست نسخه‌ی معتبر بازی را دارد. چون هاست نمی‌خواهد به خودش اطّلاعاتی ارسال کند، Latency اش صفر است. به عبارت دیگر، هاست در بازی «واقعی» شرکت می‌کند، و پیرها تمام تلاششان را می‌کنند تا بازی را همان طور ببینند که هاست دارد می‌بیند. در نتیجه هاست از مزیّت روند بازی خوب برخوردار است.

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

[1] linear

[2] angular

[3] none