מובייל מרובה משתתפים: חיזוי לקוח ופיצוי השהיה

הנדסת משחקי מובייל מרובי משתתפים

אנו מתמחים בבניית משחקי מובייל מרובי משתתפים בזמן אמת. זה לא רק WebSocket ושליחת קואורדינטות — זה ניהול השהיה של 50–200 אלפיות שנייה, פיצוי על אובדן מנות, סנכרון פיזיקה והתמודדות עם רשת 4G לא יציבה. לקוחות מובייל מאבדים מנות בתדירות גבוהה יותר ממחשבים שולחניים: מעבר מ-WiFi ל-LTE, מעבר של מערכת ההפעלה לרקע — יישום נאיבי נכשל בבדיקות מוקדמות. אובדן מנות של 5% הוא נפוץ ברשתות מובייל, והשהיה נוספת של 100 אלפיות שנייה יוצרת חוויה בלתי מקובלת. הצוות שלנו, עם ניסיון של למעלה מעשור במשחקי מובייל ו-20+ כותרים מרובי משתתפים ששוחררו, מספק פתרון מלא מארכיטקטורה ועד פריסה. אנו משיגים חיסכון של עד 40% ברוחב פס באמצעות דחיסת דלתא — חיסכון אופייני של $2,000–$5,000 לחודש למשחק בגודל בינוני. מאמר זה מכסה החלטות טכניות מרכזיות: שרת סמכותי, חיזוי לקוח, פיצוי השהיה ואופטימיזציות למובייל.

אתגרים מרכזיים במובייל מרובי משתתפים

הטעות הראשונה היא לסמוך על הלקוח. הלקוח שולח "זזתי לכאן" והשרת מיישם זאת ללא אימות. תוך שבוע, רמאים משתגרים על פני המפה. הארכיטקטורה הנכונה: שרת סמכותי. הלקוח שולח קלט (לחצנים שנלחצו, וקטור תנועה), השרת מדמה פיזיקה ומשדר את המצבים המתקבלים. הלקוח מריץ את אותם חישובים מקומית — זהו חיזוי צד לקוח. כאשר תגובת השרת מגיעה, הלקוח מבצע התאמה — חוזר למצב המאושר האחרון ומשחזר את מאגר הקלטים הלא מאושרים. כפי שצוין בתיעוד Unity Netcode, גישה זו היא חובה למשחקים תחרותיים.

כיצד חיזוי צד לקוח משפר מובייל מרובי משתתפים?

כל מחזור משחק (בדרך כלל 20–60 הרץ למובייל):

1. הלקוח שולח InputPayload { tick, moveDirection, shootPressed }.
2. השרת מיישם קלט, מחשב StatePayload { tick, position, health, ... }.
3. השרת משדר תמונות מצב לכל הלקוחות (לא בכל מחזור — מופעלת דחיסת דלתא).
4. הלקוח מקבל תמונת מצב, משווה עם המצב החזוי ומתקן.

דחיסת דלתא היא קריטית: במקום מצב עולם מלא (300 בתים), נשלחים רק שינויים (10–30 בתים). ב-20 הרץ עבור 10 שחקנים, ההבדל הוא 60 KB/s לעומת 6 KB/s — הפחתה של 90%. חיזוי צד לקוח מפחית את ההשהיה הנתפסת פי 3 בהשוואה להמתנה לאישור השרת.

UDP לעומת TCP לזמן אמת במובייל

TCP מבטיח משלוח וסדר באמצעות שידור חוזר בעת אובדן. במשחק בזמן אמת, מנה שאבדה עם מיקום שחקן מלפני 200 אלפיות שנייה אינה נחוצה — יש צורך במיקום הנוכחי. TCP יחכה וישלח מחדש נתונים מיושנים בעוד נתונים חדשים ממתינים בתור, ומוסיף 100–400 אלפיות שנייה להשהיה הנראית בערוצים גרועים. UDP — ירי ושכח. אובדן מטופל בשכבת היישום: עדכוני מיקום אינם דורשים אמינות (מנה חדשה מחליפה ישנה), בעוד אירועים חשובים (נזק, מוות) דורשים אישור — מיושם באמצעות מנגנון ACK פשוט מעל UDP. למובייל, UDP גולמי זמין דרך System.Net.Sockets.UdpClient ב-Unity או NWConnection עם פרמטר .udp ב-iOS. אנדרואיד משתמשת ב-DatagramSocket דרך Java/Kotlin. Photon Realtime משתמש בפרוטוקול משלו מעל UDP עם משלוח אמין מובנה למסרים קריטיים. LiteNetLib היא חלופה בקוד פתוח. בבדיקות השהיה, UDP מפחית את הפיגור הממוצע ב-30–40% בהשוואה ל-TCP לנתוני מיקום בזמן אמת.

