פיתוח ואינטגרציה של Backend שרתי למשחק ב-Xbox Live

מצבי אונליין נשברים כאשר החלק השרתי אינו מותאם לעומס אמיתי: משחקים נקטעים, שחקנים עוזבים. אנו מפתחים ומשלבים Backend שרתי למשחקים ב-Xbox Live במפתח מלא — מתכנון ועד השקה ותמיכה. אונליין אמין מפחית נשירת שחקנים ומחזיק את הקהל במשחק.

היכולות שלנו

שירותי סטודיו אחרים

יישומי VR/AR/MR מותאמים אישית

טבלו לקוחות וצוותים בחוויות דיגיטליות חדשות

פיתוח משחקי Unity

מקונספט לשחרור — משחקים שאנשים זוכרים

מידול ואנימציה בתלת-ממד

החיו את המוצר שלכם בגרפיקת תלת-ממד ואנימציה

סימולטורי ציוד VR תעשייתיים

אמנו מפעילים על ציוד בבטחה, ללא השבתה

הוראות AR לייצור

הנחיות שלב-אחר-שלב ישירות על הציוד — ללא נייר

סימולטורי VR לבטיחות

תרגול תגובה לשעת חירום ללא צורך בהגעה לשטח

תוכניות הכשרה ב-VR/AR

הכשרת עובדים בשירות, קליטה ומיומנויות רכות ב-VR

חידוני הכשרה לעובדים

בדיקת ידע באמצעות משחקים — בקלות וללא לחץ

הוראות וידאו ארגוניות

סרטונים ברורים להכשרת העובדים והלקוחות שלכם

גיימיפיקציה עסקית

הניעו צוותים עם מכניקת משחק ב-KPI ובמשאבי אנוש

יישומי קיוסק אינטראקטיביים

מסכים אינטראקטיביים לקמעונאות, תערוכות ומשרדים

מתקני VR/AR

אפקט וואו למותגים בתערוכות, אירועים וחדרי תצוגה

תערוכות ומוזיאונים וירטואליים

התערוכות שלכם מגיעות לכל פינה בעולם, 24/7

מסעות אירועים ומשחקי מותג

משחקים בלתי נשכחים לכנסים ולאירועי לקוחות

שאלות נפוצות

העבודות האחרונות

  • פיתוח משחקים עבור Mortal Motors
    פיתוח משחקים עבור Mortal Motors
    1638
  • משחק אסטרטגיה מבוסס תורות המתרחש בעולם פנטזיה, With Fire and Sword
    משחק אסטרטגיה מבוסס תורות המתרחש בעולם פנטזיה, With Fire and Sword
    1122
  • פיתוח משחק עבור חברת Second term
    פיתוח משחק עבור חברת Second term
    751
  • אנימציית תלת-ממד - טיזר למשחק Phoenix 2.
    אנימציית תלת-ממד - טיזר למשחק Phoenix 2.
    830

פיתוח משחקים בהתאמה לצורכי העסק: מדוע הפרויקט נתקע בלי שרת אמין

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

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

הצוות עצמו לא מבין מי בכלל אחראי על השרת: המפתחים אומרים שזו "תשתית", אנשי התשתית — ש"זה הקוד של המשחק".

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

אין צורך לחפש קבלן נפרד לשרת ולחבר אותו עם צוות הגיימפליי — האחריות ליציבות המשחק המקוון מוטלת עלינו מהאב-טיפוס הראשון ועד לשחרור ולעדכונים.

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

כבר עברנו את הדרך הזו בפרויקטים בקני מידות שונים ואנחנו יודעים איפה זה בדרך כלל נקרע — לכן אנחנו מניחים מרווח ביטחון מראש, ולא מטכסים חורים אחרי השחרור.

מה מקבל הלקוח: מאונליין יציב ועד לצמיחה בשימור

אונליין יציב הוא לא מאפיין טכני, אלא סעיף הכנסה ישיר. כששחקן מאבד התקדמות בגלל ניתוק הסשן או לא מצליח למצוא יריב במשחק דירוג, הוא לא כותב לתמיכה — הוא просто מוחק את המשחק ומשאיר ביקורת שלילית. אנחנו סוגרים בדיוק את האזור הזה: הצד השרת עובד כך שהשחקן חוזר, ולא עוזב אחרי הסשן הכושל הראשון.

שימור שחקנים מתחיל מאמון במשחק. אם ההתקדמות, הרכישות וההישגים נשמרים בכל תקלת תקשורת, לשחקן אין סיבה לעזוב — ואצלכם גדל חלק אלה שחוזרים ביום השני והעשירי.

אנחנו מתכננים את הלוגיקה בצד השרת כך שהנתונים לא הולכים לאיבוד גם בניתוקים חדים, וזה משפיע ישירות על מדדי השימור, ולא רק על "הבריאות הטכנית" של הפרויקט.

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

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

