ניהול הגדרות הפרויקט של Play Games Services ב-Google Cloud

יכול להיות שתרצו לצפות בפרויקט Play Games Services ולערוך אותו ישירות ב-Google Cloud.

תרחישים נפוצים:

• הפעלת ממשקי API נוספים בפרויקט (כמו Google Drive).
• עריכת פרטי המיתוג של המשחק בתיבת הדו-שיח של OAuth 2.0.
• צפייה במכסת ה-API ובקשה להגדלת המכסה (אם צריך).
• עריכה של כתובות URI מורשות או מקורות JavaScript במזהי לקוח שיצרתם בעבר.

צפייה בפרויקט

כדי לראות את הפרויקט ב-Google Cloud:

1. בוחרים אמצעי אימות למשחק בדף הגדרות (פיתוח > Play Games Services > הגדרה וניהול > הגדרות).
2. עוברים לקטע אימות ולוחצים על הצגה ב-Google Cloud.

שינוי מכסות השימוש ב-API

ב-Google Cloud, אפשר לראות את מגבלות השימוש בממשקי ה-API שהוגדרו למשחק ואת כמות המכסה שהייתה בשימוש. אפשר גם להגדיר מגבלות לכל משתמש כדי למנוע ממשתמש פוגעני (או מלקוח משחק עם באגים) לנצל את המכסה.

כדי לראות או לשנות את מגבלות השימוש בפרויקט, או כדי לבקש להגדיל את המכסה:

1. אם עדיין אין לכם חשבון לחיוב לפרויקט, אתם צריכים ליצור חשבון כזה.
2. נכנסים לדף Enabled APIs (ממשקי API מופעלים) ב-API library ב-קונסולה לממשקי API ובוחרים API מהרשימה.
3. כדי לראות ולשנות הגדרות שקשורות למכסות, בוחרים באפשרות מכסות. כדי לראות את נתוני השימוש, בוחרים באפשרות שימוש.

חשוב לדעת שההגדרה 'משתמשים' נקבעת על סמך כתובת ה-IP של הלקוח ששולח את בקשת המכסה. לדוגמה, אם כל הבקשות שלכם מגיעות משרת אחד, יכול להיות שהשרת הזה יתויג בטעות כמשתמש ספאמי יחיד. כדי למנוע זאת, אפשר לצרף ארגומנט userIp=x.x.x.x לבקשות של נקודות הקצה ב-API.

מידע נוסף על הגדרת מכסות לכל משתמש זמין במאמר הגבלת השימוש ב-API.

בנוסף למגבלה לכל משתמש, יש מגבלה יומית לכל האפליקציה עבור Google Play Games Services API. בדרך כלל לא צריך לשנות את המגבלה שהוקצתה מראש. עם זאת, אם אתם צופים עלייה חדה בנפח (לדוגמה, לקראת אירוע השקה), אתם יכולים ללחוץ על הקישור בקשה להגדלת המכסה כדי לבקש מכסה נוספת.

הפעלת ממשקי API אחרים

כשיוצרים מזהה לקוח ב-Play Console, ממשק ה-API של Google Play Games Services מופעל אוטומטית בפרויקט. אפשר להפעיל ממשקי API אחרים של Google מ-Google Cloud.

כדי להפעיל API בפרויקט:

1. פותחים את API Library ב-Google API Console. אם מתבקשים, בוחרים פרויקט או יוצרים פרויקט חדש. בספריית ה-API מפורטים כל ממשקי ה-API הזמינים, מקובצים לפי משפחת מוצרים ופופולריות.

2. אם ה-API שרוצים להפעיל לא מופיע ברשימה, אפשר להשתמש בחיפוש כדי למצוא אותו.

3. בוחרים את ה-API שרוצים להפעיל ולוחצים על הכפתור הפעלה.

4. אם תופיע בקשה, תצטרכו להפעיל את החיוב.

5. אם מתבקשים לעשות זאת, מאשרים את התנאים וההגבלות של ה-API.

שינוי פרטי המיתוג

