در مدل Host یکی از بازیکنان همزمان نقش سرور را دارد. این روش برای نمونه اولیه یا بازی دوستانه کمهزینه است، اما با خروج میزبان مسابقه قطع میشود و میزبان میتواند مزیت تأخیر یا امکان دستکاری بیشتری داشته باشد. Dedicated Server این نقش را به یک نمونه مستقل منتقل میکند.
سرور اختصاصی معمولاً بدون تصویر و صدا اجرا میشود و فقط منطق ضروری مسابقه را نگه میدارد. Unity برای Dedicated Server هدف Build و بهینهسازیهایی ارائه میکند، اما استقرار موفق به کانتینر، تخصیص مسابقه، مانیتورینگ، امنیت و اتصال بکاند نیز نیاز دارد.
ساخت Dedicated Server برای بازی Unity چیست؟
ساخت Dedicated Server برای بازی Unity یعنی تولید نسخهای از پروژه که روی ماشین سرور اجرا میشود و مرجع وضعیت مسابقه است. کلاینت ورودی را ارسال میکند و سرور پس از بررسی قوانین، نتیجه معتبر را برای بازیکنان منتشر میکند. این نسخه معمولاً رابط گرافیکی و داراییهای غیرضروری ندارد.
هدف Build مخصوص سرور میتواند زیرسیستم صوتی، دادههای صرفاً GPU و بخشهایی از رندر را حذف کند تا اندازه فایل و مصرف منابع کاهش یابد. بااینحال، اسکریپتها باید برای اجرای بدون دوربین و محیط Headless آماده باشند و هیچ منطق حیاتی به Animation Event یا فریم رندر وابسته نباشد.
تفکیک منطق کلاینت و سرور
قواعد مسابقه، اعتبارسنجی حرکت، سلامت، امتیاز و پایان بازی باید در سرور قرار بگیرند. کلاینت مسئول دریافت ورودی، نمایش، صدا و پیشبینی محلی است. کد مشترک مانند تعریف پیام یا محاسبات پایه میتواند در Assembly جداگانه قرار گیرد تا از اختلاف رفتار جلوگیری شود.
استفاده از شرطهای پراکنده برای خاموش کردن رندر در صدها اسکریپت نگهداری را دشوار میکند. معماری مناسب لایه Presentation را از Simulation جدا میسازد. به این ترتیب تست منطق بدون صحنه گرافیکی و اجرای خودکار تعداد زیادی مسابقه امکانپذیر میشود.
چرخه ایجاد یک مسابقه
پس از پیدا شدن بازیکنان، سرویس Allocation یک نمونه سرور آزاد انتخاب یا ایجاد میکند. شناسه مسابقه، Map و اطلاعات مجاز به سرور داده میشود. سرور آماده بودن خود را اعلام میکند و کلاینتها آدرس و توکن اتصال کوتاهعمر دریافت میکنند.
در پایان مسابقه، نتیجه معتبر به بکاند ارسال میشود، لاگ ضروری ذخیره و نمونه آزاد یا متوقف میگردد. عملیات گزارش نتیجه باید Idempotent باشد تا Retry موجب ثبت دوباره پاداش نشود. Timeout نیز لازم است تا مسابقه رهاشده منابع را برای همیشه اشغال نکند.
کانتینر و استقرار
Build لینوکس معمولاً داخل Container Image قرار میگیرد تا محیط اجرا تکرارپذیر باشد. Image باید کوچک، نسخهبندیشده و بدون کلید ثابت باشد. تنظیمات محیط مانند پورت، منطقه و شناسه مسابقه هنگام اجرا تزریق میشوند و اطلاعات حساس از Secret Manager دریافت میگردند.
برای مقیاس کم میتوان چند Process را روی ماشین مجازی اجرا کرد. در مقیاس بالاتر، Orchestrator ظرفیت را بر اساس صف و مصرف افزایش میدهد. انتخاب میان سرویس مدیریتشده و زیرساخت شخصی به بودجه، مناطق مورد نیاز و توان DevOps تیم بستگی دارد.
Server Authoritative و امنیت
اختصاصی بودن سرور بهتنهایی مانع تقلب نیست. تمام پیامها باید از نظر نوع، اندازه، نرخ و مجوز بررسی شوند. بازیکن نباید بتواند موقعیت غیرممکن، خرید جعلی یا فرمان مربوط به کاربر دیگر ارسال کند. Rate Limit و قطع اتصال رفتار مخرب ضروری است.
توکن ورود باید کوتاهعمر و مخصوص همان Match باشد. پورت مدیریتی نباید عمومی باشد و ارتباط سرویسها باید احراز هویت شود. بهروزرسانی وابستگیها، اسکن Image و اجرای Process با حداقل دسترسی، سطح حمله را کاهش میدهد.
Latency، Tick Rate و احساس بازی
سرور منطق را با Tick Rate مشخص اجرا میکند. نرخ بالاتر میتواند پاسخگویی را بهتر کند، ولی CPU و ترافیک بیشتری مصرف میشود. مقدار مناسب برای بازی نوبتی با تیراندازی سریع یکسان نیست و باید با آزمایش روی سختافزار هدف انتخاب شود.
کلاینت برای نمایش نرم از Interpolation استفاده میکند و برای پاسخ سریع حرکت خود را پیشبینی میکند. سرور در صورت اختلاف، وضعیت را اصلاح میکند. جبران تأخیر برای شلیک نیز باید محدود و منصفانه باشد تا بازیکن با Ping بالا برتری غیرمنطقی نگیرد.
مانیتورینگ و لاگ
شاخصهای مهم شامل تعداد مسابقه فعال، بازیکن متصل، CPU، حافظه، Tick Time، ترافیک، خطای اتصال و مدت صف هستند. تنها ذخیره متن خطا کافی نیست. هر Match باید شناسه داشته باشد تا رخدادهای بکاند، سرور و کلاینت کنار هم قابل بررسی شوند.
لاگ بسیار زیاد نیز هزینه ایجاد میکند و ممکن است داده شخصی ذخیره کند. سطح لاگ محیط تولید باید کنترل شود و رویدادهای حساس حذف یا ناشناسسازی شوند. هشدارها باید بر اساس اثر روی کاربر تعریف شوند، نه صرفاً هر افزایش کوتاه CPU.
مدل هزینه سرور
هزینه به RAM و CPU هر نمونه، تعداد بازیکنان در Match، مدت مسابقه، منطقه و ترافیک بستگی دارد. ابتدا باید ظرفیت یک Process با Load Test اندازهگیری شود. سپس همزمانی کاربران و ضریب اوج برای تخمین تعداد نمونهها به کار میروند.
فعال نگه داشتن ظرفیت گرم زمان انتظار را کم میکند اما هزینه بیکاری دارد. Autoscaling بیش از حد کند نیز باعث صف طولانی میشود. ترکیبی از ظرفیت پایه و افزایش خودکار معمولاً مناسب است. هزینه دیتابیس، لاگ و پهنای باند خروجی نیز باید جدا محاسبه شود.
مراحل اجرای پروژه
- جداسازی Simulation از رابط و گرافیک
- ساخت Build سرور و اجرای محلی چند کلاینت
- پیادهسازی احراز هویت و چرخه Match
- ساخت Image و استقرار در محیط آزمایشی
- افزودن مانیتورینگ، Crash Report و Autoscaling
- اجرای Load Test، تست شبکه و آزمون امنیت
Prototype یک مسابقه ساده میتواند طی چند هفته آماده شود، ولی استقرار تجاری به نوع بازی و سرویسهای جانبی وابسته است. در JPGames ابتدا مصرف واقعی هر Match اندازهگیری و سپس معماری میزبانی انتخاب میشود. برای برآورد ساخت Dedicated Server برای بازی Unity باید تعداد بازیکنان، مناطق و کاربران همزمان هدف مشخص باشند.