24 घंटे में रस्ट खेलना: व्यक्तिगत विकास का अनुभव

इस लेख में मैं रस्ट में एक छोटा गेम विकसित करने के अपने व्यक्तिगत अनुभव के बारे में बात करूंगा। एक कार्यशील संस्करण बनाने में लगभग 24 घंटे लगे (मैंने ज्यादातर शाम या सप्ताहांत में काम किया)। खेल अभी ख़त्म नहीं हुआ है, लेकिन मुझे लगता है कि अनुभव फायदेमंद होगा। खेल को शुरू से बनाते समय मैंने जो सीखा और कुछ अवलोकन किए, उन्हें मैं साझा करूंगा।

स्किलबॉक्स अनुशंसा करता है: दो वर्षीय व्यावहारिक पाठ्यक्रम "मैं एक PRO वेब डेवलपर हूं".

अनुस्मारक: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रचार कोड का उपयोग करके किसी भी स्किलबॉक्स पाठ्यक्रम में नामांकन करते समय 10 रूबल की छूट।

जंग क्यों?

मैंने यह भाषा इसलिए चुनी क्योंकि मैंने इसके बारे में बहुत सारी अच्छी बातें सुनी हैं और मैं देख रहा हूं कि यह खेल के विकास में अधिक से अधिक लोकप्रिय हो रही है। गेम लिखने से पहले, मुझे रस्ट में सरल एप्लिकेशन विकसित करने का बहुत कम अनुभव था। खेल लिखते समय मुझे स्वतंत्रता का एहसास दिलाने के लिए यह पर्याप्त था।

खेल क्यों और कैसा खेल?

गेम बनाना मज़ेदार है! काश और भी कारण होते, लेकिन "घर" परियोजनाओं के लिए मैं ऐसे विषयों को चुनता हूं जो मेरे नियमित काम से बहुत करीब से संबंधित नहीं हैं। यह कौन सा खेल है? मैं एक टेनिस सिम्युलेटर जैसा कुछ बनाना चाहता था जो सिटीज़ स्काईलाइन्स, ज़ू टाइकून, प्रिज़न आर्किटेक्ट और टेनिस को ही जोड़ता हो। सामान्य तौर पर, यह एक टेनिस अकादमी के बारे में एक खेल निकला जहाँ लोग खेलने आते हैं।

तकनीकी प्रशिक्षण

मैं रस्ट का उपयोग करना चाहता था, लेकिन मुझे नहीं पता था कि इसे शुरू करने के लिए कितना जमीनी काम करना होगा। मैं पिक्सेल शेडर्स लिखना और ड्रैग-एन-ड्रॉप का उपयोग नहीं करना चाहता था, इसलिए मैं सबसे लचीले समाधानों की तलाश में था।

मुझे उपयोगी संसाधन मिले जिन्हें मैं आपके साथ साझा करता हूं:

• क्या हम अभी भी खेल रहे हैं? - खेल के विकास के लिए आवश्यक जंग तत्वों की एक सूची;
• रस्ट गेम देव सबरेडिट;
• मुफ़्त पिक्सेल कला.

मैंने कई रस्ट गेम इंजनों की खोज की, अंततः पिस्टन और जीजीज़ को चुना। पिछले प्रोजेक्ट पर काम करते समय मेरी उनसे मुलाकात हुई थी। अंत में, मैंने ggez को चुना क्योंकि यह एक छोटे 2D गेम को लागू करने के लिए अधिक उपयुक्त लगा। पिस्टन की मॉड्यूलर संरचना नौसिखिया डेवलपर (या कोई व्यक्ति जो पहली बार रस्ट के साथ काम कर रहा है) के लिए बहुत जटिल है।

खेल संरचना

मैंने परियोजना की वास्तुकला के बारे में सोचने में कुछ समय बिताया। पहला कदम "भूमि", लोगों और टेनिस कोर्ट बनाना है। लोगों को कोर्ट-कचहरी के चक्कर लगाने पड़ते हैं और इंतजार करना पड़ता है. खिलाड़ियों के पास ऐसे कौशल होने चाहिए जो समय के साथ बेहतर हों। साथ ही, एक संपादक होना चाहिए जो आपको नए लोगों और अदालतों को जोड़ने की अनुमति दे, लेकिन यह अब मुफ़्त नहीं है।

सब कुछ सोचने के बाद, मैं काम पर लग गया।

खेल निर्माण

शुरुआत: वृत्त और अमूर्त

मैंने 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 आवश्यक है क्योंकि इसमें कोड की सभी पंक्तियाँ शामिल हैं। मैंने फ़ाइलों को अलग करने और निर्देशिका संरचना को अनुकूलित करने में थोड़ा समय बिताया। उसके बाद यह ऐसा दिखता था:
संसाधन -> यह वह जगह है जहां सभी संपत्तियां हैं (छवियां)
"
- संस्थाएँ
- गेम_ऑब्जेक्ट.आरएस
- सर्कल.आरएस
— main.rs -> मुख्य लूप

