در بسیاری از بازی‌های چندنفره، بازیکن مستقیما وارد گیم‌پلی نمی‌شود؛ ابتدا وارد یک لابی، اتاق یا صف انتظار می‌شود و بعد از تکمیل شرایط، بازی شروع می‌شود. این بخش همان Room System است؛ سیستمی که مشخص می‌کند چه کسی وارد کدام اتاق شود، ظرفیت هر اتاق چقدر باشد، چه زمانی بازی شروع شود و وضعیت بازیکنان چگونه بین کلاینت و سرور هماهنگ بماند.
طراحی Room System فقط ساخت چند متغیر برای نگهداری بازیکنان نیست. اگر این سیستم درست طراحی نشود، مشکلاتی مثل ورود همزمان بیش از ظرفیت، شروع بازی با بازیکن ناقص، قطع ارتباط در لحظه حساس، تقلب در آماده بودن بازیکنان و ناهماهنگی وضعیت بازی به وجود می‌آید. در بازی‌های آنلاین حرفه‌ای، اتاق‌ها باید بر اساس معماری سرور، نوع بازی، تعداد بازیکنان، سیستم Matchmaking و حتی مدل درآمدی پروژه طراحی شوند.
در JPGames، هنگام طراحی بازی‌های آنلاین با Unity، Socket.IO و سرور Authoritative، Room System به عنوان یکی از بخش‌های اصلی معماری در نظر گرفته می‌شود؛ چون کیفیت این بخش مستقیما روی تجربه بازیکن، پایداری سرور و امکان توسعه آینده بازی اثر می‌گذارد.
طراحی Room System در بازی آنلاین چیست؟
طراحی Room System در بازی آنلاین یعنی ساخت یک ساختار نرم‌افزاری برای ایجاد، مدیریت، کنترل و حذف اتاق‌های بازی. اتاق می‌تواند یک لابی ساده قبل از مسابقه، یک Match فعال، یک میز بازی کارتی، یک سرور کوچک برای بازی بتل رویال یا حتی یک فضای خصوصی برای دوستان باشد. مهم‌ترین وظیفه Room System این است که بازیکنان مرتبط را در یک فضای منطقی مشترک قرار دهد و قوانین آن فضا را مدیریت کند.
در ساده‌ترین حالت، هر Room شامل شناسه اتاق، لیست بازیکنان، ظرفیت، وضعیت فعلی، تنظیمات بازی و زمان ایجاد است. اما در پروژه‌های جدی، اطلاعات بیشتری مثل Region، سطح مهارت بازیکنان، وضعیت اتصال، نقش هر بازیکن، تیم‌ها، Seed تصادفی، نسخه کلاینت، قوانین Matchmaking و وضعیت ضدتقلب نیز باید در نظر گرفته شود.
چرا Room System برای بازی‌های چندنفره مهم است؟
بدون Room System، سرور نمی‌داند هر پیام مربوط به کدام گروه از بازیکنان است. برای مثال در یک بازی دوئل آنلاین، وقتی بازیکن A حرکت می‌کند، این حرکت فقط باید برای حریف او ارسال شود، نه برای همه کاربران آنلاین. Room System این مرزبندی را ایجاد می‌کند و باعث می‌شود ارتباطات شبکه‌ای هدفمند، سبک‌تر و قابل کنترل‌تر باشند.
از نظر تجربه کاربری نیز Room System اهمیت زیادی دارد. بازیکن باید بداند آیا در حال انتظار است، آیا حریف پیدا شده، آیا همه آماده‌اند، بازی چه زمانی شروع می‌شود و اگر اینترنتش قطع شد چه اتفاقی می‌افتد. هر چقدر این جریان شفاف‌تر باشد، حس حرفه‌ای بودن بازی بیشتر می‌شود.
- مدیریت لابی و انتظار قبل از شروع بازی
- کنترل ظرفیت و جلوگیری از ورود اضافه
- ارسال پیام فقط به بازیکنان همان اتاق
- هماهنگ‌سازی شروع، پایان و نتیجه بازی
- پشتیبانی از Reconnect و بازگشت بازیکن
- کاهش فشار روی سرور با دسته‌بندی کاربران
اجزای اصلی یک Room System استاندارد
Room Manager
Room Manager مغز اصلی سیستم اتاق‌هاست. این بخش مسئول ساخت اتاق جدید، پیدا کردن اتاق مناسب، حذف اتاق‌های خالی، بررسی ظرفیت و مدیریت چرخه عمر Room است. در پروژه‌های کوچک، Room Manager می‌تواند داخل همان سرور اصلی پیاده‌سازی شود؛ اما در پروژه‌های بزرگ‌تر بهتر است به شکل سرویس مستقل یا ماژول جداگانه طراحی شود.
Room State
هر اتاق باید یک وضعیت مشخص داشته باشد. برای مثال Waiting یعنی اتاق منتظر بازیکن است، ReadyCheck یعنی بازیکنان باید آماده بودن خود را اعلام کنند، InGame یعنی مسابقه شروع شده و Finished یعنی بازی تمام شده است. استفاده از State واضح باعث می‌شود منطق سرور قابل پیش‌بینی باشد و از اجرای اشتباه رویدادها جلوگیری شود.
Player Session
بازیکن فقط یک Socket ID نیست. در طراحی حرفه‌ای، برای هر بازیکن یک Session در نظر گرفته می‌شود که شامل User ID، وضعیت اتصال، زمان آخرین فعالیت، تیم، نقش، وضعیت آماده بودن و اطلاعات امنیتی است. این کار مخصوصا برای Reconnect اهمیت دارد؛ چون ممکن است Socket قطع شود، اما بازیکن هنوز حق بازگشت به همان اتاق را داشته باشد.
Room Rules
هر اتاق باید قوانین مشخصی داشته باشد. مثلا حداقل تعداد بازیکنان برای شروع، حداکثر ظرفیت، مدت زمان انتظار، اجازه ورود وسط بازی، سطح دسترسی Host، نوع Match و شرایط پایان بازی. بهتر است این قوانین به صورت داده‌محور طراحی شوند تا برای حالت‌های مختلف بازی قابل تغییر باشند.
چرخه عمر Room از ایجاد تا حذف
یک Room معمولا از چند مرحله عبور می‌کند. ابتدا بازیکن درخواست ورود به بازی می‌دهد. سرور بررسی می‌کند که آیا اتاق مناسبی وجود دارد یا نه. اگر اتاقی با ظرفیت و قوانین مناسب پیدا شد، بازیکن به همان اتاق اضافه می‌شود. اگر چنین اتاقی وجود نداشت، سرور یک اتاق جدید می‌سازد.
بعد از تکمیل ظرفیت یا رسیدن به حداقل بازیکن، اتاق وارد مرحله آماده‌سازی می‌شود. در این مرحله سرور می‌تواند اطلاعات اولیه مثل تیم‌ها، نقشه، Seed، زمان شروع و تنظیمات Match را برای کلاینت‌ها ارسال کند. سپس بازی شروع می‌شود و Room وارد حالت InGame می‌شود. پس از پایان بازی، نتیجه ذخیره شده، امتیازها محاسبه می‌شوند و اتاق بعد از مدت کوتاهی حذف یا برای Match بعدی بازنشانی می‌شود.
- درخواست ورود بازیکن به Match
- پیدا کردن Room مناسب یا ساخت Room جدید
- افزودن بازیکن و ارسال وضعیت فعلی
- بررسی ظرفیت و آماده بودن بازیکنان
- شروع بازی با تایید سرور
- مدیریت رویدادهای InGame
- ثبت نتیجه و پاک‌سازی منابع Room
نمونه مدل داده برای Room در سرور
مدل داده Room باید ساده، قابل توسعه و قابل اعتبارسنجی باشد. در Node.js و Socket.IO می‌توان ساختاری شبیه نمونه زیر در نظر گرفت. این نمونه صرفا نمای کلی معماری است و در پروژه واقعی باید با دیتابیس، سیستم احراز هویت و منطق ضدتقلب ترکیب شود.
class GameRoom {
constructor(roomId, config) {
this.id = roomId;
this.state = 'waiting';
this.maxPlayers = config.maxPlayers;
this.minPlayers = config.minPlayers;
this.players = new Map();
this.createdAt = Date.now();
this.startedAt = null;
this.region = config.region;
this.mode = config.mode;
}
canJoin(player) {
return this.state === 'waiting' && this.players.size < this.maxPlayers;
}
addPlayer(player) {
if (!this.canJoin(player)) return false;
this.players.set(player.userId, player);
return true;
}
isReadyToStart() {
return this.players.size >= this.minPlayers;
}
}در این ساختار، سرور تصمیم می‌گیرد بازیکن اجازه ورود دارد یا نه. این موضوع بسیار مهم است؛ چون در معماری امن، کلاینت نباید بتواند خودش را وارد هر اتاقی کند یا وضعیت Room را تغییر دهد. کلاینت فقط درخواست می‌دهد و سرور تصمیم نهایی را می‌گیرد.
ارتباط Room System با Matchmaking
Room System و Matchmaking به هم وابسته‌اند، اما یکی نیستند. Matchmaking تصمیم می‌گیرد کدام بازیکنان باید کنار هم قرار بگیرند؛ Room System آن گروه را در یک فضای منطقی نگهداری و مدیریت می‌کند. در بازی‌های ساده، ممکن است Matchmaking فقط اولین اتاق خالی را انتخاب کند. اما در بازی‌های رقابتی، معیارهایی مثل سطح مهارت، پینگ، Region، رتبه، نوع دستگاه و نسخه بازی اهمیت پیدا می‌کند.
برای مثال در یک بازی موبایلی آنلاین، اگر بازیکنان ایران، اروپا و آمریکا روی یک سرور قرار بگیرند، تجربه برخی کاربران به دلیل پینگ بالا خراب می‌شود. بنابراین Room System باید امکان دسته‌بندی اتاق‌ها بر اساس Region را داشته باشد. همچنین اگر بازی دارای Ranked Match باشد، Room باید اطلاعات رتبه و قوانین امتیازدهی را نیز نگهداری کند.
Authoritative Server در مدیریت Room
یکی از اشتباهات رایج در طراحی بازی آنلاین این است که بخش زیادی از منطق اتاق به کلاینت سپرده می‌شود. در بازی‌های جدی، مخصوصا بازی‌های رقابتی، باید از سرور Authoritative استفاده شود. یعنی سرور منبع اصلی حقیقت است و تصمیم‌هایی مثل ورود بازیکن، شروع بازی، نتیجه Match، ترک بازی، برد و باخت و تغییر وضعیت Room را کنترل می‌کند.
در معماری Client Authoritative، ممکن است کلاینت اعلام کند که بازی شروع شده یا نتیجه را خودش ارسال کند. این مدل برای نمونه‌های آزمایشی ساده‌تر است، اما برای محصول واقعی ریسک تقلب و ناهماهنگی بالایی دارد. در مقابل، در معماری Authoritative، کلاینت فقط Input یا درخواست ارسال می‌کند و سرور پس از اعتبارسنجی، وضعیت معتبر را برای همه اعضای Room Broadcast می‌کند.
طراحی پیام‌ها و Eventها در Socket.IO
اگر از Socket.IO برای بازی آنلاین استفاده شود، باید Eventها با نام‌گذاری شفاف طراحی شوند. برای مثال join_room، leave_room، room_state، player_ready، match_started و match_finished می‌توانند رویدادهای اصلی باشند. نکته مهم این است که هر Event باید ورودی مشخص، خروجی مشخص و خطای قابل فهم داشته باشد.
در سمت سرور، استفاده از قابلیت room داخلی Socket.IO برای ارسال پیام به اعضای یک اتاق مفید است، اما نباید آن را با مدل منطقی Room System اشتباه گرفت. Room داخلی Socket.IO ابزار ارسال پیام است؛ اما Room System واقعی شامل قوانین بازی، وضعیت بازیکنان، چرخه عمر Match و داده‌های سروری است.
socket.on('join_room', async (payload) => {
const player = await authenticatePlayer(socket, payload.token);
const room = roomManager.findOrCreateRoom(player, payload.mode);
if (!room.addPlayer(player)) {
socket.emit('join_room_failed', { reason: 'room_not_available' });
return;
}
socket.join(room.id);
io.to(room.id).emit('room_state', room.toPublicState());
if (room.isReadyToStart()) {
roomManager.startMatch(room.id);
}
});در این نمونه، احراز هویت قبل از ورود انجام می‌شود، سپس Room مناسب پیدا یا ساخته می‌شود و در نهایت وضعیت عمومی اتاق برای اعضا ارسال می‌شود. متد toPublicState اهمیت زیادی دارد؛ چون نباید تمام اطلاعات داخلی سرور برای کلاینت ارسال شود.
مدیریت Disconnect و Reconnect
قطع شدن اینترنت در بازی‌های آنلاین کاملا طبیعی است. Room System باید مشخص کند اگر بازیکن از بازی خارج شد، بلافاصله حذف شود یا برای چند ثانیه فرصت بازگشت داشته باشد. در بازی‌های نوبتی یا رقابتی، حذف فوری بازیکن می‌تواند تجربه ناعادلانه ایجاد کند. بهتر است وضعیت بازیکن به disconnected تغییر کند و یک تایمر Reconnect فعال شود.
اگر بازیکن در زمان تعیین‌شده برگشت، Session قبلی به Socket جدید متصل می‌شود و Room ادامه پیدا می‌کند. اگر برنگشت، سرور می‌تواند بازی را با Bot ادامه دهد، بازیکن را بازنده اعلام کند یا Match را لغو کند. انتخاب این رفتار به سبک بازی بستگی دارد.
نکات امنیتی در طراحی Room System
امنیت در Room System فقط به ورود کاربر محدود نمی‌شود. سرور باید تمام درخواست‌ها را اعتبارسنجی کند. بازیکن نباید بتواند وارد اتاق خصوصی دیگران شود، ظرفیت Room را دور بزند، خودش را Ready اعلام کند در حالی که در اتاق نیست، نتیجه جعلی بفرستد یا با تغییر داده‌های کلاینت وارد Match نامعتبر شود.
- اعتبارسنجی Token قبل از Join
- بررسی عضویت بازیکن قبل از اجرای هر Event
- مخفی نگه داشتن اطلاعات داخلی Room
- Rate Limit برای جلوگیری از Spam در Join و Leave
- ثبت Log برای خطاها و رفتارهای مشکوک
- عدم اعتماد به نتیجه ارسال‌شده از کلاینت
مقیاس‌پذیری Room System در پروژه‌های بزرگ
وقتی تعداد کاربران افزایش پیدا می‌کند، نگهداری همه Roomها روی یک سرور کافی نیست. در این مرحله باید به Load Balancing، چندین Instance سرور، Redis، Pub/Sub و حتی معماری Microservice فکر کرد. یکی از چالش‌های مهم این است که پیام‌های یک Room باید به همان Instance برسند که Room در آن فعال است یا وضعیت Room بین Instanceها هماهنگ شود.
برای بازی‌های Real-time، بهتر است تا حد امکان یک Match فعال روی یک Node مشخص مدیریت شود تا تاخیر کم بماند. اما اطلاعات عمومی مثل لیست اتاق‌ها، وضعیت صف Matchmaking و آمار کلی می‌تواند در Redis یا دیتابیس سریع نگهداری شود. طراحی درست این بخش از ابتدا، هزینه توسعه آینده را بسیار کاهش می‌دهد.
Room خصوصی، عمومی و سفارشی
همه اتاق‌ها یکسان نیستند. در برخی بازی‌ها، بازیکن فقط روی دکمه Play می‌زند و وارد یک Room عمومی می‌شود. در برخی دیگر، بازیکن می‌خواهد با دوستانش بازی کند و کد دعوت بسازد. در بازی‌های آموزشی، سازمانی یا برندمحور نیز ممکن است اتاق‌ها بر اساس کلاس، تیم، کمپین یا رویداد ساخته شوند.
برای همین بهتر است Room System از ابتدا قابلیت پشتیبانی از Room عمومی، Room خصوصی، Room با رمز، Room دعوت‌محور و Room سفارشی را داشته باشد. این انعطاف در پروژه‌هایی که قرار است بعدا توسعه پیدا کنند بسیار ارزشمند است.
اشتباهات رایج در طراحی Room System
یکی از اشتباهات رایج، نگهداری Room بدون زمان انقضا است. اگر اتاق‌های خالی حذف نشوند، حافظه سرور به مرور پر می‌شود. اشتباه دیگر این است که کلاینت اجازه داشته باشد وضعیت Room را مستقیما تغییر دهد. همچنین بسیاری از تیم‌ها از ابتدا به Reconnect فکر نمی‌کنند و بعدا مجبور می‌شوند بخش زیادی از معماری را بازنویسی کنند.
اشتباه مهم دیگر، ترکیب بیش از حد منطق Room با منطق گیم‌پلی است. بهتر است Room مسئول مدیریت بازیکنان، وضعیت Match و ارتباط شبکه‌ای باشد؛ اما قوانین دقیق گیم‌پلی در ماژول جداگانه Game Logic پیاده‌سازی شود. این جداسازی تست‌پذیری و نگهداری پروژه را بهتر می‌کند.
جمع‌بندی
طراحی Room System در بازی آنلاین یکی از پایه‌های اصلی معماری Multiplayer است. این سیستم مشخص می‌کند بازیکنان چگونه وارد Match شوند، چطور در کنار هم قرار بگیرند، چه زمانی بازی شروع شود، پیام‌ها برای چه کسانی ارسال شوند و پس از پایان بازی چه اتفاقی بیفتد. اگر Room System اصولی طراحی شود، توسعه ویژگی‌هایی مثل Matchmaking، لابی خصوصی، Reconnect، Ranked Match و مقیاس‌پذیری بسیار ساده‌تر خواهد شد.
برای پروژه‌هایی که با Unity، Socket.IO یا سرور Authoritative ساخته می‌شوند، بهتر است Room System از همان مرحله طراحی فنی و GDD جدی گرفته شود. تیم JPGames با تجربه در ساخت بازی‌های آنلاین، موبایلی و چندنفره می‌تواند این معماری را متناسب با نیاز هر پروژه طراحی و پیاده‌سازی کند؛ چه هدف ساخت یک بازی رقابتی Real-time باشد، چه یک بازی آموزشی، تبلیغاتی یا محصول سفارشی برای برند.