अपूर्ण प्रौद्योगिकी

नमस्ते मैं मिखाइल कपेल्को हूँ, ओपेंससोर्स गेम स्टूडियो टीम के लिए प्रोग्रामर। मैं आपको बताना चाहता हूं कि ओजीएस माहजोंग 1.0 की रिलीज के करीब पहुंचने पर हमने क्या सीखा, हमारी महाजोंग त्यागी की नवीनतम रिलीज (लेकिन माहजोंग श्रृंखला में अंतिम नहीं)। यह लेख पिछले एक जारी है: लॉन्ग वे टू माहजोंग 0.7

एक साल पहले, मई 2011 में, हमने ओजीएस माहजोंग 0.7 जारी किया, यह हमें बड़ी मुश्किल से दिया गया था। इस साल सितंबर 2012 में हमने OGS महजोंग 1.0 जारी किया। विकास 1.0 के दौरान, हम अपने गेम को सभी लिनक्स वितरणों पर वितरित करना चाहते थे, साथ ही साथ मैक ओएस एक्स। दुर्भाग्य से, हम सफल नहीं हुए, क्योंकि OGS महजोंग OGRE और OIS का उपयोग करता है।


राक्षस

मैंने OGS महजोंग के लिए 2010 की गर्मियों में OGRE 1.8 की अस्थिर (उस समय) शाखा का उपयोग करना शुरू किया, जब मुझे संसाधनों को फिर से लोड किए बिना गेम विंडो को फिर से बनाने का एहसास हुआ। इसे लागू करने के लिए मेरे बदलावों को उसी गर्मियों में शाखा 1.8 में ले जाया गया था।
मैंने तब सोचा था कि OGRE 1.8 की स्थिर रिलीज़ एक साल में नहीं होगी, ताकि इस समय तक OGS महजोंग 1.0 पहले से ही OGRE के स्थिर संस्करण पर निर्भर रह सके। OGRE 1.8 को 28 मई 2012 को जारी किया गया था।
लेकिन इस समय तक:
1) हमने OIS 1.3 (उस समय उत्तरार्द्ध) की कोशिश की, यह हमारे लिए उपयुक्त नहीं था (नीचे विवरण)।
2) मैंने एक और OGRE फाइल में बदलाव किया (कहानी के लिए: Overlay :: setMaterialName), लेकिन इसे OGRE डेवलपर्स को पास नहीं किया, क्योंकि पहले से ही पता था कि यह छोटा सा बदलाव एक साल में सर्वश्रेष्ठ प्रदर्शन करेगा।

FreeImage

OGRE FreeImage का उपयोग मुख्य छवि कोडेक के रूप में करता है। FreeImage के साथ मुख्य समस्या यह है कि लाइब्रेरी Gentoo वितरण द्वारा समर्थित नहीं है क्योंकि डेवलपर्स zlib, png, आदि सिस्टम लाइब्रेरी का उपयोग कर विरोध करते हैं ... इसके बजाय, वे FreeImage में इन सभी पुस्तकालयों को सांख्यिकीय रूप से शामिल करते हैं।
EDIT : FreeImage को Gentoo, मीडिया-लिबास के साथ शामिल किया गया है। अन्य सभी मुद्दे मान्य हैं।

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

OIS

OIS एक और शायद ही अपडेटेड लाइब्रेरी है। हाल ही में रिलीज़ हुई रिलीज़ 1.3, जिसने हमारे लिए कीस्ट्रोक प्रसंस्करण को पूरी तरह से बर्बाद कर दिया। कीस्ट्रोक लॉजिक को बदल दिया गया है, यही वजह है कि ओजीएस माहजोंग ने लॉन्च के 30 सेकंड बाद कीस्ट्रोक्स को स्वीकार करना बंद कर दिया।
मैंने डेवलपर को इस समस्या के बारे में बताया, लेकिन वह इसे पुन: पेश नहीं कर सका। हमें लिनक्स के लिए संस्करण 1.2 पर रहना था।
OIS 1.3 मिनगॉव के तहत नहीं बनाया गया है, केवल SVN का नवीनतम (उस समय) संस्करण है।
मैक ओएस एक्स के लिए, ओआईएस हमें यहां भी छोड़ दें, क्योंकि जो व्यक्ति मैक ओएस एक्स के लिए महजोंग बनाने में हमारी मदद करने की कोशिश कर रहा था, वह संकलन त्रुटियों के कारण ओआईएस का निर्माण नहीं कर सकता था।
क्योंकि संस्करण 1.3 जारी किया गया है, यह अब सभी लिनक्स वितरणों के साथ आता है, जो तांबे के बेसिन के साथ सभी लिनक्स वितरणों में OGS महजोंग को शामिल करने की हमारी इच्छा को शामिल करता है। अस्वीकार्य।

CEGUI

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

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

OpenSceneGraph