כדי לשנות את פרטי המיתוג (שם, לוגו וכו') של המשחק שמופיעים בתיבת הדו-שיח של OAuth 2.0, צריך להגדיר את המאפיינים במסך ההסכמה של Google Cloud.

כדי להגדיר את מסך ההסכמה של הפרויקט:

1. פותחים את הדף 'מסך בקשת הסכמה' ב-Play Console. אם מתבקשים, בוחרים פרויקט או יוצרים פרויקט חדש.
2. ממלאים את הטופס ולוחצים על שמירה.

שינוי סוג המשתמש ב-OAuth

אם אתם מבצעים בדיקות במסלול הבדיקות Production (Test and release > Production) באמצעות חשבון בדיקות אישי, אתם צריכים להגדיר גם את הגדרת קהל OAuth ב-Google Cloud כExternal. מידע נוסף מופיע במאמר בנושא ניהול קהל האפליקציה.

שינוי מאפיינים שקשורים למזהה לקוח

כדי לשנות מאפיינים שקשורים למזהה הלקוח ב-OAuth 2.0 (מקורות אינטרנט וכתובות URL להפניה אוטומטית לאפליקציית אינטרנט וכו'):

1. פותחים את Play Console ועוברים למשחק.
2. בוחרים אמצעי אימות למשחק בדף הגדרות (פיתוח > Play Games Services > הגדרה וניהול > הגדרות).
3. גוללים לתחתית הקטע אימות ולוחצים על הצגה ב-Google Cloud.
4. ב-Google Cloud, בוחרים את הפרויקט.
5. בסרגל הצד שמימין, לוחצים על APIs & auth (ממשקי API והרשאות). מוודאים שהסטטוס של Google Play Games Services API הוא ON ברשימת ה-APIs שמוצגת.
6. בסרגל הצד שמימין, בוחרים באפשרות אפליקציות רשומות.
7. מרחיבים את הקטע OAuth 2.0 Client ID (מזהה לקוח ב-OAuth 2.0) ומחפשים את המאפיין שרוצים לערוך.

העברת לקוחות OAuth מפרויקט קיים בענן

כדי לראות את הפרויקט ב-Google Cloud, פועלים לפי השלבים שמפורטים במאמר בנושא הצגת הפרויקט.

כדי להגדיר את Play Games Services (שירותי המשחקים של Play,‏ PGS), נדרש פרויקט ייחודי ב-Google Cloud. אם כמה משחקים חולקים פרויקט בענן אחד, צריך להעביר את לקוחות OAuth של Android שלהם לפרויקטים נפרדים כדי להבטיח הגדרה תקינה.

בדוגמה הקודמת, המשחקים Game 1 ו-Game 2 יצרו את לקוחות האינטרנט וה-Android שלהם במסגרת פרויקט Google Cloud יחיד לצורך כניסה באמצעות חשבון Google. אנחנו צריכים להעביר את לקוחות האינטרנט וה-Android של משחק 2 מפרויקט Google Cloud מדורי קודם הנוכחי לפרויקט Google Cloud חדש.

שלב 1: הכנה של ה-Backend

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

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

שלב 2: הגדרת לקוחות OAuth חדשים לאתר ולאנדרואיד ב-Google Cloud הנכון

שלב 2.1: יוצרים לקוח OAuth חדש לאינטרנט עבור משחק 2 בפרויקט היעד ב-Google Cloud:

שלב 2.2: אזהרה: שינוי לקוח Android ימנע ממשתמשי המשחק שלכם להיכנס למשחק באמצעות 'כניסה באמצעות חשבון Google', ולכן עליכם לוודא שאתם מבצעים את שלב 2.3 מיד אחרי שלב 2.2. מומלץ לפתוח 2 דפי אינטרנט בו-זמנית כדי לצמצם את פרק הזמן בין השינוי ליצירה מחדש של הפעולות.

משנים את שם החבילה של לקוח Android של משחק 2 בפרויקט מדור קודם ב-Google Cloud לערך לא תקין, כמו com.noexist.none.

שלב 2.3: יוצרים באופן מיידי לקוח Android חדש למשחק 2 עם אותה טביעת אצבע SHA-1 ושם חבילה של משחק 2 בפרויקט היעד ב-Google Cloud:

שלב 3: פריסת ההגדרה בזמן אמת

אחרי שיוצרים בהצלחה את לקוח Android החדש בפרויקט היעד, צריך לבצע מיד את הפעולות הבאות:

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