एक नया खेल विकसित करते समय विचार करने के लिए सबसे बड़ी नुकसान क्या हैं?


19

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

आम तौर पर एक वेबसाइट बनाते समय मुझे 'कोड में सोचना' पसंद होता है और मुझे इसे तेजी से खोजने के लिए कोड को बदलना / HTML को इसमें ट्वीक करना होता है। यह शायद इसलिए है क्योंकि मैं जो करता हूं उसमें बहुत आरामदायक हूं और मुझे पता है कि क्या उम्मीद करनी है जैसा कि मैंने इसे बार-बार किया है। खेल के विकास के साथ इस बिंदु पर मैं अपने आप को फिर से कागज पर शुरू कर रहा हूं (जैसे मैं वेबसाइटों के साथ उपयोग करता हूं) और मुझे आश्चर्य है कि क्या यह सिर्फ खेल तर्क के साथ फोकस और अंतर्ज्ञान की कमी है या अगर यह मेरे विचारों को बाहर निकालने का एक उपयुक्त तरीका है कोडिंग का अग्रिम।

मैं इस समस्या पर सही ढंग से हमला करने और खुद को काम पर रखने के बारे में कुछ सलाह की सराहना करूंगा। मैं जल्दी से सीख रहा हूं कि एक मानक व्यावसायिक वेबसाइट से गेम इंजन कितना अलग है! हर बार जब मैं कुछ हासिल करता हूं तो यह सिर्फ उदासीन और अधूरा लगता है और यह निराशाजनक होता जा रहा है।

विस्तृत

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

हो सकता है कि मेरी पोस्ट सरल गेम तर्क का वर्णन करने वाले सुझाए गए लिंक के लिए पूछ रही हो।

एक्सटेंशन समाप्त करें

एडवांस में आप सभी को धन्यवाद!


1
यह कुछ हद तक संबंधित और दिलचस्प है जिसे मैंने सहायक पाया है: makegames.tumblr.com/post/1136623767/finishing-a-game
zfedoran

जवाबों:


22

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


4
इसने मेरे एफबी खेलों में से एक को मार दिया। यह सुविधाओं के साथ पैक किया गया है, लेकिन पूरी बात समग्र रूप से आधा-मिश्रित है।
Tesserex

अगर मुझे सही से याद है तो इस घटना को "फीचर रेंगना" कहा जाता है। एक खतरनाक नुकसान, वास्तव में।
एस। तारिक 21etin

14

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

प्रोटोटाइपिंग: आप (शायद) गलत कर रहे हैं

विज्ञापन:

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

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

संपादित करें:

मैं इसे केवल प्रोटोटाइप और ट्रेसर कोड के बीच अंतर को स्पष्ट करने के लिए जोड़ रहा हूं।

हमेशा याद रखें: एक प्रोटोटाइप को फेंकने के लिए डिज़ाइन किया गया है! ट्रेसर कोड नहीं है।

प्रोटोटाइप ख़तरा

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

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

ट्रेगर कोड डिजाइन के बारे में अधिक जानकारी, व्यावहारिक प्रोग्रामर से

ट्रेसर बुलेट और प्रोटोटाइप


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

आपने जो गलती की है वह मुझे काफी समय से परेशान कर रही है।
जोकून

4

नुकसान: अपने तर्क को अपने डेटा से अलग नहीं करना। परीक्षण नहीं कि आपका डेटा वांछित परिणाम पैदा करता है।

जो की पोस्ट पर अपनी टिप्पणी से:

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

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

हालाँकि, क्योंकि संतुलन चर कभी-कभी अन्योन्याश्रित होते हैं, एक चर को बेहतर एक परिदृश्य में बदलने से अन्य परिदृश्यों पर एक विशाल (नकारात्मक) प्रभाव हो सकता है।

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

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);

EncounterEngine.SeedRNG(seed);
while(1) { result = EncounterEngine.Attack(player, monster); if (result == PLAYER_DEAD) return TEST_FAIL; if (result == MONSTER_DEAD) return TEST_PASS; // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. } }

उदाहरण के लिए। यदि आप इसे PlayerStats.Level == 5 और MonsterStats.Level == 3 के साथ कहते हैं, तो आप खिलाड़ी से इस राक्षस को अंततः हराने की उम्मीद करेंगे।


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

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

2

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

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


1

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


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

क्यों इंजन को फिर से लिखना? आप लुआ जैसी स्क्रिप्टिंग भाषा में गेम विशिष्ट कोड को लागू कर सकते हैं। परिवर्तन चर या गणित की गणना कैसे की जाती है और कभी भी केवल चीजों की जांच करने के लिए पुन: उपयोग करने की आवश्यकता नहीं होती है। gamedev.net/reference/articles/article1932.asp
डेविड यंग

1

मैं समय प्रबंधन और स्व-प्रेरणा के बारे में स्टीव पावलीना के लेखों की सिफारिश करूंगा : http://stevepavlina.narod.ru/

वह प्रोग्रामर भी है। उनके जीवनशैली प्रयोगों ने कुछ मुख्यधारा के मीडिया हित उत्पन्न किए हैं।

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