Cave: शुरुआत गाइड

Back to Learn

Keep your place in this quest

Log in or sign up for free to subscribe, follow lesson progress, and access more learning content.

पिछले पाठ में, आपने सीखा कि कैसे Python गेमप्ले के दौरान तत्वों को नियंत्रित कर सकता है। लेकिन Cave में Python केवल चल रहे खेल तक सीमित नहीं है। आप इसका उपयोग एडिटर टूल्स बनाने के लिए भी कर सकते हैं जो आपको अपना खेल जल्दी बनाने में मदद करते हैं।

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

इस पाठ में, आप सीखेंगे:

  • गेमप्ले स्क्रिप्ट और एडिटर स्क्रिप्ट के बीच का अंतर।
  • एक संपादक टूल किसके लिए उपयोग किया जा सकता है।
  • एक संपादक टैब टूल कैसे संरचित होता है।
  • #editoronly क्यों महत्वपूर्ण है।
  • एक कस्टम टूल बनाने का कब मूल्य है।

आपको शुरू करने पर तुरंत टूल बनाने की आवश्यकता नहीं है, लेकिन यह जानना अच्छा है कि यह प्रणाली मौजूद है। यह उन विशेषताओं में से एक है जो आपके प्रोजेक्ट के बढ़ने पर अधिक मूल्यवान हो जाती है।

गेमप्ले स्क्रिप्ट बनाम एडिटर टूल्स

संक्षेप में:

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

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

एडिटर टूल्स उपयोगी क्यों हैं

पहले, कस्टम टूल बड़े टीमों को अधिकतर आवश्यकता हो सकती है ऐसा लग सकता है।

लेकिन अकेले विकासकर्ताओं को भी छोटे टूल्स से लाभ हो सकता है क्योंकि वे दोहराए गए मैनुअल कार्य को कम करते हैं। यदि आप कई बार समान कार्य करते हैं, तो एक सरल एडिटर स्क्रिप्ट प्रोजेक्ट को काम करने में अधिक तेज़ी से बनाती है।

एडिटर टूल्स उन चीज़ों में मदद कर सकते हैं जैसे:

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

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


एडिटर-केवल स्क्रिप्ट

एडिटर स्क्रिप्ट सामान्यतः इस लाइन से शुरू होती हैं:

#editoronly

यह Cave को बताता है कि स्क्रिप्ट का उपयोग संपादक के लिए है।

यह महत्वपूर्ण है क्योंकि संपादक टूल्स ऐसे APIs या व्यवहार का उपयोग कर सकते हैं जो केवल संपादक के अंदर समझ में आते हैं। आप सामान्यतः नहीं चाहते कि स्तर डिजाइन सहायक या डिबग पैनल आपके अंतिम खेल के रनटाइम का हिस्सा बने।

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

इसलिए, यदि आप एक स्क्रिप्ट बना रहे हैं जो केवल Cave Editor के अंदर काम करने में आपकी मदद करने के लिए है, तो इसे एडिटर-केवल बनाएं।

एडिटर टैब टूल्स

एक टूल बनाने का एक सामान्य तरीका एडिटर टैब का उपयोग करना है।

image.png

एक एडिटर टैब एक कस्टम पैनल है जो Cave Editor के अंदर दिखाई देता है। इसमें एक draw() विधि होती है, और Cave उस विधि को तब कॉल करता है जब टैब दृश्य में होता है ताकि टूल बटन, पाठ, संपत्तियां, और अन्य नियंत्रण बना सकें।

एक बहुत छोटा एडिटर टैब इस तरह दिखता है:

#editoronly
import cave

class ExampleTab(cave.ui.DebugTab):
    def __init__(self):
        super().__init__()
        self.counter = 0

    def draw(self):
        cave.ui.text("यह एक नमूना टूल है।")
        cave.ui.separator()

        self.counter = cave.ui.prop("काउंटर", self.counter)

        if cave.ui.buttonDark("काउंटर बढ़ाएँ +1"):
            self.counter += 1
            print("काउंटर +1 द्वारा बढ़ा")

यह तब है जब आप एक एडिटर टैब जोड़ते हैं तो यह डिफ़ॉल्ट कोड होता है। यदि आप इसे गुण टैब में खोलने के लिए क्लिक करते हैं और फिर संपादक टूलिंग टैब पर जाते हैं, तो आप देखेंगे कि उदाहरण टैब क्लास एक डिबग टैब के रूप में प्रकट हो रही है। फिर आपको केवल टैब को पंजीकरण या पुनः लोड करना है और यह आपके लिए UI में उपलब्ध होगा:

image.png

यह उदाहरण सरल है, लेकिन यह पहले से ही मूल विचार को दिखाता है:

  • cave.ui.DebugTab एक कस्टम एडिटर टैब बनाता है।
  • draw() यह वर्णन करता है कि टैब क्या दिखाता है।
  • cave.ui.text() पाठ को खींचता है।
  • cave.ui.prop() एक संपादन योग्य संपत्ति खींचता है।
  • cave.ui.buttonDark() एक बटन बनाता है।
  • print() का उपयोग जानकारी को कंसोल में भेजने के लिए किया जा सकता है।

Cave Editor के लिए कस्टम टूल बनाते समय यह कितना सरल है। आप इसे वास्तविक टूल बनाने के लिए बाद में इसी संरचना का उपयोग कर सकते हैं।

draw() विधि का क्या अर्थ है

draw() विधि गेमप्ले घटक में start() के समान नहीं है।

