Multiplayer Game Backend ডিজাইন

ভাই, এবার আমরা একটা মজার কিন্তু কঠিন সিস্টেম ধরব — Multiplayer Game Backend। PUBG বা Valorant-এর মতো গেম কীভাবে ১০০ জন প্লেয়ারকে একই ম্যাপে মিলিসেকেন্ডে সিঙ্ক রাখে — সেই গল্প।

১. সমস্যা বোঝা (Requirements)

Functional:

• প্লেয়াররা একটা match/room-এ যোগ দেবে, একই গেম-ওয়ার্ল্ড শেয়ার করবে।
• প্রতিটি প্লেয়ারের মুভমেন্ট, শ্যুট, অ্যাকশন রিয়েল-টাইমে সবার কাছে যাবে।
• Matchmaking — সমান skill-এর প্লেয়ার মিলিয়ে ম্যাচ বানাবে।
• Anti-cheat — অসৎ ক্লায়েন্ট ঠেকাবে।

Non-functional:

• আল্ট্রা লো লেটেন্সি — RTT ৫০ ms-এর কম হলে আদর্শ, ১০০ ms-এর বেশি হলে খেলা নষ্ট।
• High availability — ম্যাচ চলাকালীন সার্ভার ক্র্যাশ করলে বিপর্যয়।
• Cheat-resistant — competitive integrity।
• Scalable — লক্ষ কনকারেন্ট ম্যাচ।

২. স্কেল আন্দাজ (Estimation)

ধরি:
- Concurrent players: 10M
- প্রতি ম্যাচে 100 player → ~100K concurrent match
- Tick rate: 30 ticks/sec (server simulation)

প্রতি player → server:
- input ~30 packet/sec, ~50 bytes each
- 10M × 30 = 300M packets/sec inbound

server → player:
- প্রতি tick-এ state snapshot/delta (~1-2 KB)
- 10M × 30 = 300M packets/sec outbound
- ব্যান্ডউইথ: 10M × 30 × 1.5KB ≈ 450 GB/s (তাই delta compression জরুরি!)

compute:
- প্রতি match server একটা গেম instance চালায়
- 100K match / (say 50 match per machine) → ~2K game server

মূল শিক্ষা: outbound ব্যান্ডউইথ আর per-match CPU-ই বটলনেক। তাই delta + interest management অপরিহার্য।

৩. API ডিজাইন

দুই অংশ — control plane (REST/HTTPS) আর realtime plane (UDP)।

# Control plane (REST)
POST /matchmaking/queue   { userId, gameMode, mmr } → ticket
GET  /matchmaking/status  { ticket } → { state, matchId, serverIp:port }
POST /match/{id}/result   → ম্যাচ শেষে result

# Realtime plane (UDP, custom protocol)
C→S  INPUT   { seq, tick, moveVec, actions, clientTime }
S→C  STATE   { tick, entities:[{id,pos,vel,hp}], lastAckedInput }
S→C  EVENT   { type:"hit"|"death", ... }
C→S  PING    { clientTime }   S→C PONG { clientTime, serverTime }

লক্ষ্য করো: ক্লায়েন্ট কখনো "আমি ৫০ HP কমালাম" বলে না, শুধু input ("আমি গুলি করলাম") পাঠায়। ফলাফল সার্ভার ঠিক করে।

৪. ডেটা মডেল

Entity	Field	ব্যাখ্যা
Player	userId, mmr, region, stats	persistent
MatchTicket	ticketId, userId, mmr, mode, ts	matchmaking queue
Match	matchId, serverIp, region, players[], state	active match
EntityState	entityId, pos, vel, hp, ownerId	per-tick, in-memory
Snapshot	matchId, tick, worldState	replay/rollback এর জন্য

Choice: লাইভ গেম স্টেট পুরোটাই in-memory (RAM)-এ থাকে গেম সার্ভারে — DB ছোঁয়ার সময় নেই। শুধু persistent ডেটা (mmr, stats, match result) DB-তে যায় ম্যাচ শেষে বা পর্যায়ক্রমে। Snapshot ring-buffer রাখা হয় lag compensation/rollback-এর জন্য।

৫. হাই-লেভেল ডিজাইন

কম্পোনেন্ট:

