بخش قابل مشاهده یک بازی آنلاین فقط قسمتی از محصول است. پشت بسیاری از قابلیت‌هایی مانند ورود کاربر، ذخیره پیشرفت، موجودی، فروشگاه، رتبه‌بندی، Matchmaking و تاریخچه مسابقات یک Backend قرار دارد. ساخت بک اند بازی باید بر اساس منطق محصول طراحی شود و صرفاً ایجاد چند API عمومی نیست.
اگر سرور بدون توجه به رفتار بازی ساخته شود، خیلی زود مشکلاتی مانند داده‌های ناسازگار، درخواست‌های تکراری، تقلب، فشار زیاد روی دیتابیس یا دشواری در توسعه قابلیت‌های جدید ظاهر می‌شوند. معماری خوب باید مشخص کند چه اطلاعاتی روی Client باقی می‌مانند و کدام داده‌ها مرجع اصلی سمت Server هستند.
در JPGames طراحی Backend می‌تواند برای بازی‌های نوبتی، Multiplayer، بازی‌های موبایل دارای حساب کاربری یا محصولات دارای اقتصاد و پنل مدیریت انجام شود. تکنولوژی نهایی بر اساس نیاز پروژه انتخاب می‌شود، نه صرفاً محبوبیت یک ابزار.
ساخت بک اند بازی شامل چه بخش‌هایی است؟
Backend معمولاً از چند لایه تشکیل می‌شود. API یا لایه ارتباطی درخواست‌های Client را دریافت می‌کند، Business Logic تصمیم‌های لازم را می‌گیرد و دیتابیس اطلاعات پایدار را نگه می‌دارد. در بازی‌های Real-time ممکن است ارتباط WebSocket یا پروتکل‌های سریع‌تر نیز در کنار API وجود داشته باشد.
سیستم حساب کاربری و Authentication
اولین نیاز بسیاری از بازی‌ها شناسایی کاربر است. ورود می‌تواند با شماره تلفن، ایمیل، حساب مهمان یا سرویس‌های خارجی انجام شود. پس از Authentication، سرور معمولاً Token یا Session معتبر ایجاد می‌کند تا درخواست‌های بعدی قابل شناسایی باشند.
طراحی حساب کاربری باید امکان تبدیل Guest به حساب دائمی، بازیابی اطلاعات و جلوگیری از دسترسی غیرمجاز را در نظر بگیرد.
دیتابیس بازی
دیتابیس می‌تواند اطلاعات پروفایل، سطح، ارزهای بازی، آیتم‌ها، نتایج Match و تنظیمات را ذخیره کند. انتخاب SQL یا NoSQL به نوع داده و الگوی دسترسی بستگی دارد. MongoDB برای بعضی پروژه‌های بازی انعطاف‌پذیر است، در حالی که PostgreSQL و دیتابیس‌های رابطه‌ای نیز برای بسیاری از ساختارها انتخاب بسیار مناسبی هستند.
مهم‌تر از نام دیتابیس، طراحی Schema و قوانین تغییر داده است. برای مثال افزایش سکه باید یک عملیات کنترل‌شده باشد تا درخواست تکراری باعث دوبار اضافه‌شدن پاداش نشود.
چرا منطق حساس باید سمت سرور باشد؟
هر داده‌ای که فقط روی Client کنترل شود قابل دستکاری است. موجودی ارز، نتیجه مسابقات رقابتی، خرید و جوایز از مواردی هستند که باید توسط Server اعتبارسنجی شوند. Client می‌تواند درخواست انجام عمل را ارسال کند، اما تصمیم نهایی بهتر است سمت Backend گرفته شود.
این مدل به کاهش تقلب کمک می‌کند و باعث می‌شود داده کاربران روی چند دستگاه سازگار باقی بماند.
API و WebSocket چه تفاوتی در بازی دارند؟
APIهای HTTP برای کارهایی مانند دریافت پروفایل، لیست آیتم‌ها، خرید یا تنظیمات مناسب هستند. اما در ارتباطات Real-time، بازکردن درخواست HTTP برای هر رخداد می‌تواند ناکارآمد باشد. WebSocket یک اتصال پایدار ایجاد می‌کند که Client و Server بتوانند سریع‌تر پیام ارسال کنند.
در بسیاری از بازی‌ها هر دو روش همزمان استفاده می‌شوند. برای مثال Login و Store با REST API و Match آنلاین با Socket.IO یا WebSocket اجرا می‌شود.
ساخت سرور بازی آنلاین چه تفاوتی با بک اند معمولی دارد؟
بازی آنلاین علاوه بر داده‌های پایدار، State موقت مسابقه را نیز دارد. سرور باید بداند چه بازیکنانی در Room هستند، نوبت چه کسی است، آخرین Action معتبر چه بوده و در صورت قطع اتصال چه اتفاقی می‌افتد.
در بازی‌های نوبتی نگهداری State نسبتاً ساده‌تر است. در بازی‌های اکشن Real-time باید نرخ پیام‌ها، پهنای باند، Latency و Synchronization نیز جدی‌تر بررسی شوند.
Matchmaking در Backend چگونه پیاده‌سازی می‌شود؟
Matchmaking یک صف ساده نیست مگر اینکه پروژه بسیار ابتدایی باشد. سیستم می‌تواند رتبه، Level، Ping، منطقه، Arena یا مدت انتظار را بررسی کند. اگر بازیکن مدت زیادی منتظر بماند، محدوده جست‌وجو معمولاً گسترده‌تر می‌شود.
در برخی بازی‌ها Bot نیز به عنوان Fallback استفاده می‌شود. در این حالت سرور باید تصمیم بگیرد چه زمانی Bot وارد Match شود و نتیجه آن چگونه ثبت گردد.
مدیریت اقتصاد بازی در سرور
اگر بازی دارای Coin، Diamond، Ticket یا آیتم‌های قابل خرید باشد، Backend باید منبع معتبر موجودی باشد. هر تراکنش بهتر است دلیل مشخصی داشته باشد؛ مانند Reward Match، خرید فروشگاه یا Daily Reward. این رویکرد Audit و بررسی خطاها را آسان‌تر می‌کند.
- ثبت تراکنش‌ها
- جلوگیری از Double Reward
- اعتبارسنجی پرداخت
- محدودکردن درخواست‌های غیرعادی
- امکان پیگیری تغییر موجودی
مقیاس‌پذیری سرور بازی چگونه برنامه‌ریزی می‌شود؟
لازم نیست یک پروژه تازه از روز اول برای میلیون‌ها کاربر معماری شود، اما طراحی نباید مانع رشد آینده باشد. تعداد کاربران همزمان، نرخ پیام‌ها و حجم داده مهم‌ترین عوامل برآورد زیرساخت هستند.
در نسخه MVP ممکن است یک Instance مناسب باشد، اما با افزایش CCU می‌توان Load Balancing، Redis، Queue یا تقسیم سرویس‌ها را اضافه کرد. این تصمیم‌ها باید زمانی انجام شوند که نیاز واقعی وجود داشته باشد.
| بخش | وظیفه |
|---|---|
| Authentication | شناسایی و مدیریت Session کاربر |
| Database | ذخیره داده پایدار |
| Game Server | مدیریت State مسابقه |
| Matchmaking | پیداکردن حریف مناسب |
| Admin API | مدیریت داده از پنل |
امنیت Backend بازی چه مواردی را شامل می‌شود؟
امنیت فقط رمزگذاری پسورد نیست. Rate Limit، اعتبارسنجی ورودی، مدیریت Token، سطح دسترسی Admin، نگهداری Secretها و ثبت Audit Log نیز اهمیت دارند. Endpointهای مدیریتی نباید برای Client عمومی قابل استفاده باشند.
در پرداخت درون‌برنامه‌ای نیز بهتر است Receipt یا Token خرید در سمت Server با سرویس مربوطه بررسی شود تا Client نتواند خرید جعلی ایجاد کند.
هزینه ساخت بک اند بازی به چه عواملی وابسته است؟
یک Backend ساده برای Login و Cloud Save با سرور کامل Multiplayer تفاوت زیادی دارد. تعداد سیستم‌ها، نیاز Real-time، پنل مدیریت، پرداخت، رتبه‌بندی و سطح امنیت روی زمان توسعه اثر می‌گذارند.
هزینه زیرساخت نیز جدا از هزینه برنامه‌نویسی است. سرور، دیتابیس مدیریت‌شده، SMS، ایمیل و مانیتورینگ ممکن است هزینه ماهانه داشته باشند.
برای شروع طراحی Backend چه اطلاعاتی لازم است؟
نوع بازی، تعداد بازیکنان هر Match، پلتفرم، تعداد تقریبی کاربران، سیستم‌های اقتصادی، روش Login و قابلیت‌های مدیریتی اطلاعات پایه هستند. اگر Client Unity از قبل ساخته شده، ساختار فعلی نیز باید بررسی شود.
اگر برای پروژه خود به Backend، دیتابیس، API، WebSocket یا Game Server نیاز دارید، می‌توانید معماری و قابلیت‌های بازی را برای JPGames ارسال کنید تا مسیر توسعه و تکنولوژی مناسب بر اساس نیاز واقعی پروژه بررسی شود.