ऑब्जेक्ट-ओरिएंटेड भाषा में गेम इंजन कैसे डिज़ाइन करें? [बन्द है]

Question

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

एक अच्छा डिजाइन क्या है और इसे कैसे लागू किया जाएगा? कुछ ऐसे ट्रेडऑफ़ हैं जिन्हें बनाया जाना है और उनके पेशेवरों / विपक्षों को?

Comments

विश्लेषण विश्लेषण पक्षाघात के बजाय आवेग पर जाने और वहां से फिर से सक्रिय होने में क्या गलत है?

— कम्युनिस्ट डक

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

— एक्सट्रोपिक-इंजन

@chuzzum, अच्छी बात है। एक चीज़ जो मैं सुझाऊँगा, वह है C4 इंजन के आर्किटेक्चर की जाँच करना; terathon.com/c4engine/images/altecture.png यह आपकी ज़रूरत से बहुत अधिक उच्च-स्तर का हो सकता है, लेकिन आपको कुछ विचार दे सकता है ;-)

— कम्युनिस्ट डक

i.imgur.com/81zIY.png

— द कम्युनिस्ट डक

साथ ही यह प्रश्न भी अस्पष्ट है। शायद अपना एक उदाहरण लें और उस पर एक गहन प्रश्न करें या दो।

— तेतराद

Answer 1

मुझे संदेह है कि कोई व्यक्ति यह कहने में सक्षम होने जा रहा है कि 'आपको यह करना है और यह और यह पैटर्न X का उपयोग करने वाला स्लॉट है।'

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

ये आपकी ज़रूरत के लिए बहुत कम हो सकते हैं, लेकिन आप किसी चीज़ के बारे में बहुत अधिक नहीं जान सकते हैं, और मुझे यकीन है कि आपको उनसे एक अच्छी योजना मिल जाएगी।

संपादित करें: मैं भूल गया कि Gamedev लेख को नई साइट के बाद से संग्रहीत किया गया है, निश्चित :)

Comments

Enginuity लिंक को तोड़ दिया गया था, और लेखों को देखने से प्रतीत होता था कि वे अब वेब पर नहीं हैं। (?) किताबें अच्छे संसाधनों की तरह दिखती हैं, और मैं हमेशा अधिक प्रोग्रामिंग पुस्तकों के लिए नज़र रख रहा हूँ;)

— एक्सट्रोपिक-इंजन

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

— एक्सट्रोपिक-इंजन

लिंक तय किया।

— कम्युनिस्ट डक

पूर्णता के लिए +1। @chuzzum बस खेल इंजन के एक जोड़े की जांच करें, उन्हें आपको प्रेरित करें और अपने लिए इष्टतम वास्तुकला प्राप्त करें। प्लस: पदानुक्रमित की तुलना में अपने गेम इंजन घटक को बनाने के लिए अक्सर बेहतर होता है, देखें काउबॉयप्रोग्रामिंग.com

— डेव ओ।

मैं यह नहीं कहूंगा कि यह वह इंजन है जिसे इकाइयाँ करने की आवश्यकता है, और अधिक इकाई ढांचा भाग।

— कम्युनिस्ट डक

Answer 2

एक उदाहरण के रूप में, यहां बताया गया है कि मेरी वर्तमान रॉगुलाइक परियोजना कैसे संरचित है (जावा में)। यह एक 2D ग्राफिक्स इंजन का उपयोग कर रहा है, इसलिए मेरे लिए पहले से ही बहुत सारे प्रतिपादन कोड का ध्यान रखा गया था। आलोचना का स्वागत किया है।

class Game
यह वर्ग राज्य मशीन स्थापित करता है जो खेल की वर्तमान स्थिति का प्रबंधन करता है। (एक मेनू में बनाम एक नया गेम शुरू करने बनाम एक सहेजा गया गेम खेलना)

interface State
प्रत्येक राज्य वर्ग में दो लूप होते हैं: तर्क को अपडेट करने के लिए एक लूप और रेंडरिंग के लिए एक लूप। उनमें Gameक्लास को कॉल करने और एक अलग राज्य में बदलाव का अनुरोध करने के लिए कोड भी हैं ।

