פיתוח משחק מילים לנייד: מ-Trie ועד משחק מרובה משתתפים

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות הרכבה של המילון ובדיקת מהלכים: השוואת גישות

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

חלופות טכניות

כיצד בוחרים בפועל

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

שלבי העבודה: מפירוק המילון ועד מסירת החבילה

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

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

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

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

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

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

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

הרכב האספקה: סכמות נתונים, כללי מהלכים, תיעוד

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

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

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

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

מה הראו המדדים לפני העיבוד מחדש

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

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

מה שינו ומה יצא

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

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

במה שונה בדיקת מהלכים בשרת מבדיקה מקומית?

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

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

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

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

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

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

ספקות טכניים: מילון, השהיות, עדכונים

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

להלן תשובות למה ששואלים הכי הרבה בשלב ההערכה.

מה עם השהיית ההיענות במכשיר חלש?

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

כמה עבודה מוסיפה שפה שנייה במשחק?

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

כיצד מתבצע המעבר לפלטפורמה שנייה?

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

מי אחראי על מודרציה של מילים?

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

דיון במשימה: מה יידרש מכם וכיצד תתקדם העבודה

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

מה יידרש מכם:

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

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