Numivo की सबसे महत्वपूर्ण विशेषता अदृश्य है: आपके रिलीज़ किए गए गेम में इसका कुछ भी नहीं होता। बॉक्स का हर टूल (स्कैटर, मेश ब्लेंडिंग, ग्रिड) केवल साधारण इंजन एसेट बनाता है, और कुछ नहीं। यह पोस्ट बताती है कि तकनीकी रूप से इसका क्या अर्थ है, और हम इसे गैर-परक्राम्य क्यों मानते हैं।
"नेटिव" का ठोस अर्थ क्या है
जब आप Unreal में कोई स्कैटर पास बेक करते हैं, तो Numivo Hierarchical Instanced Static Mesh कॉम्पोनेंट या फ़ोलिएज इंस्टेंस लिखता है: वही संरचनाएँ जो आपको चीज़ें हाथ से रखने पर मिलतीं। Unity में, ये मानक prefab इंस्टेंस या टेरेन डिटेल होते हैं। मेश ब्लेंडिंग की मटीरियल पिक्सेल-परफ़ेक्ट नॉर्मल ट्रांज़िशन के साथ सामान्य इंजन मटीरियल में कंपाइल होती हैं; कोई कस्टम शेडर पास नहीं, कोई प्रति-फ़्रेम प्लगइन काम नहीं, आपकी Build.cs या पैकेज मैनिफ़ेस्ट में कोई "Numivo रनटाइम" मॉड्यूल नहीं।
इससे निकलने वाले आँकड़े:
- आपके बिल्ड में Numivo कोड की 0 पंक्तियाँ
- 0 ms अतिरिक्त फ़्रेम समय: निष्पादित करने के लिए कुछ है ही नहीं
- सामान्य दृश्यों में < 150 MB एडिटर RAM, क्योंकि एडिटर टूलिंग ही पूरा फ़ुटप्रिंट है
- Unreal और Unity में साझा 1 कोर, इसलिए प्रीसेट इंजनों के बीच आते-जाते हैं
हम रनटाइम निर्भरता से इनकार क्यों करते हैं
रनटाइम निर्भरताएँ एक कर्ज़ हैं जिसे किसी और को चुकाना पड़ता है:
- प्रमाणन (certification)। कंसोल प्रमाणन टीमें पूछती हैं कि हर तृतीय-पक्ष मॉड्यूल क्या करता है। "कोई है ही नहीं" सबसे छोटा संभव उत्तर है।
- दीर्घायु। गेम टूल सब्सक्रिप्शन से अधिक जीते हैं। चूँकि बेक किए गए परिणाम साधारण एसेट हैं, Numivo से बनाया गया दृश्य दस साल बाद भी खुलता और रिलीज़ होता है: चाहे हम रहें या न रहें। यदि आप रद्द करते हैं, तो जो कुछ आपने बनाया वह सब आपके पास रहता है: यह हमारी शर्तों का वादा नहीं, बल्कि आर्किटेक्चर का गुण है।
- प्रदर्शन का स्वामित्व। आपका प्रोफ़ाइलर वे इंजन प्रिमिटिव दिखाता है जिन्हें अनुकूलित करना आप पहले से जानते हैं (कल दूरियाँ, LOD, Nanite सेटिंग्स) कोई ब्लैक बॉक्स नहीं।
आपकी रिपॉज़िटरी के लिए इसका क्या अर्थ है
बेक किए गए परिणाम किसी भी अन्य एसेट की तरह वर्ज़न होते हैं: वे diff होते हैं, मर्ज होते हैं, रिव्यू होते हैं। Numivo के स्पीशीज़ और ग्रिड प्रीसेट छोटी सादी फ़ाइलें हैं जिन्हें आप commit कर और टीम के साथ साझा कर सकते हैं। एकमात्र चीज़ जो वर्ज़न कंट्रोल में नहीं जानी चाहिए वह है लोकल कंटेंट-इंडेक्स कैश (यह स्वयं फिर से बन जाता है); एक ignore नियम और काम पूरा।
समझौता, ईमानदारी से कहा जाए तो
गैर-विनाशकारी प्रक्रियात्मक संपादन के लिए प्लगइन चाहिए: एक बार बेक होने पर, एक पहाड़ी इंजन का डेटा बन जाती है, और उसे प्रक्रियात्मक रूप से फिर संपादित करने का अर्थ है उसे Numivo से फिर खोलना। हमें लगता है यही सही समझौता है: दूसरा विकल्प (दृश्यों को रनटाइम परत पर निर्भर रखना) चुपचाप आपके प्रोजेक्ट को बंधक बना लेता है। आपके लेवल आपके गेम के होने चाहिए, आपके टूल के नहीं।
यदि यह दर्शन आपकी टीम के काम करने के तरीके से मेल खाता है, तो फ़्री टियर इसे जाँचने का सबसे आसान तरीका है: कुछ स्कैटर करें, उसे बेक करें, प्लगइन हटा दें, और देखें कि दृश्य को कोई फ़र्क नहीं पड़ता।