class ResourceManager
एक सिंगलटन जो उस Gameवर्ग द्वारा आरम्भ किया जाता है जो सभी आवश्यक संसाधनों को लोड करता है और उन तक पहुँच की अनुमति देता है। मुझे यह डिज़ाइन पसंद नहीं है क्योंकि यह विभिन्न स्तरों पर संसाधनों को लोड / अनलोड करना कठिन बनाता है, उदाहरण के लिए। अगर मैं शुरू कर रहा था तो मैं इसे अलग तरह से डिजाइन करूंगा।

class Map
मानचित्र में टाइलों की एक सरणी और मानचित्र पर सभी प्राणियों और वस्तुओं की एक सूची होती है। यह काफी बुनियादी वर्ग है।

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

interface AITask
जीवों के पास एआईटीकेएस की एक सूची हो सकती है, जो हर बार प्राणी के लॉजिक लूप चलने पर निष्पादित होती हैं। AITask का अपना लॉजिक लूप है जो प्राणी को आदेश जारी करता है, और एक समाप्ति स्थिति जो यह निर्धारित करती है कि कार्य सफलतापूर्वक पूरा हुआ या नहीं।

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

Comments

क्या वास्तव में यह गलत हो रहा है? यह मुझे पूरी तरह से ठीक लगता है।

— कम्युनिस्ट डक

@ TheCommunistDuck यह वास्तव में मेरे द्वारा चुने गए उदाहरणों के माध्यम से नहीं आता है, लेकिन मुझे इस कोड के साथ बहुत सारी समस्याएं हैं। रिसोर्समैन क्लास उनमें से एक है, लेकिन मुझे राज्यों के साथ भी परेशानी है- मैं उनमें से एक बड़े प्रसार के साथ समाप्त होता हूं, और बहुत सारे कोड कॉपी करता हूं। विशेष रूप से एक आरपीजी में, जहां खिलाड़ी के पास किसी भी एक समय में बहुत सारे विकल्प होते हैं, आप वास्तव में जटिल राज्य ग्राफ़ के साथ समाप्त हो सकते हैं। उदाहरण: एक जादू कास्टिंग। NormalState से जाता है -> SelectSpellState -> SelectTargetState -> InvalidTargetState (यदि यह विफल रहा है) -> DoSpellAnimationState -> NormalState। और वह सिर्फ एक क्रिया है।

— एक्सट्रोपिक-इंजन

नहीं नहीं। सं । नहीं। कृपया नहीं। ओह रुको आपने कहा कि आपको यह पसंद नहीं है।

— बार्टेक बैनविचेज

Answer 3

पहला महत्वपूर्ण बिंदु यह है कि इस प्रश्न का कोई 'अच्छा' उत्तर नहीं है।

सही उत्तर के लिए निकटतम बात कुछ इस तरह होगी: यह बहुत कुछ खेल के प्रकार, लक्ष्य मंच, बाधाओं (समय) पर निर्भर करता है।

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

मेरा वर्तमान डिज़ाइन Quake3 / Doom3 का एक हाइब्रिड है और .NET क्लास लाइब्रेरी का एक छोटा सा है :)

मेरे पास दो पुस्तकालय हैं (स्थैतिक या गतिशील इस बात पर निर्भर करता है कि आप निर्माण कैसे करें / वितरित करें) Frameworkऔर Library।

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

यदि आप इसे कॉल करना चाहते हैं तो फ्रेमवर्क 'इंजन' की हिम्मत है। इसमें से बहुत सारे क्वेक 3 के डिजाइन दर्शन (केवल एक अधिक वस्तु केंद्रित तरीके से) का अनुसरण करते हैं। इसमें सीएलआई , समय प्रबंधन, ओएस विशिष्ट कोड और अंततः नेटवर्किंग परतें आदि शामिल हैं।

इसके बाद इन दोनों को वास्तविक ऐप के साथ जोड़ा जाता है, जिसका उत्पादन किया जा रहा है। Gameआप की तरह है, जो खेल विशिष्ट कोड है या नहीं। बहुत हद तक क्वेक 3 डीएलएल पर निर्भर करता है जिसके आधार पर 'मॉड' खेला जा रहा है।

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

---

