क्या मुख्य कोड से अलग से खेल यांत्रिकी / नियमों को लागू करना उचित है?


25

यह सुनिश्चित नहीं है कि क्या यह इस समुदाय के दायरे में फिट बैठता है, या इसके बजाय स्टैकओवरफ़्लो में जाना चाहिए।

मान लीजिए कि मैं चाहता हूं कि मेरा खेल अपने मूल में आसानी से बढ़ सके, यानी मैं चाहता हूं कि बहुत सारे लोग, यहां तक ​​कि सभ्य प्रोग्रामिंग ज्ञान के बिना भी, मौजूदा नियमों को न केवल ट्विस्ट कर पाएंगे, बल्कि इसमें पूरी तरह से नया गेम मैकेनिक भी जोड़ सकते हैं। मैं खुद अच्छा प्रोग्रामर नहीं हूं, लेकिन मैं सीखने के लिए तैयार हूं, मुझे बस कुछ दिशाओं और आश्वासन की जरूरत है।

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

यह वास्तव में ऐसा लगता है कि मुझे अपनी भाषा और इसके लिए एक कंपाइलर लिखना होगा)) जो मैं निश्चित रूप से नहीं कर पाऊंगा। लेकिन क्या समस्या का एक आसान तरीका हो सकता है?

FYI करें: उपयोगिता कोड के लिए मेरी पसंद की भाषा पायथन 3.x होगी


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

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

जवाबों:


34

सामान्यतया, किसी भी प्रणाली को जिस सहजता से बढ़ाया जा सकता है, वह इस बात पर निर्भर करता है कि उसका उपतंत्र कसकर या शिथिल रूप से किस हद तक है । आमतौर पर, सबसिस्टम जितने शिथिल होते हैं, उन्हें अलग करना उतना ही आसान होता है, क्योंकि उन्हें अलग-थलग कर दिया जाता है और जरूरी नहीं कि सिस्टम की पूरी समझ हो।

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

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


ठोस सलाह। मैं अपने कोड को यथासंभव आसानी से कम करने के लिए शिथिल रूप से युग्मित रखने की कोशिश करता हूं, लेकिन आपके पास हमेशा ऐसे मामले होंगे जहां कुछ को हार्डकोड / युगल करना इतना आसान है। यहां तक ​​कि एक पेशेवर डेवलपर के रूप में एक आसान काम नहीं है, और निश्चित रूप से नौसिखिए के अनुकूल नहीं है।
अनगर 12

टीटीएस अब लुआ का समर्थन करता है और लागू करने वाले नियम अब पूरी तरह से मानव बातचीत तक नहीं हैं।
Ave

17

मैंने क्या सोचा है कि क्या यह संभव है / संभव है कि किसी भी तरह से मुख्य उपयोगिता कोड से गेम मैकेनिक्स को लागू किया जाए?

यह बिलकुल संभव है। गेमिंग में अक्सर इस्तेमाल किया जाने वाला एक तरीका है लुआ स्क्रिप्टिंग

जुड़े लेख से:

लुआ को मूल रूप से 1993 में डिज़ाइन किया गया था, जो उस समय अनुकूलन की बढ़ती मांग को पूरा करने के लिए सॉफ्टवेयर अनुप्रयोगों के विस्तार के लिए एक भाषा के रूप में थी।

कई खेल लुआ का उपयोग करते हैं। (मैं लिंक करूँगा लेकिन नई-उपयोगकर्ता प्रतिष्ठा मेरी लिंक गणना को सीमित कर रही है।)

रन-टाइम पर लुआ लिपियों को संकलित किया जा सकता है। इसका मतलब है कि वे (उदाहरण के लिए) आपके गेम की "स्क्रिप्ट्स" डायरेक्टरी में बैठी हुई टेक्स्ट फाइल्स हो सकती हैं, जो आसानी से किसी मोडर द्वारा एडिट की जा सकती हैं। आपका खेल उन्हें लोड करता है और उन्हें चलाता है।

मैंने देखा है कि Lua स्क्रिप्ट इन-गेम इकाइयों के गुणों को परिभाषित करती है। यहाँ टीए स्प्रिंग से एक यादृच्छिक उदाहरण है।

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

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