लोग, फर्श और छवियाँ

अगला चरण एक व्यक्ति गेम ऑब्जेक्ट बनाना और छवियों को लोड करना है। सब कुछ 32*32 टाइल्स के आधार पर बनाया जाना चाहिए।

टेनिस कोर्ट

टेनिस कोर्ट कैसा दिखता है इसका अध्ययन करने के बाद, मैंने उन्हें 4*2 टाइल्स से बनाने का निर्णय लिया। प्रारंभ में, इस आकार की एक छवि बनाना, या 8 अलग-अलग टाइलें एक साथ रखना संभव था। लेकिन फिर मुझे एहसास हुआ कि केवल दो अद्वितीय टाइलों की आवश्यकता थी, और यहां बताया गया है कि क्यों।

कुल मिलाकर हमारे पास ऐसी दो टाइलें हैं: 1 और 2.

कोर्ट के प्रत्येक अनुभाग में टाइल 1 या टाइल 2 शामिल हैं। उन्हें सामान्य रूप से बिछाया जा सकता है या 180 डिग्री पर फ़्लिप किया जा सकता है।

बुनियादी निर्माण (असेंबली) मोड

जब मैं साइटों, लोगों और मानचित्रों का प्रतिपादन हासिल करने में कामयाब हो गया, तो मुझे एहसास हुआ कि एक बुनियादी असेंबली मोड की भी आवश्यकता थी। मैंने इसे इस तरह कार्यान्वित किया: जब बटन दबाया जाता है, तो ऑब्जेक्ट का चयन किया जाता है, और क्लिक उसे वांछित स्थान पर रखता है। तो, बटन 1 आपको एक कोर्ट चुनने की अनुमति देता है, और बटन 2 आपको एक खिलाड़ी चुनने की अनुमति देता है।

लेकिन हमें अभी भी यह याद रखना होगा कि 1 और 2 का क्या मतलब है, इसलिए मैंने यह स्पष्ट करने के लिए एक वायरफ्रेम जोड़ा कि कौन सा ऑब्जेक्ट चुना गया था। यह है जो ऐसा लग रहा है।

वास्तुकला और रिफैक्टरिंग प्रश्न

अब मेरे पास कई गेम ऑब्जेक्ट हैं: लोग, कोर्ट और फर्श। लेकिन वायरफ्रेम के काम करने के लिए, प्रत्येक ऑब्जेक्ट इकाई को यह बताया जाना चाहिए कि क्या ऑब्जेक्ट स्वयं प्रदर्शन मोड में हैं, या क्या एक फ्रेम बस खींचा गया है। यह बहुत सुविधाजनक नहीं है.

मुझे ऐसा लगा कि वास्तुकला पर इस तरह से पुनर्विचार करने की ज़रूरत है जिससे कुछ सीमाएँ सामने आएँ:

• एक ऐसी इकाई का होना जो स्वयं को प्रस्तुत और अद्यतन करती है, एक समस्या है क्योंकि वह इकाई "जानने" में सक्षम नहीं होगी कि उसे क्या प्रस्तुत करना चाहिए - एक छवि और एक वायरफ्रेम;
• व्यक्तिगत संस्थाओं के बीच गुणों और व्यवहार के आदान-प्रदान के लिए एक उपकरण की कमी (उदाहरण के लिए, is_build_mode संपत्ति या व्यवहार प्रतिपादन)। इनहेरिटेंस का उपयोग करना संभव होगा, हालाँकि रस्ट में इसे लागू करने का कोई उचित तरीका नहीं है। मुझे वास्तव में लेआउट की आवश्यकता थी;
• लोगों को अदालतों में नियुक्त करने के लिए संस्थाओं के बीच बातचीत के लिए एक उपकरण की आवश्यकता थी;
• संस्थाएँ स्वयं डेटा और तर्क का मिश्रण थीं जो जल्दी ही नियंत्रण से बाहर हो गईं।

मैंने कुछ और शोध किया और वास्तुकला की खोज की ईसीएस - इकाई घटक प्रणाली, जो आमतौर पर खेलों में उपयोग किया जाता है। ईसीएस के लाभ यहां दिए गए हैं:

• डेटा को तर्क से अलग किया जाता है;
• विरासत के बजाय रचना;
• डेटा-केंद्रित वास्तुकला।

ईसीएस की विशेषता तीन बुनियादी अवधारणाएँ हैं:

• संस्थाएँ - वस्तु का वह प्रकार जिसे पहचानकर्ता संदर्भित करता है (यह एक खिलाड़ी, एक गेंद या कुछ और हो सकता है);
• घटक - इकाइयाँ उनसे बनी होती हैं। उदाहरण - घटक, स्थान और अन्य का प्रतिपादन। ये डेटा वेयरहाउस हैं;
• सिस्टम - वे वस्तुओं और घटकों दोनों का उपयोग करते हैं, साथ ही उनमें व्यवहार और तर्क भी होते हैं जो इस डेटा पर आधारित होते हैं। एक उदाहरण एक रेंडरिंग प्रणाली है जो रेंडरिंग घटकों के साथ सभी संस्थाओं के माध्यम से पुनरावृत्त होती है और रेंडरिंग करती है।

इसका अध्ययन करने पर यह स्पष्ट हो गया कि ईसीएस निम्नलिखित समस्याओं का समाधान करता है:

• संस्थाओं को व्यवस्थित रूप से व्यवस्थित करने के लिए इनहेरिटेंस के बजाय लेआउट का उपयोग करना;
• नियंत्रण प्रणालियों के माध्यम से कोड गड़बड़ी से छुटकारा पाना;
• रेंडरिंग सिस्टम में वायरफ्रेम लॉजिक को उसी स्थान पर रखने के लिए is_build_mode जैसी विधियों का उपयोग करना।

ईसीएस लागू करने के बाद यही हुआ।

संसाधन -> यह वह जगह है जहां सभी संपत्तियां हैं (छवियां)
"
- अवयव
—स्थिति.आरएस
-व्यक्ति.आरएस
— टेनिस_कोर्ट.आरएस
- मंजिल.आरएस
- वायरफ्रेम.आरएस
- माउस_ट्रैक्ड.आरएस
- संसाधन
—mouse.rs
- सिस्टम
- प्रतिपादन.rs
— स्थिरांक.rs
— utils.rs
—world_factory.rs ->विश्व फ़ैक्टरी फ़ंक्शंस
— main.rs -> मुख्य लूप

हम लोगों को अदालतों में नियुक्त करते हैं

ईसीएस ने जीवन को आसान बना दिया है। अब मेरे पास संस्थाओं में डेटा जोड़ने और उस डेटा के आधार पर तर्क जोड़ने का एक व्यवस्थित तरीका था। और इसने, बदले में, अदालतों के बीच लोगों के वितरण को व्यवस्थित करना संभव बना दिया।

मैने क्या कि:

• व्यक्ति को सौंपी गई अदालतों के बारे में डेटा जोड़ा गया;
• टेनिसकोर्ट में वितरित लोगों के बारे में डेटा जोड़ा गया;
• कोर्टचॉज़िंग सिस्टम जोड़ा गया, जो आपको लोगों और अदालतों का विश्लेषण करने, उपलब्ध अदालतों का पता लगाने और उन्हें खिलाड़ियों को वितरित करने की अनुमति देता है;
• एक पर्सनमूवमेंट सिस्टम जोड़ा गया, जो अदालतों में नियुक्त लोगों की तलाश करता है, और यदि वे वहां नहीं हैं, तो लोगों को वहां भेजता है जहां उन्हें होना चाहिए।

उपसंहार

मुझे इस सरल खेल पर काम करने में सचमुच आनंद आया। इसके अलावा, मुझे ख़ुशी है कि मैंने इसे लिखने के लिए रस्ट का उपयोग किया, क्योंकि:

• जंग आपको वह देती है जिसकी आपको आवश्यकता है;
• इसमें उत्कृष्ट दस्तावेज़ीकरण है, रस्ट काफी सुंदर है;
• स्थिरता अच्छी है;
• आपको क्लोनिंग, कॉपी करने या अन्य समान कार्यों का सहारा लेने की ज़रूरत नहीं है, जो मैंने अक्सर C++ में किया था;
• विकल्पों का उपयोग करना बहुत आसान है और त्रुटियों को बहुत अच्छी तरह से संभालना है;
• यदि प्रोजेक्ट संकलित करने में सक्षम था, तो 99% समय यह काम करता है, और बिल्कुल वैसा ही जैसा इसे होना चाहिए। मुझे लगता है कि कंपाइलर त्रुटि संदेश सबसे अच्छे हैं जो मैंने देखे हैं।

रस्ट में गेम का विकास अभी शुरू हो रहा है। लेकिन पहले से ही एक स्थिर और काफी बड़ा समुदाय है जो रस्ट को सभी के लिए खोलने के लिए काम कर रहा है। इसलिए, मैं भाषा के भविष्य को आशावाद के साथ देखता हूं, हमारे सामान्य कार्य के परिणामों की प्रतीक्षा करता हूं।

स्किलबॉक्स अनुशंसा करता है:

• ऑनलाइन पाठ्यक्रम "प्रोफेशन फ्रंटएंड डेवलपर".
• व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो".
• व्यावहारिक वर्ष पाठ्यक्रम "PHP डेवलपर 0 से PRO तक".

स्रोत: www.habr.com