• ढांचा
  • IO (स्पेशलिस्ट फाइल मैनेजमेंट क्लासेस, टेक्स्ट प्रिंटिंग क्लासेस (जैसे CLI), और लॉगिंग आदि।
  • नेटवर्क
    • ग्राहक (वे वर्ग जो यह दर्शाते हैं कि फ्रेमवर्क 'व्यक्ति का खेल / खेल से जुड़ा हुआ' माना जाता है)
    • सर्वर (फ्रेमवर्क में कनेक्शन का प्रबंधन करने और खिलाड़ी को प्रबंधित करने के लिए कक्षाएं)
  • प्लेटफ़ॉर्म (कीबोर्ड / माउस / कंट्रोलर हैंडलिंग क्लासेस, OS विशिष्ट रूटीन जैसे गेटटाइम ())
  • सिस्टम (त्रुटि संदेशों की छपाई में सहायता के लिए एक त्रुटि वर्ग की तरह बहुत निम्न स्तर की कक्षाएं, समय कक्षाएं और सीएलआई ही।)
  • रेंडरर (स्व व्याख्यात्मक)
  • आदि।

---

• पुस्तकालय
  
  • संग्रह (वे वर्ग जो डेटा, लिंक की गई सूचियों / हैशटैब आदि के संग्रह का प्रतिनिधित्व करते हैं)
  • गणित (बेसिक गणित सहायक वर्ग जैसे वैक्टर और मैट्रीस)
  • आदि।

---

HTH! आपको कुछ संकेत देना चाहिए ...

Comments

— एंगिन्युइटी

Answer 4

विचार करने के लिए बातें

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

सुंदर डिजाइन

• ईआर आरेख बनाएं
• इसे सही करें
• अपना डेटाबेस, ऑब्जेक्ट या डेटा स्ट्रेंथ बनाएं

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

Comments

-1 चूंकि यह उत्तर बहुत अस्पष्ट और भ्रामक है। संबंधपरक डेटाबेस का OO- इंजन से कोई लेना-देना नहीं है। मैं समझ सकता हूं कि अंग्रेजी आपकी पहली भाषा नहीं है, लेकिन क्या आप संभवतः समझा सकते हैं कि आपके पहले पैराग्राफ में आपका क्या मतलब है? ऐसा लगता है कि विरोधाभासी (OO भाषाओं में समस्याएं हैं, लेकिन डिज़ाइन पैटर्न वाली भाषाओं में प्रोग्राम करना आसान है..क्योंकि डिज़ाइन पैटर्न लगभग हमेशा OO संरचनाएँ हैं)।

— कम्युनिस्ट डक

@d विरोधाभासी? OO में ऐसी समस्याएं हैं जो अन्य भाषाओं में मौजूद नहीं हैं, DP उन्हें हल करता है c2.com/cgi/wiki?DesignPatternsInDynamicProgramming देखें ।

— user712092

@ डक 1) आप सी ++ 2 में एसक्यूएल का उपयोग कर सकते हैं) आप ईआर से ऑब्जेक्ट्स की विशेषताओं का अनुमान लगा सकते हैं (क्योंकि यह अभ्यास की अनुशंसा नहीं की गई है) 3) आप संबंधों से स्ट्रक्चरल डेटा प्राप्त कर सकते हैं (यह एक सूची है क्योंकि मुझे हाथियों को विलोम करने की आवश्यकता है यह एक हैश है क्योंकि मुझे तेजी से देखने की जरूरत है)

— user712092

@ डक मैं माफी मांगता हूं, मैंने गलती करके गलती की। मैं यह दावा नहीं करना चाहता था कि "डीपी XY के लिए आसान है" लेकिन "जो भाषाएं प्रथम श्रेणी में कर सकती हैं ..."। :)

— user712092

हां, कार्यात्मक भाषाओं के फायदे हो सकते हैं। हालांकि, यहां तक ​​कि निष्पक्ष रूप से, मुझे लगता है कि एक OO दृष्टिकोण एक gamedev परिप्रेक्ष्य से तार्किक समझ में आता है। इसके अलावा, कोई कारण नहीं है कि आपको कहीं भी रिलेशनल डेटाबेस की आवश्यकता है। यकीन है, वे उपयोगी हो सकते हैं। हालांकि, यह कहीं भी एक आवश्यक घटक नहीं बनता है।

— कम्युनिस्ट डक