कृपया ध्यान दें: मैं लूआ को ऊपर लाता हूं क्योंकि मुझे पता है कि यह आमतौर पर गेमिंग और सॉफ्टवेयर में अनुकूलन के लिए उपयोग किया जाता है। मैं सुझाव नहीं दे रहा हूं कि यह एकमात्र समाधान है, और न ही प्रश्नकर्ता की जरूरतों के लिए सबसे अच्छा है।


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

3

दृष्टिकोणों का एक सिलसिला है और क्या उनमें से कोई भी विशेष योग्य है या नहीं यह इस बात पर निर्भर करेगा कि आप क्या करने की कोशिश कर रहे हैं। विशेष रूप से, आप tweaker की पेशकश करने के लिए कितना नियंत्रण चाहते हैं?

नियंत्रण के चरम छोर पर, आप बस tweaker को पूरे गेम के कोड को संशोधित करने दे सकते हैं। उस बिंदु पर आप अनिवार्य रूप से उपयोगिता कोड प्रकाशित कर रहे हैं और कम से कम एक उदाहरण है कि इसका उपयोग कैसे करें। एक tweaker जितना चाहें उतना कम या कम कोड का उपयोग कर सकता है।

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

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

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


इसे ओपन सोर्स बनाना वास्तव में मेरा लक्ष्य है। मैं एक समस्या के रूप में देखता हूं कि इस एक्स्टेंसिबिलिटी को सबसे आसान तरीके से कैसे लागू किया जाए, ताकि खेल के अन्य खिलाड़ी (जो कि एमपी गेम, बीडब्ल्यूटी है) नियमों के मूल सेट के अपने स्वयं के एक्सटेंशन बना सकें, और उन्हें प्रत्येक के साथ साझा कर सकें अन्य, किसी भी तरह एक ही समय में संघर्ष से बचना। इसलिए यदि एक उपयोगकर्ता कुछ नियमों को ओवरराइड करके कुछ एक्सटेंशन विकसित करता है, और दूसरा अलग-अलग एक्सटेंशन विकसित करता है, तो यह कैसे सुनिश्चित करें कि 3 जी उपयोगकर्ता जो अपने गेम में उन दोनों का उपयोग करना चाहता है, संगतता मुद्दों में नहीं चलेगा? उन्हें कसकर सहयोग करने के लिए मजबूर करने के अलावा।
tis

..और इसे इस तरह से लागू करना है जिसके लिए किसी भी उपयोगिता कोड के संशोधन की आवश्यकता नहीं होगी और इस प्रकार प्रोग्रामिंग के बारे में बहुत अधिक ज्ञान होना चाहिए।
tis

1
मुझे नहीं लगता कि संगतता समस्याओं को रोकने का कोई तरीका होगा, (यहां तक ​​कि किसी चीज़ का रंग सेट करना भी इसका कारण हो सकता है!) मुझे लगता है कि बेहतर करने के लिए संभव संगतता समस्याओं का पता लगाने और उपयोगकर्ताओं के लिए एक अच्छा तरीका है। जवाब देने के लिए। उपयोगिता कोड इंटरफ़ेस के डिजाइन, और विस्‍तार में विस्‍तार के आधार पर, कॉलबैक आदि ऑर्डर करने का एक तरीका हो सकता है जो वांछित परिणाम पैदा करता है। तो फिर, वहाँ नहीं हो सकता है। उपयोगकर्ता को सूचित करना कि समस्याएँ हो सकती हैं और ऐसा क्यों लगता है कि बिना स्पष्टीकरण के चीजों को तोड़ने से बेहतर उपयोगकर्ता अनुभव है।
रयान 1729

2

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

क्या यह इसके लायक है यह प्रणाली की जटिलता पर निर्भर करता है। जैसे मैं पीएसी मैन के लिए परेशान नहीं होता, लेकिन मैं बौना किले को किसी अन्य तरीके से लिखने की कल्पना नहीं कर सकता था।


धन्यवाद, @Robyn किसी को पढ़ने की सलाह, जो यह भी नहीं जानता कि इस डिजाइन को ठीक से कैसे किया जाए? क्या ऐसे अनुप्रयोगों के लिए कुछ अच्छी तरह से स्थापित डिज़ाइन पैटर्न हैं? कोई भी किताब जो विषय को कवर करती है?
tis

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

2

यह निश्चित रूप से संभव है। यदि यह लायक है तो यह आपके लक्ष्यों पर निर्भर करता है।

