नोएल ललोपिस के खेल भीतर से ब्लॉग ने हाल ही में "रिमोट गेम एडिटिंग" पोस्ट में छुआ । प्रारंभिक पैराग्राफ:
मैं लंबे समय से कम से कम गेम रनटाइम का प्रशंसक रहा हूं। कुछ भी जो ऑफ़लाइन या एक अलग टूल में किया जा सकता है, रनटाइम से बाहर होना चाहिए। यह गेम आर्किटेक्चर और कोड को बहुत दुबला और सरल बनाता है ।
(लेख में नोएल के अधिकांश सामानों के साथ एक उच्च अनुशंसित लेख पढ़ा गया है, चाहे आप 100% सहमत हों या नहीं।)
मेरा मानना है कि यहां कुंजी इंजन के बाहर की जटिलता को बनाए रखना है। आपके पास अभी भी लचीलापन हो सकता है, लेकिन यह सामग्री पाइपलाइन में लचीलापन है। और आप डेटा को चारों ओर परिवर्तित करने और स्थानांतरित करने में समय नहीं लगाकर बेहतर प्रदर्शन प्राप्त करते हैं।
बेहतर प्रदर्शन, कम संपादन समय में तब्दील हो सकता है, अजीब रूप से, इन-इंजन संपादन क्षमताओं में से कुछ को खोने के बावजूद: यदि आप गेम को एक सेकंड में लोड कर सकते हैं तो कुछ प्रयास करना आसान है।
" यूनिक्स दर्शन " के कुछ सिद्धांतों को अपनाने से आपको अपने टूलकिन को लचीला रखने में मदद मिलेगी: एक छोटा मॉड्यूलर पाइप लाइन।
मेरा व्यक्तिगत दर्शन: जितना संभव हो उतने डेटा को ऑफलाइन सेंकना , लेकिन किसी भी समय नया बेक्ड डेटा प्राप्त करने के लिए इंजन का समर्थन प्रदान करना। (ध्यान दें कि इस नए डेटा को एक सुविधाजनक बिंदु तक खेलने में आने की आवश्यकता नहीं है: "ताज़ा करें" बटन दबाया जाता है, अगला स्तर शुरू होता है, आप एक नए क्षेत्र में संक्रमण करते हैं, जो भी हो। कुंजी उस मिठाई स्थान को ढूंढ रही है जो कम से कम हो। न्यूनतम कोड जटिलता और कोडिंग प्रयास के साथ यात्रा का समय।)
हमारी कंपनी में हमारे कलाकार / डिजाइनर-सामना करने वाले अधिकांश उपकरण यूआई मुद्दों पर केंद्रित हैं: एकल संपत्ति या बैचों के हेरफेर में आसानी, आदि। कभी-कभी वे फ़ोटोशॉप या 3 डी मैक्स जैसे केवल 3 पार्टी उपकरण हैं। ये उपकरण एक मध्यवर्ती प्रारूप में निर्यात होते हैं (अक्सर xml जो स्रोत बाइनरी डेटा को संदर्भित करता है, लेकिन हमेशा नहीं)। मध्यवर्ती प्रारूप को बैकएंड "डेटा मेक" टूल द्वारा उठाया जाता है, जो इसे लक्ष्य प्लेटफॉर्म के लिए कुछ उपयोगी और त्वरित-लोडिंग में बनाता है।
पोर्टेबिलिटी अतिरिक्त बैकेंड डेटा मेक टूल जोड़कर हासिल की जाती है, या मौजूदा बैकेंड डेटा मेक टूल का विस्तार किया जाता है, जिसमें सामग्री रचनाकारों के लिए अदृश्य होने का अतिरिक्त लाभ होता है।
अब, एक उचित वृद्धिशील डेटा बनाने के साथ, आप सेकंड के भीतर बेक्ड प्रारूप में परिवर्तन कर सकते हैं; आपका इंजन मकड़ी कर सकता है, या एक उपकरण मकड़ी कर सकता है, और फिर ये आपके संसाधन प्रणाली में दिखाई देंगे, सुविधाजनक होने पर पुनः लोड के लिए तैयार हैं।
उपकरण - विशेष रूप से बैकेंड डेटा उपकरण बनाते हैं - अक्सर इंजन कोड की तुलना में ढलान और बगियर होते हैं। यह ठीक है, क्योंकि वे रिफलेक्टर / पुनः लिखना, विस्तार करना और परीक्षण करना आसान कर रहे हैं; आपके पास उनके व्यवहार के लिए चश्मा है और कुछ इंजन कोड की तुलना में यूनिट परीक्षण करना काफी आसान है।
आपके सवालों पर मेरी राय:
क्या इंजन को विभिन्न छवि प्रारूपों को लोड करने में सक्षम होना चाहिए? एक TGA केवल लोडर हाथ कोड के लिए बहुत आसान है।
(इसके अलावा: यदि आप TGA डिकोडर-इंजन का उपयोग करते हैं, तो भी इसे नियंत्रित न करें। आप बस परेशानी पूछ रहे हैं - अधिकांश छवि प्रारूपों के साथ बहुत सारी सूक्ष्मताएं हैं, और बहुत सारे उपकरण हैं जो पालन नहीं करते हैं। संभवत: अंडरस्क्राइब किए गए प्रारूप के बिल्कुल विपरीत। आप इमेज प्रोसेसिंग के लिए मौजूदा अच्छी तरह से परीक्षण किए गए लाइब्रेरी कोड को ढूंढना सबसे अच्छा है।)
मैं उपकरण यहाँ TGA से कन्वर्ट करने के लिए जो भी अपने आंतरिक बनावट प्रारूप है, प्लस मेटाडेटा है।
ऑडियो प्रारूपों के बारे में क्या? क्या केवल लोडिंग wav फ़ाइलों का समर्थन करना संभव है? परिवेश संगीत फ़ाइलों के बारे में क्या जो अक्सर विशाल होते हैं।
हम यहां तीन स्वरूपों का उपयोग करते हैं: ट्रैक किए गए संगीत (.xm), ADPCM (.wav), और Speex (.spx)। यह ज्यादातर इसलिए है क्योंकि हम हैंडहेल्ड पर हैं, और ये प्रारूप डिकोड करने के लिए बहुत हल्के हैं।
क्या इंजन गतिशील टीटीएफ पार्सिंग और एटलस जेनरेशन के लिए सक्षम होना चाहिए? बनावट पैकिंग।
एटलसिंग एक कठिन समस्या है: अपने हाल के प्रश्न के उत्तर देखें। यह लगभग हमेशा ऑफ़लाइन करने के लायक है।
साथ ही आप प्रति-चरित्र मेटाडेटा को लगभग शून्य-लोड-कोड-बेक्ड संरचना में बना सकते हैं।
समापन में, आप अपने समुदाय के लिए, मॉड समुदाय के लिए इस पाइपलाइन को साफ और पैकेज कर सकते हैं। आप हमेशा अधिक स्रोत प्रारूप जोड़ सकते हैं। और विशिष्ट मामलों में सामग्री निर्माण उपकरण और इंजन के बीच की खाई को पाटने से आपको रोकने के लिए कुछ भी नहीं है; उम्मीद है कि आपका डेटा बेकिंग कोड और स्पाइडर / ट्रांसफर कोड पुस्तकालयों में वापस लाया जा सकता है जो अंततः कुछ मामलों में सामग्री निर्माता टूल द्वारा सीधे उपयोग किया जा सकता है। लेकिन मैं यह नहीं कहूंगा कि मेरा पहला लक्ष्य, जरूरी है ... बस इस बात का ध्यान रखें कि यह एक अंतिम लक्ष्य होगा और अपने डिजाइन को थोड़ा प्रभावित करें, और सबसे पहले कम लटके फलों के लिए जाएं।
अद्यतन के रूप में, आप बनावट के लिए KTX फ़ाइल प्रारूप का उपयोग करने पर विचार कर सकते हैं । यह structसबसे अधिक GL usecases के लिए ज्यादातर "पढ़ा जाना और जाना" होने का लाभ है (और आपकी टिप्पणियों से ऐसा लगता है जैसे आप GL को लक्षित कर रहे थे) जबकि अभी भी लचीला और अच्छी तरह से परिभाषित किया जा रहा है।
KTX हेडर ओवरहेड आपके लक्ष्य के आधार पर पूरी तरह से बेक्ड डेटा के लिए थोड़ा अधिक हो सकता है, और आप अपने usecase के आधार पर एंडियन स्वैप सपोर्ट को छोड़ना चाह सकते हैं ... लेकिन यह निश्चित रूप से कम से कम डिज़ाइन विचार के लिए एक गण्डर के लायक है।