मान लीजिए कि आपके पास एक दृश्य है जो एक दुनिया , एक खिलाड़ी और एक बॉस से बना है। ओह, और यह एक तीसरा व्यक्ति खेल है, इसलिए आपके पास एक कैमरा भी है ।
तो आपका दृश्य कुछ इस प्रकार है:
class Scene {
World* world
Player* player
Enemy* boss
Camera* camera
}
(कम से कम, यह मूल डेटा है । आपके पास डेटा कैसे है, आप पर निर्भर है।)
जब आप गेम खेल रहे हों, तब ही आप अपडेट और रेंडर करना चाहते हैं, जब विराम न हो या मुख्य मेनू में हो ... तो आप इसे गेम स्टेट से अटैच कर दें!
State* gameState = new State();
gameState->addScene(scene);
अब आपके गेम स्टेट में एक दृश्य है। अगला, आप दृश्य पर तर्क चलाना चाहते हैं, और दृश्य प्रस्तुत करना चाहते हैं। तर्क के लिए, आप बस एक अद्यतन फ़ंक्शन चलाते हैं।
State::update(double delta) {
scene->update(delta);
}
इस तरह आप Sceneकक्षा में सभी खेल तर्क रख सकते हैं । और सिर्फ संदर्भ के लिए, एक इकाई घटक प्रणाली इसके बजाय ऐसा कर सकती है:
State::update(double delta) {
physicsSystem->applyPhysics(scene);
}
वैसे भी, अब आप अपने दृश्य को अपडेट करने में कामयाब हो गए हैं। अब आप इसे प्रदर्शित करना चाहते हैं! जिसके लिए हम उपरोक्त के समान कुछ करते हैं:
State::render() {
renderSystem->render(scene);
}
तुम वहाँ जाओ। रेंडरसिस्टम दृश्य से जानकारी पढ़ता है, और उपयुक्त छवि प्रदर्शित करता है। सरलीकृत, दृश्य को प्रस्तुत करने की विधि इस तरह दिख सकती है:
RenderSystem::renderScene(Scene* scene) {
Camera* camera = scene->camera;
lookAt(camera); // Set up the appropriate viewing matrices based on
// the camera location and direction
renderHeightmap(scene->getWorld()->getHeightMap()); // Just as an example, you might
// use a height map as your world
// representation.
renderModel(scene->getPlayer()->getType()); // getType() will return, for example "orc"
// or "human"
renderModel(scene->getBoss()->getType());
}
वास्तव में सरलीकृत, आपको अभी भी आवश्यकता होगी, उदाहरण के लिए, आपके खिलाड़ी कहां है और वह कहां देख रहा है, इसके आधार पर एक रोटेशन और अनुवाद लागू करें। (मेरा उदाहरण एक 3 डी गेम है, यदि आप 2 डी के साथ जाते हैं, तो यह पार्क में टहलने जाएगा)।
मुझे आशा है कि यह वही है जो आप ढूंढ रहे थे? जैसा कि आप ऊपर से याद कर सकते हैं, रेंडर सिस्टम गेम के तर्क की परवाह नहीं करता है । यह केवल दृश्य की वर्तमान स्थिति को रेंडर करने के लिए उपयोग करता है, अर्थात यह रेंडर करने के लिए इससे आवश्यक जानकारी खींचता है। और खेल तर्क? यह परवाह नहीं करता है कि रेंडरर क्या करता है। बिल्ली, यह परवाह नहीं करता है अगर यह बिल्कुल भी प्रदर्शित होता है!
और आपको दृश्य को जानकारी प्रदान करने की आवश्यकता नहीं है। यह पर्याप्त होना चाहिए कि रेंडरर जानता है कि उसे orc रेंडर करने की आवश्यकता है। आपने पहले ही एक orc मॉडल लोड किया होगा, जिसे रेंडरर तब प्रदर्शित करना जानता है।
यह आपकी आवश्यकताओं को पूरा करना चाहिए। ग्राफिक प्रतिनिधित्व और तर्क युग्मित हैं , क्योंकि वे दोनों एक ही डेटा का उपयोग करते हैं। फिर भी वे अलग हैं , क्योंकि न तो दूसरे पर निर्भर हैं!
संपादित करें: और सिर्फ यह जवाब देने के लिए कि कोई ऐसा क्यों करेगा? क्योंकि यह आसान है सबसे सरल कारण है। आपको "इस तरह के और इस तरह के होने के बारे में सोचने की ज़रूरत नहीं है, मुझे अब ग्राफिक्स को अपडेट करना चाहिए"। इसके बजाय आप सामान बनाते हैं, और प्रत्येक फ्रेम खेल को देखता है कि वर्तमान में क्या हो रहा है, और इसे किसी तरह से व्याख्या करता है, जिससे आपको ऑन-स्क्रीन परिणाम मिलता है।
