שיבוטים ב-Scratch: אויב אחד, עשרות מופעים וקוד אחד
המשחק עובד מצוין עם מטאור אחד. ואז מגיעה הדרישה הבאה: ״עכשיו שיהיו שלושים, וכל אחד ייפול ממקום ובמהירות אחרים״. במקום לשכפל את הדמות ידנית, נלמד לבנות מקור אחד שמייצר מופעים זמניים ומנהל לכל אחד מחזור חיים ברור.
לא מעתיקים אויב — מגדירים תבנית
העתקה ידנית של דמות יכולה לעבוד פעמיים או שלוש, אבל מהר מאוד נוצרים שמות רבים, קוד כפול ותיקונים שצריך לבצע בכל עותק. שיבוט פותר את הבעיה בדרך אחרת: דמות אחת משמשת כתבנית, והמשחק יוצר ממנה מופעים רק כשהם נחוצים.
זהו רעיון חשוב גם מעבר ל-Scratch. במשחקים ובתוכנות רבות מפרידים בין ההגדרה של אובייקט לבין המופעים הפעילים שלו. ב-Scratch אפשר לראות את ההפרדה הזאת בלי להסתבך בתחביר.
ארבעה רגעים שצריך לדעת להסביר
שיבוט אינו דמות חדשה בעורך. הוא מופע זמני שקיים בזמן שהפרויקט רץ. מעקב אחרי ארבעת הרגעים האלה עוזר להבין מי יוצר אותו, מה הוא עושה ומתי הוא מפנה את הבמה.
- 01
המקור ממתין
דמות המקור מחזיקה את התלבושות והקוד. במשחק המטאורים היא מוסתרת כדי שלא תיראה כמו מטאור נוסף.
- 02
נוצר שיבוט
בלוק היצירה מוסיף מופע חדש של הדמות. הוא מקבל את המראה, המיקום והערכים שהיו למקור באותו רגע.
- 03
השיבוט מתחיל
האירוע „כאשר אני מתחיל כשיבוט” מפעיל את ההתנהגות של המופע החדש: מיקום, תנועה, בדיקת פגיעה ועוד.
- 04
השיבוט נמחק
כשהמטאור יוצא מהמסך או פוגע בשחקן, מוחקים את המופע. דמות המקור והקוד שלה נשארים מוכנים לסיבוב הבא.
מחלקים אחריות בין המקור למופע
דמות המקור היא מנהלת הייצור: היא מסתתרת, ממתינה זמן קצר ויוצרת שיבוט. כל שיבוט אחראי רק לחיים שלו: לבחור נקודת התחלה, ליפול, לבדוק פגיעה ולמחוק את עצמו.
ההפרדה הזאת מונעת סקריפט ענק שמנסה לנהל הכול. היא גם נותנת בדיקת דיבאגינג פשוטה: תקלה בקצב היצירה שייכת למקור; תקלה בתנועה או במחיקה שייכת לשיבוט.
הערת דיוק
חומרי Scratch שנמסרו למכללה כוללים משתנים, לולאות, תנאים, תנועה ולוגיקת משחק. התרגיל כאן מחבר את היסודות האלה לדוגמת שיבוטים; הוא אינו תיאור מחייב של תוכן במחזור לימודים מסוים.
הסקריפט של דמות המקור
when green flag clicked hide forever wait (pick random 0.4 to 1.2) seconds create clone of myself
הסקריפט של כל שיבוט
when I start as a clone set speed to (pick random 3 to 7) go to x: (pick random -210 to 210) y: 170 show repeat until <touching player or y position < -170> change y by (0 - speed) end if <touching player> then change lives by -1 delete this clone
ערך משותף או זיכרון פרטי?
שיבוטים חולקים את הקוד של הדמות, אבל לא כל נתון חייב להיות משותף. לפני שיוצרים משתנה, כדאי להחליט אם הוא מתאר את כל המשחק או מופע יחיד.
משתנה לכל הדמויות
למשל: ניקוד, חיים או שלב
כל השיבוטים קוראים ומשנים את אותו ערך. אם מטאור אחד מוסיף נקודה, לוח הניקוד של המשחק מתעדכן לכולם.
האם כל המופעים צריכים להסכים על אותו ערך?
משתנה לדמות הזאת בלבד
למשל: מהירות, עוצמה או סוג של מטאור
לכל שיבוט יש עותק משלו. כך מטאור מהיר אינו משנה בטעות את המהירות של כל שאר המטאורים.
האם לכל מופע מותר להחזיק ערך שונה?
לא מנחשים: מחפשים הוכחה קטנה
כשמופעים רבים פועלים יחד, קל להרגיש שהתקלה אקראית. הטבלה מחזירה לכל סימפטום חשד שאפשר לבדוק בניסוי אחד.
| מה רואים | מה ייתכן שקרה | בדיקה שמביאה ראיה |
|---|---|---|
| כל המטאורים זזים באותה מהירות | המהירות הוגדרה כמשתנה משותף. | מציגים את המשתנה ומשנים אותו בשיבוט אחד. אם כולם מגיבים, בודקים את היקף המשתנה. |
| נשאר מטאור קפוא בתחתית | מסלול כלשהו מסתיים בלי מחיקת השיבוט. | מסמנים כל תנאי יציאה ובודקים שלכל אחד מהם מגיע בלוק „מחק שיבוט זה”. |
| בתחילת המשחק מופיע מטאור מיותר | דמות המקור אינה מוסתרת. | לוחצים על הדגל הירוק לפני שנוצר שיבוט ובודקים אם המקור כבר נראה על הבמה. |
| אחרי זמן המשחק נעשה עמוס או איטי | נוצרים מופעים מהר יותר משהם נמחקים. | מאריכים זמנית את ההמתנה בין יצירות ובודקים אם העומס נעלם; אחר כך מתקנים את הניקוי. |
סולם שדרוגים שלא שובר את המודל
מוסיפים שינוי אחד, חוזים מה יקרה ורק אז מריצים. הפרויקט גדל, אבל האחריות נשארת ברורה: המקור יוצר וכל מופע מנהל את עצמו.
- 01
שינוי חזותי
בחרו לכל שיבוט תלבושת אקראית. בדקו אם שינוי התלבושת צריך לקרות לפני היצירה או בתוך אירוע ההתחלה שלו.
- 02
שינוי התנהגותי
הוסיפו משתנה מקומי בשם „מהירות” והגרילו לכל מטאור ערך אחר. כעת הסבירו למה המשתנה אינו משותף.
- 03
שינוי מערכתי
צרו קצב הופעה משותף שהולך ומתקצר בהדרגה, אך השאירו גבול שמונע מהמשחק להפוך לבלתי קריא.
ציירו את החיים של שיבוט אחד
לפני שמוסיפים עוד אויבים, כתבו ארבע שורות: מאיפה המופע נוצר, אילו ערכים פרטיים הוא מקבל, מה משנה את המצב שלו, ובאיזה תנאי הוא נמחק. אם אפשר להסביר את המסלול בלי לפתוח את הפרויקט, הקוד כבר נשען על מודל ולא על ניסוי מקרי.