इस काम को करने के लिए आपको अपनी खुद की भाषा का आविष्कार करने या कोई कंपाइलर लिखने की जरूरत नहीं है।

यदि आप चाहते हैं कि आपका खेल आसानी से विस्तार योग्य हो, तो इसके लिए जाना एक अच्छा विचार है।

यह शायद आपके लिए अधिक काम है, कम से कम अल्पकालिक, समझने योग्य सिस्टम बनाने और चीजों को संशोधित करने में आसान बनाने के लिए।

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

वास्तविक कोडिंग द्वारा खेल को आगे / गहराई तक विस्तारित करने की संभावना भी है, मुझे इसके बारे में कम पता है लेकिन आप मॉड्स फोरम को देखकर सीख सकते हैं।

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

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


हालांकि मैं देख सकता हूं कि गेम डेटा को xml के साथ कैसे परिभाषित किया जा सकता है, मैं कल्पना नहीं कर सकता कि आप गेम मैकेनिक्स / नियमों को परिभाषित करने के लिए इसका उपयोग कैसे कर सकते हैं। क्या आप इस विषय पर कुछ उदाहरण / लेख प्रदान कर सकते हैं, शायद?
tis

@tis नियम केवल दूसरे प्रकार के डेटा हैं। अगर मेरे इंजन में "इफ़ ए डू बी" है तो मैं ए और बी को एक्सएमएल फ़ाइल से लोड कर सकता हूं, अब उपयोगकर्ता काफी मनमाने नियम लगा सकते हैं, एक अतिरिक्त बिट जो मदद कर सकता है वह है सूची के अनुसार हर संभव एस और बी एस के साथ आपको प्रति समर्थन देना। , उदाहरण के लिए "यदि स्टेटस स्टैस्टाइप फिर Movespeed 100", "यदि स्टेट स्टेटस्टाइप और टाइम> एक्स तो स्टेट स्टेटस्टाइप" तो अपने डिजाइन में सोचें कि आप किस प्रकार के ऑब्जेक्ट (स्थिति, समय, मूवीडेड) पर किस तरह के नियमों की अनुमति देना चाहते हैं और किस प्रकार की संरचना के साथ अनुमति देने के लिए (और / या, आदि ...)। यदि स्थिति पानी के भीतर और समय> 5 स्वास्थ्य -10।
ttbek

1

आप ऑब्जेक्ट-ओरिएंटेड डिज़ाइन में देखना चाह सकते हैं । अजगर को उसके लिए अच्छा समर्थन है।

इस बारे में मोटी किताबें लिखी जाती हैं जो नए होने पर डरावनी हो सकती हैं, लेकिन मुख्य सिद्धांत काफी आसान हैं।

मुख्य बिंदु यह है कि आप पहचानें कि आप किस तरह की वस्तुओं के साथ काम कर रहे हैं। आप यह नहीं कहते कि आप किस तरह के खेल के बारे में सोच रहे हैं, लेकिन प्लेयर, मॉन्स्टर, आइटम, इक्विपमेंट, वेपन, आर्मर वगैरह जैसी चीजें आम चीजें हैं।

यदि आप विभिन्न प्रकार के खेल चाहते हैं, तो आप शायद एक गेम ऑब्जेक्ट चाहते हैं जो जीत की स्थिति और इस तरह की देखभाल करता है। शायद एक मैप ऑब्जेक्ट भी?

कभी-कभी यह स्पष्ट नहीं होता है कि कुछ वस्तु के योग्य है या नहीं, जैसे कि क्षति। यदि आप किसी वस्तु को नुकसान नहीं पहुंचाते हैं तो कोड सरल हो जाएगा, लेकिन इसे ऑब्जेक्ट बनाने से कस्टमाइज़ करना आसान हो जाता है।

उपवर्ग: हथियार और हथियार दोनों उपकरण हैं। उपकरण आइटम हैं। संभवतः अन्य प्रकार के आइटम हैं। आपको शायद एक क्लास कॉम्बैटेंट को परिभाषित करने के लिए उपयोगी होगा जो प्लेयर्स और मॉन्स्टर्स दोनों के उपवर्ग हैं।

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

इसलिए, उपवर्ग आपको यह कहने का एक तरीका देता है कि "हथियार अन्य वस्तुओं की तरह हैं, लेकिन इसके अलावा आप उन्हें मिटा सकते हैं, वे आपके द्वारा किए गए नुकसान, आदि को प्रभावित करते हैं।"

