ऑब्जेक्ट्स के एरेज़ या ऐरे की वस्तु?

13

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

मान लीजिए कि मेरे खेल में मेरे 5,000 लोग हैं:

एक वस्तु बनाएं और उन्हें एक सरणी में स्टोर करें जैसे;

class person() {
    this.x = 0;
    this.y = 0;
    this.thirst = 15;
    this.hunger = 15;
    // etc.. add methods:
    public findPath(int destX, int destY) {
    // and so on
    }

    people = new person[5000];

for (int = 0; i < 5000; i++) {
    people[i] = new person;
    }

या क्या मुझे ऐसे लोगों की एक वस्तु बनानी चाहिए जिसमें कई बाइट सरणियाँ हैं जो लोगों की विशेषताओं का प्रतिनिधित्व करती हैं:

class people() {
    this.hunger = new byte[5000]
    this.thirst = new byte[5000]

    getThirst(int i) {
        return this.thirst[i]
        }

 // and so on....

या मैं पूरी तरह से निशान से दूर हूँ?

java architecture data-structure

— ali_goes_oosh
स्रोत

बहुत दिलचस्प सवाल, विशेष रूप से 2013 में, आरसीटी के बाहर आने के बाद एक दर्जन से अधिक वर्षों में, एक दुनिया में 5000 दृश्यमान, स्वतंत्र एनपीसी होने का विचार पूरी तरह से असंभव दिखाई देगा (प्रौद्योगिकी में प्रगति के बावजूद)

— कटाना 314

15

सामान्य शब्दावली "सरणियों की संरचना" (एसओए) और "संरचनाओं की सरणी" (एओएस) है जो सी से आती है और सबसे अधिक बार सिमड कार्य के संदर्भ में देखी जाती है।

आमतौर पर, एओएस दृष्टिकोण तेजी से होता है, यदि उचित रूप से उपयोग किया जाता है, लेकिन एसओए के साथ काम करना आसान हो जाता है (और इसलिए अधिक महत्वपूर्ण गुणवत्ता - विकास समय के लिए अनुकूलन करता है)।

SOA, विशेष रूप से जावा में, इसका अर्थ है कि आपका डेटा मेमोरी में कसकर पैक किया जा सकता है। आप संपत्तियों पर पुनरावृत्ति कर सकते हैं और सीपीयू कैश और इस तरह खुश रहने की उम्मीद कर सकते हैं। AOS के साथ, विशेष रूप से जावा में, प्रत्येक ऑब्जेक्ट मेमोरी में "कहीं न कहीं" आवंटित होता है। ऑब्जेक्ट्स पर Iterating संभवतः आपके CPU कैश को बहुत अधिक जोर से फेंक सकता है।

अंत में, मैं आपको जो भी उपयोग करने में आसान लगता हूं, ले जाऊंगा। आपका विकास समय कहीं अधिक मूल्यवान है कि क्या आपका खेल 10 साल पुराने पीसी या केवल 9 साल पुराने पीसी का समर्थन करता है (आप कुछ भी करने की संभावना नहीं है। htat को नवीनतम हार्डवेयर की आवश्यकता है)।

— शॉन मिडिल्डिच
स्रोत

1

अपने तीसरे पैराग्राफ में क्या आपका मतलब दो बार एओएस से है? टिप्पणियाँ विरोधाभासी लगती हैं ...

— ali_goes_oosh

क्षमा करें, इसे ठीक किया।

— सीन मिडिलिचच जुले

4

कोई कारण नहीं है कि आप दोनों नहीं हो सकते हैं, एक इंटरफ़ेस से दूसरे अंतर्निहित प्रतिनिधित्व में अनुवाद करने के लिए मुखौटा पैटर्न का उपयोग कर रहे हैं । उदाहरण के लिए, सीन के SOA / AOS शब्दों का उपयोग करना:

SOA मुखौटा

class PeopleFacade {
    Person persons[5000];
    getThirst(int i) { return persons[i].thirst; }
}

AOS मुखौटा

class People { int thirsts[5000]; } people;
class PersonFacade {
    int i;
    getThirst() { return people.thirsts[i]; }
}

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

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

class People { int nonRobotThirsts[1000]; } people;
class PersonFacade {
    int i;
    bool isRobot;
    getThirst() {
        if (isRobot)
            return 0;
        else
            return people.nonRobotThirsts[i];
    }
}

... या अधिक OO दृष्टिकोण का उपयोग करते हुए, आपके पास एक अलग Robotवर्ग होगा जो वास्तव में एक Personअपवाद के समान कार्य करता है getThirst()।

— congusbongus
स्रोत

-1

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

हर समय यह सोचें कि किसी Personऑब्जेक्ट को क्वेरी से वापस लेना आसान होगा । यह संदेश किसने भेजा है? उदाहरण के लिए। आपके द्वारा लिखे गए बहुत सारे तरीके जानना चाहेंगे कि वे किसके साथ काम कर रहे हैं। और आपके पास बहुत सारे तरीके होंगे जो एक उचित Personकक्षा में अच्छी तरह से फिट होंगे । यदि Personस्थिर या एक सिंगलटन है, तो आप उन तरीकों को कहाँ रखते हैं जो व्यक्तिगत लोगों पर कार्य करते हैं?

क्या आपको कभी मल्टीथ्रेडिंग करना चाहिए - और 5000 उपयोगकर्ताओं के साथ आपको इसमें धकेला जा सकता है - आपको प्रत्येक उपयोगकर्ता के लिए पैरेंट उदाहरण बहुत अधिक व्यावहारिक मिलेगा ।

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

— RalphChapin
स्रोत