खेल राज्य प्रणाली के लिए वैकल्पिक?

Question

जहां तक ​​मैं बता सकता हूं, अधिकांश खेलों में कुछ प्रकार के "गेम स्टेट सिस्टम" होते हैं जो विभिन्न गेम स्टेट्स के बीच स्विच करते हैं; ये "इंट्रो", "मेनमेनू", "कैरेक्टेलेक्ट", "लोडिंग" और "गेम" जैसी चीजें हो सकती हैं।

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

यह मुझे मूर्खतापूर्ण लगता है कि "गेम" को "मेन मेनू" के समान स्तर पर रखा गया है। फिर भी "गेम" स्थिति को तोड़ने का कोई तरीका नहीं है।

क्या एक खेल राज्य प्रणाली जाने का सबसे अच्छा तरीका है? क्या "गेम स्टेट" को प्रबंधित करने के लिए कुछ अलग, बेहतर तकनीक है? क्या एक इंट्रो स्टेट होना ठीक है जो एक मूवी ड्रॉ करता है और एंटर के लिए सुनता है, और फिर एक लोडिंग स्टेट जो रिसोर्स मैनेजर पर लूप करता है, और फिर गेम स्टेट जो प्रैक्टिकल रूप से सब कुछ करता है ? क्या यह आपको असंतुलित नहीं लगता है? क्या मैं कुछ भूल रहा हूँ?

Answer 1

मुझे लगता है कि आप यहां सिर्फ शब्दार्थ पर बहस कर रहे हैं। इसे गेम स्टेट कहा जाता है क्योंकि यह एक परिमित स्टेट मशीन की तरह व्यवहार करता है , जिसमें कई राज्यों की संख्या और उनके बीच संक्रमण होता है। State गेम स्टेट सिस्टम ’में The गेम’ समग्र प्रणाली को संदर्भित करता है, जिसमें, Loading ’, 'MainMenu’ आदि खेल के राज्य हैं। इन्हें आसानी से 'दृश्य' या 'स्क्रीन' या 'स्तर' कहा जा सकता है। इसका सिर्फ शब्दार्थ है।

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

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

Comments

यह ठीक यही है कि इसे कैसे किया जाना चाहिए। स्क्रीन एक पेड़ जैसी वास्तुकला में कई अन्य स्क्रीन शामिल करने में सक्षम होना चाहिए। इसलिए आपके प्रोग्राम में एक गेम स्क्रीन होती है, जिसमें एक पॉज़-मेनू स्क्रीन होती है, जिसमें एक ऑडियो सेटिंग्स स्क्रीन और एक गेम सेटिंग्स स्क्रीन होती है। आदि

— Iain

मैं इसके लिए उदाहरण स्रोत कोड देखना पसंद करूंगा! (C ++ / C # / जावा में अधिमानतः)

— Zolomon

दुर्भाग्य से, मैं केवल इस समय उत्पादन कोड है, लेकिन एक समान अवधारणा XNA खेल राज्य नमूने में है: creators.xna.com/en-GB/samples/gamestatemanagement

— DrDeth

Answer 2

यकीन है कि खेल राज्य बहुत बड़ा होगा, लेकिन ऐसा कोई कारण नहीं है कि खेल राज्य में अपने डेटा का प्रबंधन करने के लिए राज्य मशीन नहीं हो सकती है। पदानुक्रमित राज्य मशीनें उपयोगी हैं।

Answer 3

मैं हमेशा "दृश्य" के रूप में प्रत्येक "राज्य" के बारे में सोचना पसंद करता हूं। तो उद्घाटन वीडियो एक दृश्य है, बस एक स्थिर है। क्रेडिट एक दृश्य है। मेनू एक दृश्य है। उन सभी के बीच एकमात्र अंतर अन्तरक्रियाशीलता और खेल तर्क का स्तर है।

Answer 4

मुझे वास्तव में इससे भी समस्या है।

मान लीजिए कि आपके पास एक गेम है।

'खेल' को 'लोडिंग', 'मेन मेन्यू', आदि जैसे राज्य बनाने के बजाय - IMO यह बेहतर है कि गेम को कई राज्यों में रखा जाए:

"लोड हो रहा है - " मेनू दिखा रहा है " - " रुका हुआ " , आदि।

खेल अभी भी चल रहा है, लेकिन जब यह मुख्य मेनू दिखाता है तो यह 'शो मेनू' मोड में होगा।

और जब गेम किसी विशेष स्थिति में नहीं है, तो बस चल रहा है।

यह बहुत अधिक समझ में आता है, कम से कम मेरे लिए। :)

Comments

मैं सहमत हूँ। कोई भी खेल-राज्य से बाहर निकलने के लिए सिर्फ पॉज-स्टेट में प्रवेश नहीं करना चाहता है । दूसरी ओर: यह अभी भी एक राज्य प्रणाली है .. बस नेस्टेड :)

— bummzack

Answer 5

एक ऑनलाइन कार्यक्रम (ऑनलाइन के पारंपरिक अर्थ में, यानी। लगातार चलने और इनपुट पर प्रतिक्रिया देने के बजाय, इंटरनेट से जुड़े अर्थ से) आमतौर पर 3 चीजें होती हैं:

• इनपुट एकत्र करना और संभालना
• तर्क का अद्यतन
• उत्पादन

सामान्यतया, ये 3 एक ही समय में संबंधित और बदलते हैं। उदाहरण के लिए, एक स्प्लैश स्क्रीन प्रदर्शित करते समय आप अपनी सभी कुंजियों को एक 'क्लोज स्क्रीन ’कमांड पर मैप कर सकते हैं और अपडेट एक ग्राफिक को धीरे-धीरे आउटपुट के साथ फीका कर रहा हो सकता है। लेकिन जब कोई गेम खेलता है, तो सभी अलग-अलग कमांड में मैप कर सकते हैं और अपडेट कई इन-गेम ऑब्जेक्ट्स के गुणों को बदल रहा है।

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

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