सबक्लासिंग आपके मॉड बिल्डरों को यह कहने देता है कि "मेरे नए प्रकार के हथियार मानक हथियारों की तरह ही हैं, सिवाय इसके ..."

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

जब तक आप सिर्फ अपने दम पर छेड़छाड़ कर रहे हैं तब तक आप चीजों को बदल सकते हैं लेकिन जिस पल आप जनता के लिए कुछ जारी करते हैं, बदलाव करना बहुत कठिन हो जाता है! लोग ऐसे मोड बनाएंगे जो उन चीजों पर निर्भर करते हैं जैसे वे अब हैं। यहां तक ​​कि बग भी। लोग ऐसे मॉड लिखेंगे जो कोड में रहने वाले बग पर निर्भर करते हैं। यदि आप चीजों को बदलते हैं, तो वे मोड टूट जाएंगे और लिंच मॉब आपके घर पर दिखाई देंगे।

उदाहरण के लिए:

एक हथियार चलाने वाले एक खिलाड़ी ने कई आर्मरेस पहने हुए एक राक्षस पर हमला किया। यह एक विशेष गेम मोड में और एक निश्चित मानचित्र पर होता है।

दोनों कॉम्बैटेंट में क्रिटिकल हिट और डॉज जैसे कौशल हो सकते हैं।

अब, किस वस्तु के लिए जिम्मेदार है?

इसका एक भी सही जवाब नहीं है। बहुत कुछ इस बात पर निर्भर करता है कि आप किस तरह के अनुकूलन की अनुमति देना चाहते हैं।

यदि आप कभी भी ऑब्जेक्ट (उदाहरण के लिए मैप) को कॉल नहीं करते हैं, तो वह ऑब्जेक्ट किसी भी तरह से हमले को बदल नहीं सकता है।

ये सभी निर्णय लेने के बाद, उन्हें दस्तावेज दें । एक "मॉड्यूल्स मैनुअल" लिखें, जो यह बताता है कि प्रत्येक वस्तु में क्या-क्या मोडेबल विधियां हैं, वे कौन से पैरामीटर लेते हैं, उन्हें क्या लौटना चाहिए, और इसी तरह और इतने पर और ...

सौभाग्य!


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

@tis इस की कुंजी इस बात का सही निर्णय ले रही है कि गेम के आपके OO मॉडल में वास्तव में क्या वस्तुएं हैं। शुरू करने के लिए "स्पष्ट" जगह "संज्ञाओं" के साथ है जैसे हथियार, कवच, आदि केवल एकमात्र तरीका नहीं है, और यह बिना कोड के गड़बड़ उलझ सकता है। यदि कोई नियम कहता है कि "आप आधी रात को चर्च के एक परिसर में चांदी की गोलियों से कुछ राक्षसों को मार देते हैं" तो आप उस नियम को कोड में कैसे लागू करते हैं? गन (या बुलेट) क्लास में, मॉन्स्टर क्लास में, गन-यूजर के फाइटर क्लास में, चर्चयार्ड क्लास में, या टाइम क्लास में? सबसे अच्छा जवाब "उपरोक्त में से कोई नहीं" हो सकता है ...
alephzero

... और एक नियम वर्ग (जो कि वास्तव में एक डेटाबेस है) और एक संघर्ष समाधान वर्ग के संदर्भ में पूरे डिजाइन को पुनर्विचार करते हैं। अब, अन्य नियम जैसे "यदि आपके पास कोई गोलियां नहीं हैं, तो आप अभी भी अपनी बंदूक को एक क्लब के रूप में उपयोग कर सकते हैं" और "यदि ऐलिस एक जादू करता है जो आंशिक रूप से (लेकिन पूरी तरह से नहीं) बॉब को गोली के घावों से बचाता है, जबकि चार्ली बॉब को गोली मारने की कोशिश कर रहा है, फिर .... "एक एकल, और" स्पष्ट, "कोड में लागू किया जाना है। आप पा सकते हैं कि आपका मूल गन वर्ग अब बहुत कम करता है, सिवाय कुछ ऑडियो-विज़ुअल इफ़ेक्ट के - और वह भी नहीं, अगर यह एक टेक्स्ट-आधारित गेम है!
एलेफ़ेज़रो

1

