डेटा-उन्मुख डिजाइन (या क्यों, ओओपी का उपयोग करके, आप शायद खुद को पैर में गोली मारते हैं)

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

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

यह सब डेटा के बारे में है

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

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

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

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

बिल्कुल सही डेटा

चित्रा 1 ए। ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण के साथ कॉलिंग सीक्वेंस

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

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

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


चित्र 1 बी। डेटा-उन्मुख तकनीक में कॉल अनुक्रम

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

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

डेटा उन्मुख डिजाइन के लाभ

यदि हम सबसे पहले डेटा के बारे में सोचते हैं और इसके आधार पर प्रोग्राम का आर्किटेक्चर बनाते हैं, तो इससे हमें कई फायदे होंगे।

समानता

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

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

कैश का उपयोग

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

अनुकूलन विकल्प

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

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

प्रतिरूपकता

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

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

परीक्षण

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

डेटा उन्मुख डिजाइन के नुकसान

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

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

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

डेटा-ओरिएंटेड डिज़ाइन का उपयोग करना

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

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

यह कैसे उपयोग किया जाता है, इसके आधार पर आने वाले डेटा को वापस लेना और वर्गीकृत करना महत्वपूर्ण है। क्या वे केवल पढ़े-लिखे हैं, पढ़े-लिखे हैं या केवल लिखने वाले हैं? इस तरह के एक वर्गीकरण से कार्यक्रम के अन्य हिस्सों पर निर्भरता के कारण डेटा को कहां संग्रहीत करना है और इसे कैसे संसाधित करना है, इसके बारे में निर्णय लेने में मदद मिलेगी।

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

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

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

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

क्या OOP का उपयोग करने के लिए जगह बची है?

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

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

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

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