1. Client — render, input ক্যাপচার, prediction চালায়।
2. Matchmaker — queue থেকে similar-MMR প্লেয়ার গ্রুপ করে, region বেছে dedicated server allocate করে।
3. Game Server (per-match) — authoritative simulation, tick loop চালায়, anti-cheat ভ্যালিডেট করে।
4. Session / Fleet Manager — গেম সার্ভার fleet স্কেল করে (যেমন Agones ধরনের অর্কেস্ট্রেটর)।
5. Regional edge — প্লেয়ারের কাছাকাছি data center যাতে RTT কম।
6. Persistence — player profile, stats, replay store।

ফ্লো:

Player → queue (REST)
  → Matchmaker: MMR ± range-এ মিলিয়ে 100 জন গ্রুপ
  → নিকটতম region-এ game server allocate
  → players-কে serverIp:port দেয়
  → players UDP-তে কানেক্ট
  → Game loop (30 Hz):
      collect inputs → simulate physics → resolve combat
      → produce delta snapshots → broadcast
  → ম্যাচ শেষ → result DB-তে, server পুল-এ ফেরত

৬. গভীরে (Deep Dive)

Tick rate ও authoritative loop

সার্ভার একটা ফিক্সড টাইমস্টেপে (যেমন 30 বা 64 Hz) পুরো ওয়ার্ল্ড সিমুলেট করে। প্রতি tick-এ সে সব প্লেয়ারের জমা ইনপুট নেয়, physics/collision চালায়, hp আপডেট করে, তারপর নতুন state সবাইকে পাঠায়। বেশি tick rate = বেশি accuracy কিন্তু বেশি CPU ও ব্যান্ডউইথ।

Client prediction + server reconciliation

নেটওয়ার্ক ল্যাগ লুকাতে ক্লায়েন্ট নিজের input তাৎক্ষণিক অ্যাপ্লাই করে (move করলেই সরে যায়), প্রতিটা input-এ একটা seq রাখে। সার্ভার পরে যখন authoritative position পাঠায় (সাথে lastAckedInput), ক্লায়েন্ট দেখে তার prediction মিলেছে কিনা। না মিললে সে authoritative position থেকে শুরু করে unacked inputs আবার replay করে — একে বলে reconciliation। অন্য প্লেয়ারদের জন্য interpolation ব্যবহার হয় (দুটো পুরোনো snapshot-এর মাঝে smooth move)।

Lag compensation

শ্যুটার গেমে আমি যাকে দেখছি সে আসলে আমার স্ক্রিনে ১০০ ms পুরোনো position-এ। আমি যখন গুলি করি, সার্ভার আমার RTT হিসাব করে time-rewind করে — অর্থাৎ শ্যুটিং tick-এ টার্গেট কোথায় ছিল সেই historical snapshot দেখে hit রেজলভ করে। এজন্যই snapshot ring-buffer রাখা হয়।

Matchmaking

প্লেয়ার queue-তে ঢোকে MMR সহ। ম্যাচমেকার শুরুতে সরু MMR window খোঁজে, সময় বাড়লে window চওড়া করে (অপেক্ষা vs ম্যাচ কোয়ালিটি ট্রেড-অফ)। region/ping-ও বিবেচনা করে যাতে সবাই কাছাকাছি সার্ভার পায়।

৭. বটলনেক ও স্কেলিং

• ব্যান্ডউইথ — full state নয়, delta + interest management (যে এন্টিটি কাছে শুধু সেগুলো পাঠাও)।
• Per-match CPU — physics ভারী; fixed timestep, spatial partitioning (grid/quadtree) দিয়ে collision অপ্টিমাইজ।
• Regional latency — multiple data center, edge-এ গেম সার্ভার, players-কে নিকটতম region।
• Server allocation — fleet autoscaler দিয়ে dynamic game server spin-up/down।
• Anti-cheat — সার্ভার-সাইড validation (impossible move/speed detect), encrypted protocol, এবং client-side anti-cheat (kernel-level) — তবে কখনো ক্লায়েন্টকে trust করো না।

৮. সারসংক্ষেপ

মাল্টিপ্লেয়ার গেমের মেরুদণ্ড হলো authoritative server, যাতে চিট ঠেকে। তার ওপর client prediction দিয়ে ল্যাগ লুকাও, interpolation দিয়ে অন্যদের smooth দেখাও, আর lag compensation দিয়ে ন্যায্য combat নিশ্চিত করো। ট্রান্সপোর্ট UDP, sync হয় fixed tick rate-এ, আর regional servers RTT কমায়।