यह हर बार कॉल किया जाता है जब टूल दृश्य में होता है, क्योंकि संपादक UI को खींचा और अपडेट करने की आवश्यकता होती है। इसका मतलब है कि draw() के अंदर का कोड टूल के वर्तमान इंटरफेस का वर्णन करना चाहिए।

उदाहरण:

def draw(self):
    cave.ui.text("स्तर सहायक:")

    if cave.ui.buttonDark("दुश्मन समूह बनाएं"):
        print("दुश्मन समूह बनाने पर क्लिक किया")

बटन हर बार टैब अपडेट करते समय खींचा जाता है, लेकिन if के अंदर का कोड केवल तब चलता है जब उपयोगकर्ता बटन पर क्लिक करता है।

यह पैटर्न एडिटर टूल्स में बहुत सामान्य है।

एक व्यावहारिक टूल विचार

मान लीजिए आप एक स्तर बना रहे हैं और आपको अक्सर वही बुनियादी फ़ोल्डर्स की आवश्यकता है:

  • Environment
  • Enemies
  • Gameplay Triggers
  • Lighting
  • Audio
  • Debug Helpers

आप एक एडिटर टूल बना सकते हैं जिसमें एक बटन हो जिसका नाम Create Level Folders हो। जब क्लिक किया जाए, तो यह वर्तमान दृश्य में उन फ़ोल्डर तत्वों को बना सकता है। याद रखें: दृश्य ग्राफ़ में एक फ़ोल्डर बस एक तत्व होता है जिसके साथ कोई घटक नहीं जुड़ा होता है।

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


एडिटर घटक

कभी-कभी, आप गेमप्ले लॉजिक को एडिटर लॉजिक के साथ मिलाना चाहते हैं। उदाहरण के लिए, आप एक तत्व से जुड़े एक घटक के पास होना चाह सकते हैं जो एडिटर लॉजिक भी चलाता है, उदाहरण के लिए, डिबग जानकारी प्रदर्शित करने के लिए या एक डिबग स्फीयर को प्रदर्शित करने के लिए जो दुश्मन की मूवमेंट या अटैक रेंज को इंगित करता है। इस मामले में, आप cave.Component का उपयोग करने के बजाय cave.EditorComponent का उपयोग करते हैं।

यह तब उपयोगी है जब किसी तत्व को विशेष संपादक व्यवहार की आवश्यकता होती है, लेकिन वह व्यवहार वास्तव में खेल का हिस्सा नहीं होना चाहिए।

उदाहरण:

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

महत्वपूर्ण विचार यह है कि एडिटर स्क्रिप्ट गेम बनाने के कार्यप्रवाह के लिए होती हैं। गेमप्ले स्क्रिप्ट का उपयोग खेल के लिए होता है।

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

यह संभावित रूप से खतरनाक हो सकता है, उदाहरण के लिए: यदि आप एक एडिटर घटक के शुरूआत विधि में एक लॉजिक डालते हैं जो दृश्य में सभी तत्वों को प्राप्त करता है और उन्हें मिटा देता है, तो आपका खेल पूरी तरह से संपादक में एक विनाशकारी तरीके से मिट जाएगा (जैसा कि इसे पूर्ववत नहीं किया जा सकता है)। यह एक गलती नहीं है, यह एक बग नहीं है, यह डिजाइन द्वारा ऐसे काम करता है। इसलिए सतर्क रहें।

यदि आप ऐसा करने का एक सुरक्षित तरीका चाहते हैं, तो आप Python कोड घटक का उपयोग कर सकते हैं, क्योंकि इसमें एक संपादक अपडेट विधि होती है, और इस संपादक अपडेट को लिखने से यह प्रभावित नहीं होगा कि आमंत्रण और समाप्ति अपडेट संपादक में चलाए जाएंगे या नहीं (वे नहीं होंगे)। Cave द्वारा निर्मित प्रारंभिक परियोजना में दुश्मन जांचें, क्योंकि इसका उपयोग डिबग स्फीयर को दुश्मनों के चारों ओर खींचने के लिए किया जाता है, जो यह बताता है कि वह कैसे घूम सकता है। यह इसके बारे में अधिक जानने का एक अच्छा तरीका है।


आपको कब एक टूल बनाना चाहिए?

हर छोटे कार्य के लिए एक कस्टम टूल न बनाएं।

जब यह एक वास्तविक कार्यप्रवाह की समस्या का समाधान करता है, जैसे:

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

एक शुरुआती के लिए, सबसे पहले हाथ से गेम ऑब्जेक्ट बनाना बेहतर होता है। फिर, जब आप चरणों को समझ लेते हैं, तो आप उबाऊ भाग को स्वचालित कर सकते हैं।

आपको क्या याद रखना चाहिए

Cave में Python को गेमप्ले और संपादक टूलिंग दोनों के लिए उपयोग किया जा सकता है।

गेमप्ले स्क्रिप्ट वह नियंत्रित करती हैं जो खेल चलने के दौरान होता है। एडिटर स्क्रिप्टें आपको Cave Editor के अंदर प्रोजेक्ट बनाने, निरीक्षण करने, डिबग या व्यवस्थित करने में मदद करती हैं।

आपको अपना पहला खेल बनाने के लिए संपादक टूल्स की आवश्यकता नहीं है, लेकिन जब आपका प्रोजेक्ट बढ़ता है तो वे शक्तिशाली होते हैं। एक छोटा टूल जो आज पांच मिनट बचाता है, बाद में घंटे बचा सकता है।