יצירת ספרייטים דו-ממדיים למשחק מובייל עם אופטימיזציה

מדוע ספרייטים דו-ממדיים למשחק מובייל מאבדים איכות ופריימים

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

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

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

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

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

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

מה נותנת אופטימיזציה של ספרייטים דו-ממדיים למשחק מובייל

אטלסים במקום פיזור של קבצים

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

דחיסת טקסטורות עבור מעבדים גרפיים במובייל

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

שליטה בזיכרון וסילוק קריסות

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

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

איך אנחנו יוצרים ומבצעים אופטימיזציה לספרייטים דו-ממדיים: שלבי העבודה

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

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

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

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

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

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

במה שונה אטלס ספרייטים מתמונות בודדות?

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

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

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

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

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

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

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

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

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

מה הראו המדידות

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

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

מה שינינו

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

מה יצא

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

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

ספקות לגבי תאימות, מיגרציה וחזרה לאחור — מפרקים

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

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

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

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

על הידיים לאחר המסירה אתם מקבלים:

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

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

לוחות זמנים ליצירה ואופטימיזציה של ספרייטים דו-ממדיים לפי שלבים

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

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

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

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