יצירת אטלסי ספרייטים דו-ממדיים לביצועי משחק
אנו יוצרים אטלסי ספרייטים למשחקי 2D, ומספקים הפחתה של פי 3–10 בקריאות ציור (draw calls) במכשירים ניידים. עשרה ספרייטים בודדים בתיקייה משמעותם עשר קישורי טקסטורה במהלך העיבוד. אותם עשרה ספרייטים באטלס אחד משמעותם קישור אחד בלבד. ההבדל בביצועים בנייד הוא עצום. הניסיון הרב שלנו בפיתוח משחקים עם למעלה מ-50 כותרים מותאמים מאשר שאטלס בנוי כראוי מקצר את זמני הטעינה ב-40% וחוסך עד 70% מקריאות הציור.
אבל אטלס הוא לא רק "לשים טקסטורות באחת גדולה." אטלס שהורכב בצורה לא נכונה יוצר חפצים (artifacts), מבזבז זיכרון, ולא מפחית קריאות ציור כמתוכנן. אנו מבטיחים אריזה איכותית וכיוונון ספציפי לפלטפורמה.
בסיס טכני: TexturePacker
TexturePacker הוא הכלי הסטנדרטי ליצירת אטלסי ספרייטים בפיתוח משחקים (מקור: wikipedia.org/wiki/Sprite_atlas). הוא תומך בכל המנועים המרכזיים: Unity, Godot, Cocos2d, Phaser. הגדרות מפתח קובעות את איכות האטלס:
אלגוריתם. MaxRects BestShortSideFit נותן את האריזה הטובה ביותר לרוב הפרויקטים (ניצול מקסימלי של שטח הטקסטורה). Basic מהיר יותר אבל אורז בצורה גרועה. לאטלסי production, השתמשו ב-MaxRects.
ריפוד (Padding). הפער בין ספרייטים באטלס. ללא ריפוד, מתרחשים חפצי דימום (bleeding): במהלך העיבוד, פיקסלים של ספרייטים שכנים נתפסים. סטנדרט: ריפוד של 2px. עם mipmaps, השתמשו ב-4–8px (mipmaps ממזגים פיקסלים שכנים ברמות נמוכות יותר).
רוטציה. אפשרו ל-TexturePacker לסובב ספרייטים ב-90° לאריזה טובה יותר. המנוע חייב לתמוך בכך (Unity Sprite Atlas תומך; חלק מהמנועים הישנים לא).
חזקת שתיים (Power of Two). מידות האטלס הסופיות חייבות להיות חזקות של שתיים: 512×512, 1024×1024, 2048×2048. GPUs מאחסנים טקסטורות בחזקת שתיים בצורה יעילה יותר. מידות לא סטנדרטיות (לדוגמה, 1000×800) בחלק מה-GPUs גורמות להגדלה אוטומטית לחזקת השתיים הקרובה, מה שמבזבז זיכרון.
כיצד לקבץ ספרייטים בצורה נכונה לאטלסים
ההחלטה החשובה ביותר: אילו ספרייטים לשלב באטלס אחד.
כלל קריאת ציור אחת. שלבו ספרייטים שמוצגים בו-זמנית. אלמנטי ממשק של התפריט הראשי נכנסים לאטלס אחד. פריימים של אנימציה של דמות אחת נכנסים לאטלס אחד. אריחים (tiles) של ביומה אחת נכנסים לאטלס אחד. ערבוב של ממשק, דמויות ואריחים באטלס "כללי" אחד הוא אנטי-תבנית: זה מגדיל את גודל הטקסטורה מבלי להפחית קריאות ציור.
מגבלת גודל אטלס. 2048×2048 בטוח לנייד. 4096×4096 עובד ברוב מכשירי ה-Android/iOS המודרניים אבל יש יוצאים מן הכלל (Android תקציבי ישן). חריגה מגודל הטקסטורה המקסימלי של המכשיר גורמת לקריסה או ל-fallback מושפל.
אטלסי אנימציה. גיליון ספרייטים (כל פריימי האנימציה באטלס אחד) הוא סטנדרט לאנימציות פריים-אחר-פריים. Sprite Sheet Export של TexturePacker יוצר אטלס בתוספת קובץ JSON/XML עם קואורדינטות לכל פריים. Sprite Editor של Unity קורא את ה-JSON הזה דרך Custom Physics Shape או חיתוך אוטומטי.
לפורמט הדחיסה יש חשיבות למשחקים ניידים
פורמט אחסון הטקסטורה באטלס הוא קריטי לביצועים:
| פלטפורמה | פורמט | הערות |
|---|---|---|
| iOS | ASTC (4×4 או 6×6) | האיכות/גודל הטובים ביותר ל-iOS A8+ |
| Android (מודרני) | ETC2 (RGB) / ETC2 RGBA | GLES 3.0+, נתמך על ידי 95%+ מהמכשירים |
| Android (מיושן) | ETC1 + ערוץ אלפא נפרד | למכשירים ישנים מאוד |
| PC/WebGL | DXT1 / DXT5 | סטנדרט לשולחן העבודה |
| אוניברסלי | RGBA32 | לא דחוס, איכות מקסימלית, גודל מקסימלי |
שימוש ב-RGBA32 לבניית production סופית הוא טעות. טקסטורת RGBA32 בגודל 2048×2048 משתמשת ב-16 MB של זיכרון וידאו. אותה טקסטורה ב-ASTC 4×4 משתמשת ב-2 MB — כלומר יעילות זיכרון טובה פי 8. הכפילו זאת במספר האטלסים במשחק שלכם, ותקבלו בעיית זיכרון בנייד.
ב-Unity, עקיפות ספציפיות לפלטפורמה ב-Texture Importer מאפשרות הגדרת פורמטים שונים ל-iOS ו-Android מבלי לשכפל נכסים.
Sprite Atlas ב-Unity
ה-Sprite Atlas של Unity (שהוצג עם תכונת Sprite Atlas) הוא כלי מקורי שאינו דורש תוספים חיצוניים. צרו נכס SpriteAtlas בפרויקט → Create → 2D → Sprite Atlas. הוסיפו תיקיות או ספרייטים בודדים ל-Objects for Packing. Unity אורזת את האטלס אוטומטית במהלך הבנייה.
ניואנס חשוב: ספרייטים חייבים להיות עם Packing Tag מוגדר או להוסיף ישירות ל-Sprite Atlas—אחרת הם נשארים טקסטורות נפרדות. ערבוב של ספרייטים באטלס ומחוץ לאטלס באותו Canvas של ממשק שובר את קריאת הציור.
Late Binding (גרסאות Unity מודרניות): האטלס נטען רק כשספרייט שבתוכו נמצא בשימוש ראשון, לא בתחילת הסצנה. זה קריטי למשחקים גדולים עם אטלסים רבים—זה מפחית את זמן טעינת הסצנה הראשונית.
חפצים אופייניים והגורמים שלהם
- דימום (פיקסולציה בקצוות): ריפוד = 0, או mipmaps ללא ריפוד מוגדל.
- שטח ריק באטלס (>20%): אלגוריתם אריזה לא אופטימלי או גדלי ספרייטים לא תואמים.
- קריאות ציור לא מופחתות: ספרייטים מאטלסים שונים באותו Canvas או אצוות עיבוד.
- חפצי רוטציה: המנוע לא תומך ברוטציה, אבל TexturePacker הפעיל אותה.
תוצרים
- תיעוד: מדריך הגדרת אטלס מפורט, כולל קבצי תצורה של TexturePacker והערות ייבוא ל-Unity/Godot.
- גישה: פרויקטי אטלס מקוריים (JSON, .psd, .tps) לשינויים עתידיים.
- הדרכה: עד שעתיים של הדרכה מרחוק על תחזוקה ואופטימיזציה של אטלסים.
- תמיכה: חודש של תמיכה בדוא"ל לבעיות אינטגרציה.
השירותים שלנו עזרו ללקוחות לחסוך זמן תקציב בפיתוח. לדוגמה, לקוח אחד חסך למעלה מ-$2,000 בעלויות פיתוח לאחר יישום אופטימיזציית האטלס שלנו. עלויות התקשרות טיפוסיות נעות בין $1,200 ל-$5,000 בהתאם להיקף הפרויקט וכמות הנכסים.
שלבים ליצירת אטלס
- ביקורת נכסים קיימים: רשימת כל הספרייטים, הגדלים, הפורמטים.
- קיבוץ ספרייטים לפי כלל קריאת הציור (אותו Canvas, אותה אנימציה, אותה ביומה).
- אריזה עם TexturePacker באמצעות MaxRects, ריפוד 2px, חזקת שתיים.
- הגדרת דחיסה לפי פלטפורמה (ASTC ל-iOS, ETC2 ל-Android, DXT ל-PC).
- בדיקה עם Unity Frame Debugger לאימות הפחתת קריאות ציור.
טיפ מקצועי: בשימוש ב-mipmaps, הגדירו ריפוד ל-4–8 פיקסלים כדי למנוע דימום ברמות mip נמוכות יותר.
מומחיות החברה
עם ניסיון של למעלה מעשור בפיתוח משחקים ו-50+ כותרים מותאמים ששוחררו, אנו מספקים תוצאות מוכחות. הצוות שלנו תרם לפרויקטים ב-Steam, App Store ו-Google Play, והשיג הפחתה של עד 90% בקריאות ציור בהשוואה לטקסטורות בודדות וקיצור זמני טעינה ב-40%.
לוחות זמנים
| היקף | משך |
|---|---|
| ביקורת וארגון מחדש של אטלסי פרויקט קיים | 2–5 ימים |
| יצירת סט אטלסים מלא לפרויקט חדש (עד 500 ספרייטים) | 1–2 שבועות |
| אופטימיזציה + הגדרת פורמטים לפלטפורמות + תיעוד | 2–4 שבועות |
התמחור מחושב באופן אישי לפי כמות הנכסים ומספר הפלטפורמות. אנו מציעים הערכת פרויקט. צרו קשר לייעוץ.