משחק Rust ב-24 שעות: חווית התפתחות אישית

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

Skillbox ממליצה: קורס מעשי שנתיים "אני מפתח אתרים PRO".

אנו מזכירים: לכל קוראי Habr - הנחה של 10 רובל בעת הרשמה לכל קורס Skillbox באמצעות קוד ההטבה של Habr.

למה חלודה?

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

למה המשחק ואיזה סוג של משחק?

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

אימון טכני

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

מצאתי משאבים שימושיים שאני חולק איתך:

• אנחנו משחקים כבר - רשימה של רכיבי Rust הדרושים לפיתוח משחקים;
• מפתח משחק חלודה subreddit;
• אמנות פיקסלים בחינם.

חקרתי כמה מנועי משחק Rust, בסופו של דבר בחרתי Piston ו-ggez. נתקלתי בהם כשעבדתי על פרויקט קודם. בסופו של דבר, בחרתי ב-ggez כי זה נראה מתאים יותר ליישום משחק דו מימדי קטן. המבנה המודולרי של Piston מורכב מדי עבור מפתח מתחיל (או מישהו שעובד עם Rust בפעם הראשונה).

מבנה המשחק

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

לאחר שחשבתי הכל, התחלתי לעבוד.

יצירת משחק

התחלה: מעגלים והפשטות

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

// the game object trait
trait GameObject {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()>;
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()>;
}
 
// a specific game object - Circle
struct Circle {
    position: Point2,
}
 
 impl Circle {
    fn new(position: Point2) -> Circle {
        Circle { position }
    }
}
impl GameObject for Circle {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()> {
        Ok(())
    }
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()> {
        let circle =
            graphics::Mesh::new_circle(ctx, graphics::DrawMode::Fill, self.position, 100.0, 2.0)?;
 
         graphics::draw(ctx, &circle, na::Point2::new(0.0, 0.0), 0.0)?;
        Ok(())
    }
}

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

mpl event::EventHandler for MainState {
    fn update(&mut self, context: &mut Context) -> GameResult<()> {
        // Update all objects
        for object in self.objects.iter_mut() {
            object.update(context)?;
        }
 
        Ok(())
    }
 
    fn draw(&mut self, context: &mut Context) -> GameResult<()> {
        graphics::clear(context);
 
        // Draw all objects
        for object in self.objects.iter_mut() {
            object.draw(context)?;
        }
 
        graphics::present(context);
 
        Ok(())
    }
}

main.rs נחוץ מכיוון שהוא מכיל את כל שורות הקוד. ביליתי מעט זמן בהפרדת הקבצים ובאופטימיזציה של מבנה הספריות. ככה זה נראה אחרי זה:
משאבים -> זה המקום שבו נמצאים כל הנכסים (תמונות)
src
- ישויות
— game_object.rs
— מעגל.רס
— main.rs -> לולאה ראשית

אנשים, קומות ותמונות

השלב הבא הוא יצירת אובייקט משחק Person וטעינת תמונות. הכל צריך להיות בנוי על בסיס 32*32 אריחים.

מגרשי טניס

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

בסך הכל יש לנו שני אריחים כאלה: 1 ו-2.

כל חלק של המגרש מורכב מאריח 1 או אריח 2. ניתן לפרוס אותם כרגיל או להפוך אותם ב-180 מעלות.

מצב בנייה (הרכבה) בסיסי

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

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

שאלות ארכיטקטורה ושחזור

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

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

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

עשיתי עוד קצת מחקר וגיליתי את הארכיטקטורה ECS - Entity Component System, אשר נפוץ בשימוש במשחקים. להלן היתרונות של ECS:

• נתונים מופרדים מהלוגיקה;
• הרכב במקום ירושה;
• ארכיטקטורה ממוקדת נתונים.

ECS מאופיין בשלושה מושגי יסוד:

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

לאחר לימוד זה, התברר כי ECS פותר את הבעיות הבאות:

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

זה מה שקרה לאחר הטמעת ECS.

משאבים -> זה המקום שבו נמצאים כל הנכסים (תמונות)
src
- רכיבים
—עמדה.rs
- person.rs
— tennis_court.rs
— קומה.רס
- wireframe.rs
— mouse_tracked.rs
- משאבים
—mouse.rs
- מערכות
— rendering.rs
- קבועים.רס
- utils.rs
— world_factory.rs -> פונקציות מפעל העולם
— main.rs -> לולאה ראשית

אנחנו משייכים אנשים לבתי המשפט

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

מה עשיתי:

• הוסיפו נתונים לגבי בתי משפט שהוקצו לאדם;
• הוסיף נתונים על אנשים מבוזרים ל- TennisCourt;
• הוסיפה CourtChoosingSystem, המאפשרת לנתח אנשים ומגרשים, לזהות מגרשים זמינים ולהפיץ להם שחקנים;
• הוסיפה PersonMovementSystem, שמחפשת אנשים שהוקצו לבתי המשפט, ואם הם לא שם, אז שולחת אנשים לאן שהם צריכים להיות.

סכום

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

• חלודה נותנת לך את מה שאתה צריך;
• יש לו תיעוד מצוין, חלודה די אלגנטית;
• העקביות מגניבה;
• אתה לא צריך לנקוט בשיבוט, העתקה או פעולות דומות אחרות, מה שעשיתי לעתים קרובות ב-C++;
• האפשרויות קלות מאוד לשימוש ומטפלות בשגיאות בצורה טובה מאוד;
• אם ניתן היה להרכיב את הפרויקט, אז 99% מהזמן הוא עובד, ובדיוק כמו שצריך. אני חושב שהודעות השגיאה של המהדר הן הטובות ביותר שראיתי.

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

Skillbox ממליצה:

• קורס מקוון "מפתח חזיתי מקצועי".
• קורס מעשי "Mobile Developer PRO".
• קורס מעשי בן שנה "מפתח PHP מ-0 ל-PRO".

מקור: www.habr.com