मैं एक ही समय में क्लाइंट और सर्वर दोनों को कुशलता से कैसे कोड करूं?


15

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

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

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

क्या मुझे सर्वर में उपयोग करने के लिए क्लाइंट कक्षाओं के संशोधित संस्करण बनाने चाहिए? या क्या मुझे केवल एक बूलियन के साथ ग्राहक वर्गों को संशोधित करना चाहिए, यह इंगित करने के लिए कि क्या इसका क्लाइंट / सर्वर इसका उपयोग कर रहा है। क्या मेरे पास कोई अन्य विकल्प हैं? मैं बस कोर वर्ग के रूप में सर्वर वर्ग का उपयोग करने के बारे में एक विचार था, तो यह सामान प्रदान के साथ विस्तार?


क्या आपके पास प्री-प्रोसेसर विकल्प हैं? जैसे #ifdef CLIENT <कुछ कोड> #endif। यह साझा वर्ग फ़ाइलों के होने का एक सरल तरीका है, जो सर्वर और क्लाइंट के बीच भिन्न हो सकता है और भागों को भी साझा कर सकता है। हालांकि यह थोड़ा गड़बड़ है।
विलियम मैरीजर

मैं MindWorX से सहमत हूं। हालांकि सशर्त संकलन जावा में एक दर्द है, ऐसे समाधान हैं जिन पर विचार किया जाना चाहिए।
sam hocevar 10

1
सशर्त संकलन यह कहने का एक कच्चा तरीका है कि "मैंने अपने पैकेजों में पर्याप्त डिजाइन समय नहीं डाला," मेरे विचार में =) "थोड़ा गड़बड़" आमतौर पर "क्या बिल्ली ऐसा करती है?" छह महीने बाद जब आप अपने स्वयं के कोड को फिर से पढ़ते हैं और किसी भी चीज़ के लिए काउंटर-प्रोडक्टिव होते हैं, लेकिन फेंकने वाले प्रोटोटाइप।
पैट्रिक ह्यूजेस

जवाबों:


23

आपको अपने रेंडरिंग कोड को अपने गेम लॉजिक से अलग रखना पसंद करना चाहिए , क्योंकि वे अलग-अलग चिंताएँ हैं

यदि आप अपना रेंडर कोड अपने क्लाइंट / सर्वर कोड से अलग करते हैं, तो आपको कुछ फायदे मिलते हैं:

  • एक समर्पित सर्वर बनाना आसान होगा, क्योंकि रेंडर करने वाला कोई भी कोड एक ही जगह पर होगा।
  • आप अपने updateचरण को अपने चरण से अलग कर सकते हैं render, और उन्हें अलग-अलग समय पर चला सकते हैं।
  • आप constबग्स को कम करके , उपयोग करके अपने रेंडरिंग कोड को गेम स्टेट को म्यूट नहीं कर सकते ।

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

5

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


+1 मैं इससे सहमत हूं। यदि सर्वर किसी भी क्लाइंट को चलाने जा रहा है, तो उसे अलग-अलग प्रक्रियाओं के रूप में ऐसा करना चाहिए।
इंजीनियर

5

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.