פיצוי השהיה ואינטרפולציה

בצד הלקוח, אובייקטים של שחקנים אחרים אינם נעים ישירות לפי תמונות מצב — זה גורם לרעידות בחיבורים לא יציבים. אינטרפולציה: הלקוח מאחסן מאגר של 2–3 תמונות המצב האחרונות ומציג את המצב עם עיכוב של 50–100 אלפיות שנייה, תוך ביצוע אינטרפולציה ביניהן. התנועה הופכת חלקה במחיר של השהיה מלאכותית. פיצוי השהיה בשרת: כאשר שחקן A יורה בשחקן B, השרת "מחזיר" את מצב העולם אחורה ב-RTT/2 ובודק התנגשות היכן ש-B היה מנקודת המבט של A. ללא זאת, פגיעה ביריב מהיר בפינג גבוה היא בלתי אפשרית פיזית.

מאפייני פלטפורמות מובייל

מצב רקע ב-iOS (לאחר 5–10 שניות UIApplicationWillResignActiveNotification) שובר את הסוקט. השתמש ב-BGTaskScheduler לחיבור מחדש ברקע או ניתוק אלגנטי עם שמירת סשן בשרת. אנדרואיד: WakeLock ו-WifiLock לשמירת החיבור במהלך משחק. ללא WifiLock.WIFI_MODE_FULL_HIGH_PERF, מודול ה-WiFi נכנס למצב חיסכון בחשמל ומוסיף 30–80 אלפיות שנייה להשהיה. מעבר רשת מ-WiFi למובייל — ConnectivityManager.NetworkCallback באנדרואיד, NWPathMonitor ב-iOS. בעת שינוי רשת, חיבור מחדש מהיר ללא אובדן סשן המשחק.

טכנולוגיות וכלים

מה כלול בעבודה

• תיעוד ארכיטקטוני: בחירת פרוטוקול, תוכנית סנכרון, טיפול בשגיאות.
• קוד שרת: שרת סמכותי, פיצוי השהיה, דחיסת דלתא.
• אינטגרציית לקוח: חיזוי לקוח, אינטרפולציה, לוגיקת חיבור מחדש.
• בדיקות על מכשירים אמיתיים: 10+ דגמים, גרסאות מערכת הפעלה שונות.
• פריסה: הקמת תשתית שרת, ניטור.
• הכשרת צוות: סקירת קוד, תיעוד, חודש תמיכה.

שלבי פיתוח משחק מרובי משתתפים בזמן אמת

ביקורת דרישות (ז'אנר, מספר שחקנים, פלטפורמות) → בחירת מסגרת → אב טיפוס עם סנכרון מיקום בסיסי → יישום חיזוי לקוח והתאמה → פיצוי השהיה בשרת → בדיקות עומס → ליטוש למגבלות מובייל. אב טיפוס עם מולטיפלייר בסיסי ל-2-4 שחקנים: 3-4 שבועות. מערכת מלאה בזמן אמת ל-10-20 שחקנים עם פיצוי השהיה ואופטימיזציה למובייל: 2-4 חודשים. העלות מחושבת באופן אישי, אך אבות טיפוס אופייניים מתחילים ב-$5,000–$10,000 ומערכות מלאות נעות בין $20,000 ל-$50,000.

צרו קשר להערכת פרויקט. הזמינו אב טיפוס תוך 3-4 שבועות — נייעץ בנושא ארכיטקטורה ונציע פתרון אופטימלי. קבלו ייעוץ ממהנדס המתמחה במערכות מובייל בזמן אמת עם ניסיון של 10+ שנים ו-20+ כותרים ששוחררו.

החברה שלנו: 10+ שנים במובייל מרובי משתתפים, 20+ כותרים ששוחררו, 5+ שנים בשוק. סייענו ליותר מ-50 אולפנים לספק חוויות מרובי משתתפים מגיבות.