24 तासांत गंज खेळणे: वैयक्तिक विकास अनुभव

या लेखात मी रस्टमध्ये एक लहान गेम विकसित करण्याच्या माझ्या वैयक्तिक अनुभवाबद्दल बोलेन. कार्यरत आवृत्ती तयार करण्यासाठी सुमारे 24 तास लागले (मी मुख्यतः संध्याकाळी किंवा आठवड्याच्या शेवटी काम केले). खेळ पूर्ण होण्यापासून दूर आहे, परंतु मला वाटते की अनुभव फायद्याचा असेल. सुरुवातीपासून गेम तयार करताना मी काय शिकलो आणि काही निरीक्षणे मी सामायिक करेन.

स्किलबॉक्स शिफारस करतो: दोन वर्षांचा प्रॅक्टिकल कोर्स "मी प्रो वेब डेव्हलपर आहे".

आम्ही आठवण करून देतो: सर्व Habr वाचकांसाठी - Habr प्रोमो कोड वापरून कोणत्याही स्किलबॉक्स कोर्समध्ये नावनोंदणी करताना 10 रूबल सवलत.

गंज का?

मी ही भाषा निवडली आहे कारण मी त्याबद्दल बर्‍याच चांगल्या गोष्टी ऐकल्या आहेत आणि गेम डेव्हलपमेंटमध्ये ती अधिकाधिक लोकप्रिय होत असल्याचे मला दिसत आहे. गेम लिहिण्यापूर्वी, मला रस्टमध्ये साधे अनुप्रयोग विकसित करण्याचा फारसा अनुभव नव्हता. खेळ लिहिताना मला स्वातंत्र्याची जाणीव देण्यासाठी हे पुरेसे होते.

खेळ का आणि कसला खेळ?

खेळ बनवणे मजेदार आहे! माझी इच्छा आहे की आणखी काही कारणे असती, परंतु "होम" प्रकल्पांसाठी मी असे विषय निवडतो जे माझ्या नियमित कामाशी खूप जवळून संबंधित नाहीत. हा कोणता खेळ आहे? मला टेनिस सिम्युलेटरसारखे काहीतरी बनवायचे होते जे सिटी स्कायलाइन्स, झू टायकून, जेल आर्किटेक्ट आणि टेनिस स्वतः एकत्र करते. सर्वसाधारणपणे, हा टेनिस अकादमीचा खेळ असल्याचे दिसून आले जेथे लोक खेळायला येतात.

तांत्रिक प्रशिक्षण

मला रस्ट वापरायचा होता, पण ते सुरू करण्यासाठी किती ग्राउंडवर्क लागेल हे मला माहीत नव्हते. मला पिक्सेल शेडर्स लिहायचे नव्हते आणि ड्रॅग-एन-ड्रॉप वापरायचे नव्हते, म्हणून मी सर्वात लवचिक उपाय शोधत होतो.

मी तुमच्यासोबत शेअर केलेली उपयुक्त संसाधने मला सापडली:

• आम्ही अजून खेळत आहोत - गेमच्या विकासासाठी आवश्यक असलेल्या गंज घटकांची यादी;
• गंज खेळ dev subreddit;
• मोफत पिक्सेल कला.

मी अनेक रस्ट गेम इंजिन एक्सप्लोर केले, शेवटी पिस्टन आणि ggez निवडले. मागील प्रोजेक्टवर काम करताना मी त्यांना भेटलो. सरतेशेवटी, मी 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 आवश्यक आहे कारण त्यात कोडच्या सर्व ओळी आहेत. मी फाइल्स वेगळे करण्यात आणि डिरेक्टरी स्ट्रक्चर ऑप्टिमाइझ करण्यात थोडा वेळ घालवला. त्यानंतर हे असे दिसले:
संसाधने -> येथे सर्व मालमत्ता आहेत (प्रतिमा)
Src
- संस्था
— game_object.rs
— circle.rs
— main.rs -> मुख्य लूप

लोक, मजला आणि प्रतिमा

पुढील पायरी म्हणजे व्यक्ती गेम ऑब्जेक्ट तयार करणे आणि प्रतिमा लोड करणे. सर्व काही 32*32 टाइल्सच्या आधारे बांधले पाहिजे.

टेनिसची मैदाने