זה משפיע על הנראות של המשחק בחנות ועל ההחלטה של שחקנים חדשים להוריד אותו — כלומר על החשיפה וההכנסות בלי השקעה נוספת בפרסום.

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

פורמטים של עבודה: לפי המשימה, לוחות הזמנים והקנה מידה של המשחק שלכם

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

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

כיצד לבחור פורמט

התמקדו במטרה הקרובה, לא בסופית. אם בעוד חודש יש טורניר או אירוע עונתי — מתחילים בשדרוג השרת כדי לעמוד בשיא. אם לפניכם השקה — הולכים לפיתוח מקצה לקצה וסוגרים את כל המחזור: מחשבונות משתמש, הישגים, דירוגים, רכישות, אינטגרציה עם הפלטפורמה Xbox Live.

כיצד הפורמטים משתלבים

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

איך מתנהל הפרויקט: מהבריף ועד ההשקה והתמיכה

פרויקט של משחק הוא לא "עשינו ומסרנו", אלא תהליך מנוהל עם נקודות בקרה ברורות. הלקוח בכל שלב רואה מה קורה, כמה זמן זה לוקח ומה הוא יקבל בסוף. להלן איך אנחנו מנהלים את העבודה, כדי שלא יהיו לכם הפתעות לא בלוחות הזמנים ולא בתוצאה.

  1. בריף ומטרות. דנים במשימה: למי מיועד המשחק, באילו פלטפורמות הוא יוצא, ואיזו תוצאה נחשבת להצלחה — שימור שחקנים, חשיפה, חזרות. אנחנו מתעדים זאת בכתב, כדי שבהמשך להשוות לתמונה הכוללת ולא לזיכרונות.
  2. תוכנית פרויקט ואומדן. מחלקים את העבודה לשלבים עם תאריכים ואחראים. אתם רואים מה נעשה בכל שבוע ומי אחראי על מה מכל צד. האומדן צמוד לשלבים — התשלום מתבצע לפי תוצאות שהתקבלו בפועל.
  3. תיאום ואישור. עוברים על התוכנית יחד איתכם: מה נכלל בהיקף, מה נשאר מחוץ למסגרת, והיכן אפשריים פיצולים. תיקונים בשלב הזה עולים הכי פחות, ולכן אנחנו לא חוסכים זמן על הבהרות.
  4. ביצוע. עובדים באיטרציות: כל 1-2 שבועות מציגים תוצאה עובדת שאפשר לגעת בה, ולא דוח על התהליך. אתם משפיעים על המשחק תוך כדי, ולא מגלים על ההחלטה בסוף.
  5. הרצת בדיקה. מוציאים את המשחק לקהל סגור, בוחנים את התנהגות השחקנים ואת היציבות תחת עומס. מוצאים את נקודות התורפה לפני שהשחקנים שלכם והמוניטין של המותג יראו אותן.
  6. יציאה לקרב. מפרסמים את המשחק, עוקבים אחרי הימים הראשונים בתנועה אמיתית, וסוגרים במהירות שאלות שעולות.
  7. ליווי לאחר ההשקה. נשארים בקשר: עדכונים, תוכן עונתי, שיפורים לפי משוב מהשחקנים. ההשקה היא התחלה, לא סיום.

סדר כזה מסיר את הסיכון העיקרי — לגלות על בעיה כשכבר יקר לשנות משהו. תארו את המשימה — נחזור עם אומדן ותוכנית לפי שלבים.

מה ייכלל באספקה: ערכה לצוות שלכם

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

  • שרת עובד בקונטור שלכם. לוגיקת המשחק, חשבונות משתמשים, התקדמות השחקנים, דירוגים, רכישות ואירועים — הכול פרוס, נבדק תחת עומס ומוכן לקבל שחקנים אמיתיים ב-Xbox Live.
  • תיעוד מלא. תרשים האינטראקציה בין הלקוח לשרת, תיאור שירותי המשחק, הוראות פריסה ועדכון, סדר הפעולות בעת תקלות — בשפה מובנת, ולא אוסף הערות "לעצמנו".
  • גישות והרשאות. כל חשבונות המשתמשים, לוחות הבקרה, המפתחות והמאגרים מועברים אליכם. אתם הבעלים של הפרויקט ואינכם תלויים בצוות שלנו בעבודה השוטפת.
  • הדרכת הצוות שלכם. מקיימים מפגשים מעשיים עם המפתחים והמנהלים שלכם: כיצד לשחרר עדכונים, לקרוא לוגים, להגיב לאירועים ולחבר מכניקות משחק חדשות.
  • נהלי תפעול. כללים כתובים לגיבוי, ניטור, עדכונים וטיפול בתקלות — כדי שהאיכות לא תישען על אדם אחד ולא תיפול בעת החלפת הרכב.
  • תמיכת אחריות. לאחר ההשקה נשארים בקשר: מתקנים פגמים, מסייעים במצבים לא שגרתיים ומלווים את העדכונים הראשונים, עד שהצוות שלכם צובר ביטחון.
  • מסירת הפרויקט turnkey. פגישה מסכמת שבה נעבור יחד על כל הסעיפים, נתעד את תחומי האחריות ונענה על השאלות שנותרו.

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

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

