פרויקט Unity: רץ קז'ואל באנדרואיד ו-iOS. שחקנים עוברים 30 רמות, קונים סקינים עם מטבע במשחק וכסף אמיתי. לאחר איפוס הטלפון, ההתקדמות נעלמת ורכישות לא משוחזרות — מה שמוביל לביקורות שליליות, חיובים חוזרים וירידה של 40% בהכנסות. מצב כזה הוא סימן ברור: ללא אימות בצד השרת ושמירה בענן, המונטיזציה מבוזבזת.
אנחנו מתכננים ומיישמים מערכות אימות ופרופיל לפרויקטי משחקים ב-Unity, Unreal Engine, Godot. עם ניסיון של 5+ שנים ו-30+ פרויקטים המשרתים קהלים של 10K עד 1M+ משתמשים, אנו מבטיחים אבטחה, מיזוג חשבונות וסקלביליות תחת עומס.
איזו ארכיטקטורת אימות לבחור?
חשבון אורח (Device ID) → שדרוג לחשבון מלא. דפוס זה ממזער את חסם הכניסה. השחקן מפעיל את המשחק ללא הרשמה — נוצר חשבון אורח המקושר ל-Device ID / Apple IDFA / Android GAID. ההתקדמות נשמרת. כשהשחקן רוצה, הוא ממיר לחשבון מלא (אימייל, Apple Sign In, Google Play Games).
נקודת המפתח היא מיזוג חשבונות: שחקן עשוי להיות עם חשבון אורח במכשיר אחד וחשבון מלא במכשיר אחר. יש צורך בלוגיקת מיזוג: איזו התקדמות "זוכה"? בדרך כלל אנחנו לוקחים את הישנה יותר או את זו עם הרמה הגבוהה יותר. זו החלטה עסקית שיש לקבל מראש — לא כשהבאג הראשון מופיע.
זהות מאוחדת (Social Login). Sign In with Apple (חובה ל-iOS אם קיימים התחברויות חברתיות אחרות), Google Play Games (אנדרואיד), Facebook, Steam. אין צורך לאחסן סיסמאות — הספק מטפל באימות. אנו מקבלים טוקן JWT, מאמתים את החתימה שלו בשרת ומנפיקים טוקן סשן משלנו. בהשוואה למערכת מותאמת אישית, שילוב התחברות חברתית דרך PlayFab מקצר את זמן הפיתוח בכ-50% (מ-4 שבועות ל-2 שבועות). שימוש בקצה אחורי מוכן מאיץ את היישום פי 2.
Sign In with Apple הוא מקרה מיוחד. אפל דורשת שיטה זו אם למשחק יש לפחות התחברות צד-שלישי אחת נוספת. בנוסף, אפל עשויה להסתיר את האימייל של המשתמש ולספק אימייל ממסר. יש לקחת זאת בחשבון: אי אפשר להסתמך על אימייל כמזהה ייחודי למשתמשי אפל. תיעוד מפתחי אפל: Sign In with Apple
אימייל + סיסמה. קלאסי, אך דורש: אחסון סיסמאות באמצעות bcrypt (לא MD5 או SHA1), הגבלת קצב על נקודת הקצה של התחברות (לדוגמה, 5 ניסיונות לדקה מכתובת IP אחת), תהליך איפוס סיסמה מאובטח דרך אימייל עם טוקנים מוגבלי זמן. בקצה אחורי מנוהל (PlayFab, Nakama) זה מובנה. בפתרון מותאם אישית — צריך ליישם זאת בעצמך.
מה כלול בפרופיל השחקן?
פרופיל השחקן הוא לא רק {username, email, level}. מבנה נכון מפריד נתונים לפי סוג ותדירות עדכון:
נתוני חשבון (קבועים, משתנים לעיתים רחוקות):
-
playerId— UUID פנימי, לעולם לא משתנה -
email,username,avatarUrl -
linkedAccounts— מערך של ספקים מקושרים (google, apple, steam) -
createdAt,lastLoginAt
התקדמות משחק (קבועה, מתעדכנת לעיתים קרובות):
-
level,experience -
completedQuests[],unlockedContent[] -
inventoryId→ הפניה לאוסף נפרד (המלאי יכול להכיל עד 200 פריטים) -
statistics— הרגים, מיתות, זמן משחק, ניצחונות/הפסדים
נתוני סשן (ארעיים, לא נשמרים):
- מיקום נוכחי במשחק, שיפורים זמניים, סטטיסטיקות סשן — מאוחסנים בזיכרון השרת, לא במסד הנתונים
ההפרדה חשובה לביצועים: בכניסה למשחק, אנו טוענים רק נתוני חשבון והתקדמות בסיסית. מלאי של 200 פריטים נטען באופן עצלן כשמסך המלאי נפתח — זה מקטין את זמן הטעינה ב-40%. בפרויקט עם 500,000 MAU, כך הפחתנו את עומס מסד הנתונים בשיא ב-60%.
למה אבטחה היא קריטית?
אימות JWT בכל בקשה. טוקן סשן — JWT עם חתימת RS256 או HS256. השרת מאמת את החתימה ותוקף בכל קריאת API. תקופת תוקף — 24–48 שעות, טוקן רענון — 30–90 ימים.
אימות בצד השרת לפעולות כלכליות. הוספת מטבע, הפעלת קודי קידום, תוצאת משחק — רק דרך קוד בצד השרת. הלקוח עשוי להציג את התוצאה באופן אופטימי, אך המצב הסופי נקבע על ידי השרת. אחרת, עורך זיכרון נותן לשחקן מיליון מטבעות תוך 5 דקות.
הגבלת קצב. נקודת קצה של התחברות: מקסימום 5 ניסיונות לדקה מכתובת IP אחת. זה מגן מפני ניחוש סיסמאות. מובנה ב-PlayFab ו-Nakama. במותאם אישית — דרך Redis + חלון נע.
| שיטת אימות | זמן אינטגרציה | תכונות |
|---|---|---|
| אורח (Device ID) | 1–2 ימים | חסם נמוך, ללא שחזור |
| התחברות חברתית | 3–7 ימים | Apple Sign In חובה ב-iOS, אימייל ממסר |
| אימייל + סיסמה | 5–10 ימים | דורש bcrypt, הגבלת קצב, איפוס סיסמה |
| זהות מאוחדת | 2–4 שבועות | תלוי במספר הספקים |
איך פתרנו את בעיית מיזוג החשבונות בפרויקט אמיתי
מקרה אמיתי: רץ קז'ואל, אנדרואיד+iOS. בתחילה רק שמירה מקומית. לאחר הוספת מונטיזציה (סקינים דרך IAP) — היה צורך דחוף בשמירה בענן. הוספנו אימות PlayFab (אורח + Google Play Games + Apple Sign In) תוך שבועיים. הבעיה הבלתי צפויה: חלק מהשחקנים היו עם התקדמות באנדרואיד תחת חשבון Google וניסו להתחבר ב-iPad — מיזוג החשבונות יצר קונפליקט. היה צורך במסך נוסף "בחר איזו התקדמות לשמור", ועוד 3 ימי עידון. פתרון: בקונפליקט, הצגת שני הפרופילים, השחקן בוחר. אוטומטי — אם הפרש הרמות גדול מ-5, קח את הגבוהה יותר. גישה זו הפחיתה פניות לתמיכה ב-30% והקטינה את נטישת השחקנים לאחר החלפת מכשיר ב-15%.
תהליך היישום
- בחירת ספק זהות ועיצוב זרימת התחברות: אורח → חברתי → אימייל. זו החלטת UX עם השלכות טכניות.
- עיצוב סכמת נתוני פרופיל עם חשיבה על צמיחה עתידית (מספר פריטים, מערכת שבט).
- יישום אימות בצד השרת לכל הפעולות הכלכליות.
- בדיקת מקרי קצה: אובדן חיבור במהלך שמירה, שכפול חשבון בהתקנה מחדש, פקיעת טוקן במהלך סשן משחק.
- פריסה ותמיכה למשך 30 יום.
מה כלול בעבודה?
- עיצוב ארכיטקטורת זרימת אימות וסכמת נתונים
- אינטגרציה של אימות אורח, התחברויות חברתיות, אימייל/סיסמה
- יישום טוקני JWT ולוגיקת רענון
- אימות בצד השרת של כל הפעולות הכלכליות
- יצירת תיעוד והעברת גישה
- 30 ימי תמיכה לאחר הפריסה
| היקף המשימה | לוח זמנים משוער |
|---|---|
| אימות אורח + שמירה בסיסית בענן (PlayFab/Nakama) | 1–2 שבועות |
| אימות מלא (התחברויות חברתיות + אימייל) + פרופיל | 2–4 שבועות |
| מערכת אימות מותאמת אישית + JWT + PostgreSQL | 3–6 שבועות |
| מיזוג חשבונות + העברה משמירה מקומית | 1–2 שבועות |
העלות מחושבת לאחר ניתוח דרישות. כדי לקבל הערכה לפרויקט שלך, צור איתנו קשר — נכין הצעה מסחרית המותאמת לסטאק ולהיקף שלך. קבל ייעוץ על ארכיטקטורת אימות.