इसके लिए कुछ मूल समर्थन प्राप्त करने का एक सरल तरीका यह होगा कि अधिकांश संख्यात्मक मूल्यों को एक या एक से अधिक अलग-अलग पाठ फ़ाइलों में विभाजित किया जाए ताकि इच्छुक व्यक्तियों को गुमनामी में बदल सकें।

उदाहरण के लिए, आपने टेबलटॉप गेम्स का उल्लेख किया है; यदि आपके पास D & D पर आधारित कोई गेम है, तो आपके पास एक weapon_damageफ़ाइल हो सकती है , जैसे लाइनें Battleaxe: 1d12। आपका उपयोगिता कोड उस फ़ाइल को पढ़ेगा और जब भी Battleaxeआपके कोड द्वारा क्षति का सामना किया जाएगा, generate a number from 1-12, 1 time(s)उन्हें जोड़ा जाएगा। Battleaxe: 4d6इसके बजाय पढ़ने के लिए लाइन को मोड़ना generate a number from 1-6, 4 time(s)और उन्हें जोड़ना होगा। इसी तरह, आपके पास एक फ़ोल्डर हो सकता हैCreatures और आपके अंदर प्रत्येक प्राणी के लिए एक फ़ाइल होती है, जिसमें लाइनें भी शामिल हैं AC: 12; फिर उस फ़ोल्डर में नई फाइलें जोड़ने से नए जीव बनेंगे। यह चरित्र वर्ग, इलाके प्रकार, चीजों की एक टन के लिए भी किया जा सकता है।

गैर-कोड अनुकूलन की यह शैली अभी भी बहुत शक्तिशाली हो सकती है और आपके खेल के बहुत सारे टुकड़ों को कवर कर सकती है। हालाँकि, यह वास्तव में उपयोगकर्ता को उन परिवर्तनों को करने की अनुमति नहीं देता है जिन्हें आपने स्पष्ट रूप से निर्दिष्ट नहीं किया था। उदाहरण के लिए, आप सक्षम कर सकते हैंSneak Attack: [damage] किसी भी प्राणी या वर्ग [damage]को किसी भी हमले में जोड़ने के लिए करने के लिए हैं जो एक चुपके हमले के लिए शर्तों को पूरा करता है। आप यहां तक ​​कि स्थितियों को बदलने के तरीके भी प्रदान कर सकते हैं, जैसे "जब भी आप चुपके से हमला करते हैं" या "जब भी आप फ़्लैंक कर रहे हों" या "जब भी आपको फायदा हो"। हालांकि, अगर कोई उपयोगकर्ता यह तय करता है कि वे चुपके से हमला करना चाहते हैं, "जब आप एक हमला रोल करते हैं, तो आप लक्ष्य की धारणा के खिलाफ चुपके से रोल भी कर सकते हैं। यदि दोनों रोल सफल होते हैं, तो स्नीक अटैक क्षति जोड़ें"

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


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

@tis क्या आपने इस विषय पर विकिपीडिया पर अभी तक क्या विचार किया है? en.wikipedia.org/wiki/Logic_programming
ttbek

0

[मैं एक दशक लंबे सॉफ्टवेयर डेवलपर हूं, लेकिन कोई गेम डेवलपमेंट अनुभव नहीं है, इसलिए हो सकता है कि गेम इंडस्ट्री अलग-अलग तरीके अपनाती हो, हो सकता है अच्छे कारणों के लिए हो ...]

आपका दृष्टिकोण मेरे लिए बिल्कुल मायने रखता है। कोर बुनियादी कार्यक्षमताओं को देता है जो यांत्रिकी और नियम बनाते हैं, इसलिए यह एक एपीआई है जिसका उपयोग उच्च-स्तरीय घटकों द्वारा किया जाना है।

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

इसलिए, एक अच्छा तरीका कुछ काल्पनिक नियमों और यांत्रिकी को लिखना होगा, जिस तरह से आप उन्हें व्यक्त करना चाहते हैं (निश्चित रूप से, पायथन के सिंटैक्स के साथ), इस प्रकार यह पता लगाना कि आप क्या चाहते हैं कि कोर एपीआई नियमों और यांत्रिकी को प्रदान करें। परतों।

और निश्चित रूप से, मुझे लगता है कि वे क्या करते हैं, इसका अंदाजा लगाने के लिए मौजूदा खेलों की स्क्रिप्टिंग सुविधाओं पर एक नज़र डालने की सलाह देंगे।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.