मैंने हाल ही में प्रकाशित दो पुस्तकों के लिए OpenSceneGraph का धन्यवाद किया:
1) ओपनसेनेग्राफ शुरुआती गाइड, 2010।
2) ओपनसेनेग्राफ कुकबॉक्स, 2012।
पहली बार मैं ओपनसेनेग्राफ से मिला जब मैंने 2010 में लाइटफिगर को ओजीआरई में बदल दिया। ओएसजी, एक जटिल पुस्तकालय होने के नाते, मुझे तब अपील नहीं की, क्योंकि मैं बस इसके ट्यूटोरियल को समझ नहीं पाया। सौभाग्य से, इस बार उक्त पुस्तकें बचाव में आईं, जिसमें एक उत्कृष्ट ओएसजी संरचना, बॉक्स से बाहर सामान्य तकनीकों का समर्थन और फ्रीइमेज पर कोई निर्भरता नहीं दिखाई गई। लिनक्स वितरण में भी OSG मौजूद है।
सामान्य तकनीकों के लिए समर्थन बॉक्स से बाहर एक और प्रमुख मुद्दा है जो OGRE के साथ है। यह तर्क दिया जाता है कि OGRE बनावट मानचित्रण (शैडो मैपिंग) का समर्थन करता है, हाँ, लेकिन केवल Cg के साथ। एक और नशा! OGRE के लिए GLSL पर बनावट की छाया पर बस कोई ट्यूटोरियल नहीं था। मैं शायद ही छाया को समझता हूं, मैं एक महीने के लिए बनावट की छाया को लागू करने में सक्षम नहीं था, इसलिए हमें ओजीएस महजोंग 1.0 में स्टैंसिल का उपयोग करना पड़ा।
एक OSG पुस्तक में नरम छाया मानचित्रण के साथ एक उदाहरण था। OSG बॉक्स से बाहर कई छाया रोपण तकनीकों का समर्थन करता है। यहां तक ​​कि एक shader लिखने की कोई जरूरत नहीं है। यह पहले से ही आपके लिए लिखा गया है! स्टैंसिल छाया को नरम वाले में बदलने के लिए, आपको कोड की केवल एक पंक्ति को बदलने की आवश्यकता है।
मैंने OGRE मंचों पर GLSL में छाया के कार्यान्वयन के बारे में पूछा, लेकिन कोई परिणाम नहीं मिला। इसलिए, अगली बार जब आप ओजीआरई मंचों पर पदों की संख्या देखते हैं, तो यह मत सोचो कि वहां सभी सवालों के जवाब दिए गए हैं। जटिल चीजों के लिए, यह बिल्कुल विपरीत है।
OSG का एक और बड़ा फायदा यह है कि मुख्य डेवलपर, रॉबर्ट अभी भी OSG के विकास में सक्रिय रूप से शामिल है और अक्सर मेलिंग सूचियों में सवालों के जवाब देता है (OSG पहले से ही 12 साल पुराना है!)। सिनबाद छोड़ने के बाद ओजीआरई बहुत मृत है।
लिनक्स वितरण में ओएसजी की उपस्थिति फ्रीइमेज जैसी बकवास निर्भरता की कमी के कारण भी है। उदाहरण के लिए, OSG PNG के साथ काम करने के लिए libpng का उपयोग करता है। अंत में, आप 100,500 विभिन्न स्वरूपों का उपयोग नहीं करेंगे, ताकत पर एक या दो।

libRocket

CEGUI का एकमात्र विकल्प। फिलहाल मैं कई ट्यूटोरियल्स से गुज़रा, वे उतने अच्छे और खूबसूरत नहीं थे जितना शायद यह पहली नज़र में लगता है कि libRocket के बाद, लेकिन यह लाइब्रेरी इंटरफ़ेस का वर्णन करने के लिए HTML / CSS के सबसेट का उपयोग करती है (हाँ, HTML / CSS सपोर्ट एक झूठ है)। इस तथ्य ने मुझे GUI करने से मुक्त कर दिया। यदि यह सफल होता है, तो हम libRocket का उपयोग करना जारी रखेंगे। अन्यथा, हम CEGUI पर वापस लौट आएंगे, जहां उस समय तक, मुझे आशा है, डिजाइनरों के लिए CEED लागू किया जाएगा (कुलिक, जारी रखें कि आपने क्या शुरू किया था!)।

अजगर

MJIN2 (हमारा नया गेम इंजन) के लिए पहली आवश्यकताओं में से एक GUI और तर्क के लिए पायथन समर्थन था। बाद में, मैंने अचानक सोचा, क्यों न MJIN2 को C ++ में एक पुस्तकालय बनाया जाए, लेकिन पूरी तरह से पायथन में एक खेल है, न कि केवल तर्क और GUI? यहीं पर SWIG आती है, जो C ++ लाइब्रेरी के लिए पायथन रैपर उत्पन्न कर सकती है।

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

क्योंकि हम Android और iOS का समर्थन करने जा रहे हैं, हम प्रदर्शन सीमाओं के कारण इन प्लेटफार्मों पर पायथन का उपयोग नहीं करेंगे, लेकिन हम खेल के अंतिम संस्करणों को C ++ या Java में लिख पाएंगे, क्योंकि MJIN2 + SWIG आपको खेल को लगभग किसी भी भाषा (C ++ देशी और SWIG का उपयोग करने वाली 20 से अधिक भाषाओं) में लिखने की अनुमति देगा।

हम खेल के विकास के दृष्टिकोण में बहुत कुछ बदल रहे हैं। आइए देखें कि इसमें क्या होगा।