एसेट्स प्रबंधन, डेटाबेस या संस्करण प्रणाली?

Question

खेल के लिए संपत्ति विकसित करते समय, (जाल, बनावट, आवाज़, वीडियो) हो क्या आप उन्हें प्रबंधित करते हैं?

1. उन्हें वर्जनिंग सिस्टम के अंदर सोर्स कोड के साथ रखते हैं? (लागू, git, आदि…)
2. या एक केंद्रीय बैक-अप्ड होने के बाद, डेटाबेस संपत्ति के लिए समर्पित है और संपादकों को हमेशा यह पसंद है? (PostgreSQL, MySQL, आदि…)
3. अन्य?

प्रत्येक के समर्थक और विपक्ष क्या हैं, और क्यों एक को दूसरे के ऊपर चुनना चाहिए?

Comments

अच्छा प्रश्न। मैं यह सुनने में बहुत दिलचस्पी रखता हूं कि अन्य लोग कैसे दृष्टिकोण रखते हैं।

— डेविड मैक्ग्रा

संस्करण नियंत्रण के बारे में जानकारी के लिए: gamedev.stackexchange.com/questions/480/… और gamedev.stackexchange.com/questions/245/… मुझे नहीं लगता कि यह एक डुप्लिकेट है क्योंकि यह विशेष रूप से संपत्ति के बारे में है

— शॉन जेम्स

Answer 1

हम में से कई के लिए - विशेष रूप से छोटे खेलों पर काम कर रहे हैं - आपके पास स्रोत के रूप में उसी भंडार में संपत्ति होनी चाहिए ।

यह सुझाव कि संपत्ति एक अलग भंडार में है, केवल संपत्ति के बहुत बड़े सेट के लिए, या कुछ हद तक संपत्ति के बड़े सेट के लिए समझ में आता है जब एक स्पष्ट रूप से परिभाषित इंजन / डेटा सीमा होती है। जब तक इसके लिए कोई विशेष तकनीकी कारण नहीं है - यह खराब सलाह है!

आप चाहते हैं कि आपका संस्करण नियंत्रण संस्करण नियंत्रण की तरह व्यवहार करे । आप रिवाइंड और फ़ास्ट-फ़ॉरवर्ड और ब्रांच को रिवाइज़ और मर्ज करने में सक्षम होना चाहते हैं और फिर भी आपका गेम काम कर रहा है। और आपका कोड और संपत्ति एक-दूसरे पर निर्भर होंगे ।

उदाहरण के लिए: आपका कोड किसी shader पर एक पैरामीटर सेट करने में सक्षम होने की उम्मीद कर सकता है, और यह shader एक बनावट पर निर्भर हो सकता है। या हो सकता है कि आपके स्तर का डेटा प्रारूप आपके गेम कोड के किसी विशेष संस्करण पर निर्भर हो।

यह लगभग निश्चित रूप से गड़बड़ हो जाएगा। और आपके पास कोशिश करने और उसे ठीक रखने की तुलना में बेहतर चीजें हैं।

---

अब, जैसा कि माइक वैगनर ने ( इस जवाब पर ) टिप्पणी की - आपको संस्करण नियंत्रण के लिए अपनी संपत्ति के सभी "प्रगति पर" संस्करणों की आवश्यकता नहीं है या नहीं चाहिए! बस अंतिम / कार्यशील संस्करण, जैसा कि आपके कोड द्वारा उपयोग किया जाता है, करेगा - अक्सर यह वही होता है जो आप अपने उपकरण से निर्यात करते हैं।

(यद्यपि यदि आप परिसंपत्तियों की प्रगति के संस्करणों को नियंत्रित करना चाहते हैं - तो यह ठीक है। और एक अलग भंडार के अनुकूल है। मैं व्यक्तिगत रूप से उस अच्छे फ़ोल्डर संगठन और एक उचित बैकअप प्रणाली का पता लगाता हूं।)

कहा जा रहा है - यह कभी-कभी संस्करण नियंत्रण के तहत "प्रगति" संपत्ति में छड़ी करने का विकल्प होता है। आमतौर पर इसमें एक सामग्री पाइपलाइन शामिल होती है जो आपके लिए किसी भी 'निर्यात' चरण को संभाल सकती है - उदाहरण के लिए: एकल बनावट के लिए एक बहु-परत छवि को समतल करना।

Answer 2

वर्जनिंग सिस्टम।

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

संपत्ति को स्रोत से अलग रिपॉजिटरी में रखें, चेकआउट / सिंक समय को न्यूनतम रखने के लिए आसान बनाने के लिए और अलग-अलग निर्णय लेने के लिए कि कितना इतिहास बनाए रखना है (हालांकि डिस्क स्थान सस्ता है, जब भी संभव हो, यह सब बनाए रखें। व्यक्तिगत बनावट डॉन। 'एक परियोजना के जीवन पर इतना परिवर्तन नहीं)।

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

यदि आप कर सकते हैं, तो प्रत्येक वाक्य पर एक सिंटैक्स चेक या यहां तक ​​कि परिसंपत्ति निर्माण की व्यवस्था करें और असफल होने पर उस व्यक्ति को वापस ईमेल के साथ प्रतिबद्ध को अस्वीकार करें; इससे टीम के समय की एक बड़ी बचत होगी।

Comments

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

— केसी वैगनर

XML फ़ाइलों को बाइनरी के रूप में चिह्नित करने पर: यदि आपका वीसीएस अलग-अलग उपकरण की अनुमति देता है, तो इसे कुछ ऐसी चीज़ों का उपयोग करने के लिए कहें जो एक्सएमएल फ़ाइलों के लिए एक्सएमएल फ़र्क में माहिर हैं। यह अजीब टूटे हुए मार्कअप से बचने में मदद कर सकता है।

— जेफ

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

— जैकोमो

Answer 3

एक भंडार में सब कुछ, यदि आप इसे आकार के संदर्भ में खरीद सकते हैं। मैंने 1 टीबी के आसपास के क्षेत्र में सबवर्सन रिपॉजिटरी के बारे में सुना है। वर्तमान में हम 400 जीबी से थोड़ा नीचे हैं।

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

Comments

"बस कारक" का उल्लेख करने के लिए

— अपवोट