2010-09-18 2 views
8

मैं हाल ही में एक सिमुलेशन/रणनीति खेल के लिए एक विचार के साथ आया था। मैं गेम मैकेनिक्स के बारे में अपने कई विचारों को पेपर पर स्केच कर रहा हूं और साथ ही साथ कुछ बुनियादी वर्गों और वस्तुओं को काम कर रहा हूं। (मैं इसे एक्सएनए का उपयोग कर सी # में लिख रहा हूं)।क्या मुझे अपना गेम विचार पहले टेक्स्ट मोड में विकसित करना चाहिए?

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

तो यहां समुदाय से मेरा प्रश्न यह है कि क्या मुझे इसे केवल टेक्स्ट बेस मोड में काम करने के लिए ध्यान केंद्रित करके अवधारणा के लिए अपना उत्साह बनाए रखने की कोशिश करनी चाहिए और फिर इसे एक सुंदर ग्राफिकल इंटरफ़ेस देने पर पुन: समूह करना चाहिए?

या

एक ही समय में मैं अपने विचार बाहर फ्लश करने के लिए कोशिश कर रहा हूँ पर ग्राफिकल इंटरफेस पहाड़ी का सामान?

इस प्रश्न को लिखने के दौरान मुझे लगता है कि मैंने इसे अपने लिए उत्तर दिया है, लेकिन मुझे लोगों से विचार सुनना अच्छा लगेगा।

+0

एक बात मैंने सीखा है कि बहुत कम गेम परियोजनाओं में गंभीर गुरुत्वाकर्षण है। आप अन्य लोगों की तुलना में अपने आप पर निर्भर होने से बेहतर हैं। क्या आपने सिर्फ गेम यूआई के साथ पूरा करने के लिए गेम को माना है? क्या यह काम करेगा? –

+0

यह मूल रूप से मैं अभी पर ध्यान केंद्रित कर रहा हूं। मैं अब केआईएसएस दृष्टिकोण ले रहा हूं। –

उत्तर

7

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

इस तरह इससे कोई फर्क नहीं पड़ता कि आपका विचार क्या है (टेक्स्ट-आधारित या ग्राफिक्स)। आप बस दृश्य में मेटाडेटा पास कर सकते हैं, और दृश्य यह तय करेगा कि इसे कैसे प्रस्तुत किया जाए।

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

एक बार जब आप सबकुछ बाहर निकल जाएंगे, तो आप ग्राफिक्स सीखना शुरू कर सकते हैं और धीरे-धीरे अपनी ग्राफिक्स परत शुरू कर सकते हैं।

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

मैं सिर्फ स्पष्ट है कि मैं अपने खेल के लिए एक MVC पैटर्न की वकालत नहीं कर रहा हूँ होना चाहता हूँ - मैं सिर्फ इतना है कि यह आप के लिए आसान है चिंता की जुदाई जोर देना चाहते महत्वपूर्ण रिफैक्टरिंग किए बिना अपना विचार स्वैप करें।

+0

मुझे लगता है कि मुझे यह दृष्टिकोण पसंद है। अधिकांश निर्णय मेनू/एक्शन बटन के प्रकार में किए जा सकते हैं। सभी चीजें जो डिजाइन पक्ष में बाद में छोड़ी जा सकती हैं। काम पर मैं बहुत सारे SQL कार्य करता हूं, प्रश्न स्तर पर क्रंच संख्या करता हूं, रिपोर्ट को इसे सुंदर दिखने दें। –

+0

@NA स्लैकर बिल्कुल। सभी व्यस्त कार्य करें और डेटा को देखने के लिए पास करें - दृश्य को तय करें कि इसके साथ क्या किया जाए। –

+0

प्लस, यदि आप कभी भी जीयूआई में संशोधित करना चाहते हैं, तो आपको वास्तविक गेम निष्पादन योग्य स्पर्श करने की आवश्यकता नहीं है; बस एक नया दृश्य लिखें या मौजूदा एक –

0

यदि मैं आप थे, तो मैं पहले टेक्स्ट-आधारित कमांड लाइन इंटरफ़ेस बनाउंगा। फिर, यदि आप एक वास्तविक जीयूआई बनाने का फैसला करते हैं, तो आप केवल जीयूआई कमांड लाइन गेम को स्वचालित कर सकते हैं, इसलिए आपको खेल तर्क दो बार लिखना नहीं है। कई टूल इस दृष्टिकोण का उपयोग करेंगे। कोई, उदाहरण के लिए, कमांड लाइन डीफ्रैग्मेंटेशन टूल बनाएगा और फिर कोई टूल के लिए जीयूआई "रैपर" बनाएगा। Sort of like what Nethack did.

0

एक यूआई बनाएं। ग्राफिक्स को सरल रखें (पेंट) और उपयोगिता पर ध्यान केंद्रित करें। फिर अपने गेम को ओपन सोर्स के रूप में रिलीज़ करें और कोई और अच्छा ग्राफिक्स और कूल यूआई बनाएगा।

+0

गंभीर होने के लिए बहुत आशावादी। –

+0

यदि आपके पास उस विषय पर कोई अनुभव है, तो कृपया इसे साझा करें। मुझे नहीं लगता कि यह बहुत आशावादी है। यदि कोई ऐसा व्यक्ति है जो सॉफ़्टवेयर का उपयोग करता है, तो कोई ऐसा व्यक्ति भी है जो इसे सुधारने में मदद करेगा। – Cephalopod

0

मेरी सलाह: लगभग कोई सॉफ्टवेयर आजकल अकेले नहीं किया जा सकता है।

अपने विचारों को स्केच करने का प्रयास करें, कहीं पोस्ट करें, रुचि रखने वाले लोगों को ढूंढें, समूह को इकट्ठा करें, और अपने हाथों को गंदे करें।

यदि आपका विचार वास्तव में अच्छा है, तो आपको अधिक टीम के सदस्य मिलेंगे जो आवश्यक अन्य क्षेत्रों में विशेषज्ञता की कमी को भर सकते हैं।

आप ओपन-सोर्स प्रोजेक्ट की तरह कुछ शुरू करने के लिए वेब पर लोगों को खोजने का प्रयास कर सकते हैं, या आप एक निवेशक को खोजने का प्रयास कर सकते हैं, जो आपके व्यवसाय पर पैसा लगा सकता है और आप विशेष लोगों को किराए पर ले सकेंगे।

1

एक गेम एक जटिल परियोजना है जिसे कई डिब्बों में विभाजित किया जा सकता है। ये वास्तविक मॉड्यूल (उदा।, एक जीयूआई रेंडरर या संचार प्रबंधक) हो सकता है, या वे "सैद्धांतिक या तार्किक हो सकते हैं, जैसे कि" गेम डिज़ाइन "।

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

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

+0

मैं इसे ध्यान में रखूंगा। ऐसा करने का एक लाभ यह है कि कीबोर्ड शॉर्ट-कट परिभाषित एक पूर्ण सेट होगा जिसे कभी भी ग्राफिकल इंटरफ़ेस के साथ परिपक्व बिंदु तक पहुंचना चाहिए। –

+0

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