Answer 6

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

Comments

मैं वही कहने जा रहा था ... मेरे सभी मेनू, स्क्रीन, जो भी हो, बस एक और स्तर हैं।

— स्पीडर

Answer 7

मेरे खेल में, मेरे पास है:

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

गेम स्टेट मैनेजर , जो GameLogicEngine में रहता है, और गेम मेन लूप से संबंधित चीजों को नियंत्रित करने के लिए जिम्मेदार है: टकराव का पता लगाने, भौतिकी गणना, कीबोर्ड रीडिंग, गणित संचालन, आदि ...

प्रारंभ में, मुझे केवल एक गेम स्टेट मैनेजर मिला, जो मेरे गेमलीजिक्युटीन का हिस्सा था। हालाँकि, मुझे मुख्य उपप्रणालियों (GameLogic, ApplicationEngine, ...) के गहनिकरण पर नियंत्रकों के साथ कुछ कठिनाइयाँ हुईं। यह किया जा सकता था, लेकिन यह अधिक गन्दा था, इमो।

अब चीजें मुझे अधिक पारदर्शी लगती हैं, और मैं डिजाइन से खुश हूं।

Answer 8

'गेमप्ले' जैसी चीज के लिए 'गेम' स्टेट का नाम बदलें। तब तुम्हारा तर्क बेहतर मालूम होता है; आप वें मेनू पर जाने के लिए खेलना बंद कर देते हैं: आप मेनमेनू राज्य में जाने के लिए गेमप्ले राज्य से बाहर निकलें।

इसके अलावा, मुझे लगता है कि ठहराव जैसी चीजें, जिनके लिए खेल की आवश्यकता उसी स्थिति में होगी जब आपने खेल को रोका था, अलग राज्य नहीं होना चाहिए। बाल राज्य और घोंसले के शिकार, शायद? गेमप्ले में एक विराम मेनू है।

Answer 9

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

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

मुझे उम्मीद है कि थोड़ा अलग प्रणाली का एक विचार देता है जो राज्य-मशीन पर आधारित नहीं है।

Answer 10

क्या एक इंट्रो स्टेट होना ठीक है जो एक मूवी ड्रॉ करता है और एंटर के लिए सुनता है, और फिर एक लोडिंग स्टेट जो रिसोर्स मैनेजर पर लूप करता है, और फिर गेम स्टेट जो प्रैक्टिकल रूप से सब कुछ करता है? क्या यह आपको असंतुलित नहीं लगता है? क्या मैं कुछ भूल रहा हूँ?

यह पूरी तरह से ठीक है। या कम से कम, यह "खेल के राज्य के आधार पर एक बड़ा बदसूरत स्विच होने" पर एक सुधार है।

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

यदि आपके पास पर्याप्त रूप से अमूर्त परिमित स्टेट मशीन है, तो आप इसे गेम ऑब्जेक्ट और आपके AI दोनों के लिए फिर से उपयोग कर सकते हैं; अचानक आप गेम स्टेट पर बहुत सारे "निवेश" नहीं कर रहे हैं - इसके बजाय आप कोड का पुन: उपयोग कर रहे हैं जो आपने वैसे भी उपयोग किया था।

बेशर्म सेल्फ-प्लग एंस्यूज़: मैंने अपने लुआ गेम लाइब्रेरी, मिडिलक्लास ( संक्षेप में , ऐड-ऑन को माइंडस्टेट कहा जाता है) पर ऐसी परिमित स्टेट मशीन लागू की है । यहां बताया गया है कि आप इसके साथ गेम स्टेट कैसे करते हैं ।

Answer 11

इसके लिए एक अलग दृष्टिकोण कार्यात्मक प्रोग्रामिंग की दुनिया से एक अवधारणा का उपयोग करना है जिसे एक भेदभाव संघ कहा जाता है । जब भी ये आम तौर पर एफपी भाषाओं में पाए जाते हैं, आप कक्षाओं का उपयोग करके उनका अनुकरण कर सकते हैं ।

मूल रूप से, एक भेदभाव वाला संघ एक प्रकार है जो हमेशा nमामलों में से एक होता है, और संग्रहीत डेटा प्रत्येक मामले के साथ भिन्न हो सकते हैं।

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

type GameState =
  | Menu of MenuState
  | Playing of SimulationState

यहां, हमारे GameStateप्रकार Menuया तो हो सकते हैं Playing। यदि यह है Menu, तो इसमें एक MenuStateऑब्जेक्ट होगा। यदि यह है Playing, तो इसमें एक SimulationStateऑब्जेक्ट होगा।

अपडेट करने के लिए, हम matchराज्य पर, और तदनुसार एक अलग फ़ंक्शन को कॉल करेंगे:

let update gameTime = 
  let nextState = 
    match gameState with
    | Menu menuState -> updateMenu gameTime menuState
    | Playing simulationState -> updateSimulation gameTime simulationState

  // Mutate the current state
  gameState <- nextState

और इसी तरह प्रतिपादन के लिए:

let render gameTime = 
  let nextState = 
    match gameState with
    | Menu menuState -> renderMenu menuState
    | Playing simulationState -> renderSimulation simulationState

इस दृष्टिकोण का एक फायदा यह है कि आप बिना किसी ग्लोबल्स या "सर्विस" ऑब्जेक्ट्स के पास से गुजरते हुए राज्यों (जैसे संसाधन) को आसानी से संभाल सकते हैं।