टेनिस कोर्ट कसे दिसतात याचा अभ्यास केल्यानंतर, मी त्यांना 4*2 टाइल्सपासून बनवण्याचा निर्णय घेतला. सुरुवातीला, या आकाराची प्रतिमा तयार करणे किंवा 8 स्वतंत्र टाइल एकत्र ठेवणे शक्य होते. पण नंतर मला समजले की फक्त दोन अनन्य टाइल्सची गरज आहे आणि ते का ते येथे आहे.

एकूण आमच्याकडे अशा दोन टाइल्स आहेत: 1 आणि 2.

न्यायालयाच्या प्रत्येक विभागात टाइल 1 किंवा टाइल 2 असते. ते सामान्य किंवा 180 अंशांवर फ्लिप केले जाऊ शकतात.

मूलभूत बांधकाम (विधानसभा) मोड

मी साइट्स, लोक आणि नकाशे यांचे रेंडरिंग साध्य करण्यात व्यवस्थापित केल्यानंतर, मला समजले की मूलभूत असेंबली मोड देखील आवश्यक आहे. मी हे असे लागू केले: जेव्हा बटण दाबले जाते, तेव्हा ऑब्जेक्ट निवडला जातो आणि क्लिक इच्छित ठिकाणी ठेवतो. तर, बटण 1 तुम्हाला कोर्ट निवडण्याची परवानगी देते आणि बटण 2 तुम्हाला खेळाडू निवडण्याची परवानगी देते.

पण तरीही 1 आणि 2 चा अर्थ काय आहे हे लक्षात ठेवण्याची गरज आहे, म्हणून मी कोणता ऑब्जेक्ट निवडला आहे हे स्पष्ट करण्यासाठी वायरफ्रेम जोडली आहे. हे असे दिसते.

आर्किटेक्चर आणि रिफॅक्टरिंग प्रश्न

आता माझ्याकडे अनेक गेम ऑब्जेक्ट्स आहेत: लोक, कोर्ट आणि मजले. परंतु वायरफ्रेम्स कार्य करण्यासाठी, प्रत्येक ऑब्जेक्ट एंटिटीला हे सांगणे आवश्यक आहे की ऑब्जेक्ट्स स्वतः प्रात्यक्षिक मोडमध्ये आहेत किंवा फ्रेम फक्त काढली आहे की नाही. हे फार सोयीचे नाही.

मला असे वाटले की आर्किटेक्चरचा अशा प्रकारे पुनर्विचार करणे आवश्यक आहे ज्याने काही मर्यादा प्रकट केल्या:

• स्वतःच रेंडर आणि अपडेट करणारी एखादी संस्था असणे ही एक समस्या आहे कारण ती संस्था काय रेंडर करायची आहे ते "माहित" करू शकणार नाही - एक प्रतिमा आणि वायरफ्रेम;
• वैयक्तिक घटकांमधील गुणधर्म आणि वर्तनाची देवाणघेवाण करण्यासाठी साधनाचा अभाव (उदाहरणार्थ, is_build_mode गुणधर्म किंवा वर्तन प्रस्तुतीकरण). वारसा वापरणे शक्य होईल, जरी ते रस्टमध्ये लागू करण्याचा कोणताही योग्य मार्ग नाही. मला खरोखर लेआउटची गरज होती;
• लोकांना न्यायालयात नियुक्त करण्यासाठी संस्थांमधील परस्परसंवादाचे साधन आवश्यक होते;
• संस्था स्वतःच डेटा आणि तर्क यांचे मिश्रण होते जे त्वरीत नियंत्रणाबाहेर गेले.

मी आणखी काही संशोधन केले आणि आर्किटेक्चर शोधले ECS - घटक घटक प्रणाली, जे सामान्यतः गेममध्ये वापरले जाते. येथे ECS चे फायदे आहेत:

• डेटा तर्कशास्त्र पासून विभक्त आहे;
• वारसाऐवजी रचना;
• डेटा-केंद्रित आर्किटेक्चर.

ईसीएस तीन मूलभूत संकल्पनांद्वारे वैशिष्ट्यीकृत आहे:

• संस्था - अभिज्ञापकाने संदर्भित केलेल्या ऑब्जेक्टचा प्रकार (तो एक खेळाडू, चेंडू किंवा काहीतरी असू शकतो);
• घटक - घटक त्यांच्यापासून बनलेले आहेत. उदाहरण - रेंडरिंग घटक, स्थाने आणि इतर. हे डेटा वेअरहाऊस आहेत;
• सिस्टम्स - ते ऑब्जेक्ट आणि घटक दोन्ही वापरतात, तसेच या डेटावर आधारित वर्तन आणि तर्कशास्त्र समाविष्ट करतात. एक उदाहरण म्हणजे प्रस्तुतीकरण प्रणाली जी प्रस्तुतीकरण घटकांसह सर्व घटकांद्वारे पुनरावृत्ती करते आणि प्रस्तुत करते.

त्याचा अभ्यास केल्यानंतर, हे स्पष्ट झाले की ECS खालील समस्या सोडवते:

• संस्था व्यवस्थितपणे आयोजित करण्यासाठी वारसाऐवजी लेआउट वापरणे;
• नियंत्रण प्रणालीद्वारे कोड गोंधळापासून मुक्त होणे;
• वायरफ्रेम लॉजिक त्याच ठिकाणी ठेवण्यासाठी is_build_mode सारख्या पद्धती वापरणे - प्रस्तुत प्रणालीमध्ये.

ईसीएस लागू केल्यानंतर हेच झाले.

संसाधने -> येथे सर्व मालमत्ता आहेत (प्रतिमा)
Src
- घटक
—position.rs
— person.rs
— tennis_court.rs
— floor.rs
- wireframe.rs
— mouse_tracked.rs
- संसाधने
—mouse.rs
- प्रणाली
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> जागतिक कारखाना कार्ये
— main.rs -> मुख्य लूप

आम्ही लोकांना न्यायालयात नियुक्त करतो

ECS मुळे जीवन सोपे झाले आहे. आता माझ्याकडे संस्थांमध्ये डेटा जोडण्याचा आणि त्या डेटावर आधारित तर्क जोडण्याचा एक पद्धतशीर मार्ग होता. आणि यामुळे, न्यायालयांमध्ये लोकांचे वितरण आयोजित करणे शक्य झाले.

मी काय केले आहे:

• व्यक्तीला नियुक्त केलेल्या न्यायालयांबद्दल डेटा जोडला;
• टेनिसकोर्टमध्ये वितरित लोकांबद्दल डेटा जोडला;
• कोर्टचूजिंग सिस्टीम जोडली, जी तुम्हाला लोक आणि न्यायालयांचे विश्लेषण करण्यास, उपलब्ध न्यायालये शोधण्याची आणि त्यांना खेळाडूंचे वितरण करण्यास अनुमती देते;
• एक PersonMovementSystem जोडली, जी न्यायालयांना नियुक्त केलेल्या लोकांचा शोध घेते, आणि जर ते तेथे नसतील, तर त्यांना आवश्यक असलेल्या ठिकाणी पाठवते.

गोळा करीत आहे

या सोप्या गेमवर काम करताना मला खूप आनंद झाला. शिवाय, मला आनंद आहे की मी ते लिहिण्यासाठी रस्ट वापरले, कारण:

• गंज आपल्याला आवश्यक ते देतो;
• त्यात उत्कृष्ट दस्तऐवजीकरण आहे, गंज खूपच मोहक आहे;
• सुसंगतता थंड आहे;
• तुम्हाला क्लोनिंग, कॉपी किंवा इतर तत्सम क्रियांचा अवलंब करावा लागणार नाही, ज्या मी अनेकदा C++ मध्ये केल्या आहेत;
• पर्याय वापरण्यास अतिशय सोपे आहेत आणि त्रुटी चांगल्या प्रकारे हाताळतात;
• जर प्रकल्प संकलित करण्यात सक्षम असेल, तर 99% वेळेत ते कार्य करते आणि जसे पाहिजे तसे. मला वाटते की कंपाइलर त्रुटी संदेश मी पाहिलेले सर्वोत्तम आहेत.

रस्टमध्ये गेम डेव्हलपमेंट नुकतीच सुरू आहे. परंतु प्रत्येकासाठी रस्ट उघडण्यासाठी आधीच एक स्थिर आणि बऱ्यापैकी मोठा समुदाय कार्यरत आहे. म्हणूनच, मी भाषेच्या भविष्याकडे आशावादाने पाहतो, आमच्या सामान्य कार्याच्या परिणामांची अपेक्षा करतो.

स्किलबॉक्स शिफारस करतो:

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

स्त्रोत: www.habr.com