אלינו פנה מפיץ של משחק מרובה משתתפים ב-Xbox Live עם כאב אופייני לפרויקט בצמיחה: שחקנים התלוננו על ניתוקי חיבור בעיצומו של משחק ועל איתור יריבים ממושך. הנשירה גברה, והביקורות הטריות בחנות הצטמצמו יותר ויותר ל"המשחק טוב, אבל אי אפשר לשחק".

המשימה לא נוסחה כ"לשכתב את השרת", אלא כ"להחזיר לאנשים את הרצון להיכנס שוב בערב".

מה עשינו

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

עבדנו מחדש על ארכיטקטורת השרת לעומסי שיא ובנינו מחדש את איתור היריבים כך שמשחקים יתכנסו במהירות גם בשעות העומס.

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

מה השתנה במדדים

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

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

איך לבחור את הפורמט המתאים למשימה?

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

ואם הכול עובד, אבל הצוות לא רוצה להחזיק את זה על עצמו — תתאים תמיכה ופיתוח. אנחנו שואלים כמה שאלות הבהרה ואומרים בכנות איזה משלושת התרחישים הוא שלכם — בלי לנסות למכור את היקר ביותר.

היקף הפרויקט נקבע לא לפי מספר הפונקציות, אלא לפי כמה שחקנים בו-זמנית צריכים להישאר במשחק בלי תקלות וכמה מהר אתם מתכננים לגדול. פרויקט קטן עם כמה אלפי סשנים בו-זמנית ופרויקט עם מאות אלפים — אלה ארכיטקטורה שונה, לוחות זמנים שונים ומרווח עמידות שונה.

לכן אנחנו קודם מקבעים את היקף היעד, ורק לפיו בוחרים פתרון: כך אתם לא משלמים יותר מדי על כוח עודף ולא נתקלים בתקרה חצי שנה אחרי ההשקה.

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

התמקדו בשלושה דברים: האם יש לכם שרת ונתונים עובדים, איזה היקף שחקנים אתם מתכננים וכמה דחוף לכם התוצאה. זה מספיק כדי שנחזור עם הערכה ותוכנית — ואתם תבחרו פורמט במודע, ולא באקראי.

ספקות נפוצים של לקוחות לפני התחלה

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

"ומה אם השרת יקרוס בדיוק בשיא?"

שיא הוא כאשר יש לכם בו-זמנית עומס מקסימלי ומחיר טעות מקסימלי: טורניר, השקת עונה, גל פרסום. אנו מתכננים לתרחיש שיא, ולא ליום ממוצע: בודקים מראש את התנהגות המערכת בעומס גבוה מהצפוי ומכינים תוכנית למקרה של תקלה. אם משהו ישתבש — יש לנו תורנות ונהלי תגובה, ולא "כתבו, נסתכל".

"ומה אם הצוות הנוכחי לא יעביר את הגישות?"

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

"ומה אם הדרישות ישתנו תוך כדי?"

שינויים אינם תקלה, אלא סימן נורמלי למוצר חי. השאלה אינה אם לשנות, אלא כיצד זה משתקף בלוחות הזמנים ובהיקף. אנו עובדים באיטרציות: אתם רואים תוצאה כל 1-2 שבועות ויכולים לתקן סדרי עדיפויות לפני שהתיקון הופך ליקר.

מה אם נשנה את דעתנו באמצע הפרויקט?

אנו מתעדים שלבים ואת התוצאה של כל אחד מהם. אתם תמיד רואים מה כבר נעשה ומה נותר — ויכולים לעצור בגבול של שלב, ולקחת את החלק המוכן ואת התיעוד. אנו לא קושרים אתכם אלינו באופן מלאכותי.

אילו ערבויות שיש לאחר המסירה הכל ימשיך לעבוד?

לאחר ההשקה אנו מעבירים תיעוד ונשארים בתמיכה: עוקבים אחר היציבות, מגיבים לאירועים, מבצעים תיקונים. ערבות היא לא שורה בחוזה, אלא נהלים ברורים: מי אחראי, תוך כמה זמן, מה עושים בעת תקלה.

בואו נדון במשימה שלכם ונחזור עם הערכה ותוכנית

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

לאחר הפנייה אתם מקבלים קונקרטיקה, לא הבטחות:

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

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

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

תארו את המשימה בצורה נוחה — בקצרה, במילים שלכם. אנחנו נלמד את הפרטים, נשאל שאלות הבהרה ונחזור עם הערכה, תוכנית והרכב הצוות. לאחר מכן אתם מחליטים אם אנחנו מתחילים — בלי לחץ ובלי שלבים כפויים.