गेम डेटा की बचत के लिए एक अच्छा फ़ाइल प्रारूप क्या है? [बन्द है]


37

मुझे कुछ कस्टम गेम डेटा सहेजने की आवश्यकता है। नक्शा, खिलाड़ी, आदि।

उन सभी में "उप वस्तुएं" होंगी। उदाहरण के लिए, एक नक्शे और नक्शे में टाइलों की एक "सरणी" होगी। यानी, पदानुक्रमित डेटा। उम्मीद है कि कुछ भी नहीं बाइनरी।

इनके लिए एक अच्छा प्रारूप क्या होगा?

अब तक माना जाता है:

सेरीलाइज़ेशन: यह तेज़ और आसान है, लेकिन जब मैं अंतर्निहित कक्षाएं बदलता हूं तो टूट जाता है :(

XML: मैं वास्तव में इस पार्सिंग से नफरत करता हूं। मेरे परीक्षण का मामला कोड की 100+ पंक्तियों से अधिक था और ऐसा लगता है कि बहुत सरल प्रारूप के लिए "व्यस्त काम" के टन पसंद करते हैं।

INI: श्रेणीबद्ध डेटा के लिए वास्तव में अनाड़ी होगा।

प्रोटोबॉफ़: कभी भी इसका उपयोग नहीं किया है, लेकिन पढ़ा है कि यदि आप कक्षा बदलते हैं, तो आपको बहुत सारे मैनुअल मैकिंग करना पड़ता है और टूट जाता है।

अन्य विकल्प? इसलिए मैं यहां हूँ!

संपादित करें: यह जावा btw है।

2 संपादित करें:

मैं "नियंत्रित बाइनरी सीरियलाइज़ेशन" (नीचे देखें) पर बस गया।

पेशेवरों:

  • ये तेज़ है

  • यह छोटा है (डिस्क पर) और पढ़ने / लिखने के दौरान आसानी से संपीड़ित / विघटित हो सकता है।

  • गेम और टूलसेट से पढ़ना / लिखना बेहद आसान है।

  • मैं तय कर सकता हूं कि वस्तु को क्या शामिल / बहिष्कृत करना है।

  • ऑब्जेक्ट / डेटा को नेस्टेड किया जा सकता है।

विपक्ष:

  • इसे हाथ से संपादित नहीं कर सकते (जैसे XML, YAML, आदि)

  • इसे आसानी से स्क्रिप्ट के साथ पढ़ा / संशोधित नहीं किया जा सकता है

  • डिफ़ॉल्ट रूप से जावा सीरियलाइज़ेशन अन्य अनुमानों की तुलना में बहुत धीमा / फूला हुआ है, लेकिन यह स्थिर और काम करता है


3
अल्पविराम से अलग किए गए मान
थॉमस ईडिंग

@trinithis KISS एक बड़ी बात है।
नैट

3
CSV पार्सिंग को सोचकर फंसना
Tetrad

अपग्रेडबिलिटी का समर्थन करने के लिए मजेदार, प्रोटोब्यू बनाया गया।
जोनाथन डिकिन्सन

सब कुछ उपयोगकर्ता-परिवर्तनीय जैसे सेटिंग्स, आदि के लिए; और सब कुछ के लिए द्विआधारी।
उयुर गुम्मशान

जवाबों:


38

पदानुक्रमित डेटा प्रदर्शित करने के लिए, YAML या JSON अच्छे विकल्प होंगे। वे XML की तुलना में कहीं अधिक सरल और सरल हैं ।

एक अन्य विकल्प एक "नियंत्रित" बाइनरी क्रमांकन प्रक्रिया होगी। प्रत्येक वस्तु लिखती है कि यह नियंत्रित तरीके से है, अर्थात

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

आईडी टेक 4 (क्वेक 4 / डूम 3 इंजन) इस तरह के दृष्टिकोण का उपयोग करता है।


+1 "नियंत्रित" द्विआधारी क्रमांकन के लिए। मैं काम पर इस का उपयोग करें और यह बहुत अच्छा है!
NoobsArePeople2 19

1
"नियंत्रित" बाइनरी क्रमांकन के लिए एक और +1। जबकि मैंने पहले कभी नाम नहीं सुना था, मैं कुछ स्थानों पर ऐसा ही करता हूं - सही किया, इसमें नए जोड़े गए फ़ील्ड के लिए चूक सेट करने में सक्षम होने का लाभ है जो डेटा फ़ाइल में मौजूद नहीं है, और अनदेखा करने के लिए " रद्दी "डेटा फ़ाइल में जब एक फ़ील्ड को मॉडल से हटा दिया जाता है।
इजाकाटा

मैं अपने खेल में कुछ इस तरह का उपयोग करता हूं। यह अच्छा काम करता है! मैं जावा का उपयोग करता हूं। प्रत्येक ऑब्जेक्ट में एक ToByteStream विधि होती है जो एक फाइल स्ट्रीम और एक कंस्ट्रक्टर को लिखती है जो एक फाइल स्ट्रीम से पढ़ता है। मुझे जावस सीरियल का कार्यान्वयन पसंद नहीं आया।
माइकल हाउज़ '

4
या आप बस Boost.Serialize का उपयोग कर सकते हैं और संस्करण और इसके बाद जैसी अद्भुत विशेषताएं प्राप्त कर सकते हैं।
निकोल बोलस

@ इज़काटा मैंने वह नाम बना दिया है क्योंकि मुझे नहीं पता कि इस पद्धति को कैसे कहा जाता है।
राफेल आर।

9

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

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

इन समस्याओं को पहचानें, अपने प्रारूप को उन लोगों के साथ डिजाइन करें, और आप एक शानदार बाइनरी प्रारूप बना सकते हैं।

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


6

फ़ाइल स्वरूप की आपकी पसंद आपके वर्तमान टूलसेट और उस गेम पर निर्भर करती है जिसे आप बनाना चाहते हैं। उस के साथ कहा...

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

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

खेल। आप किस तरह का खेल बना रहे हैं? मैं क्यों कहता हूं कि यह फ़ाइल प्रारूप को प्रभावित करेगा? क्योंकि, यदि आप 2D बॉम्बरमैन की तरह कुछ बना रहे हैं, तो आप एक साधारण टेक्स्ट फ़ाइल के साथ भाग सकते हैं:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

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

  • मैप्स, कण और अन्य ग्राफिकल सामान एक कस्टम बाइनरी प्रारूप का उपयोग करते हैं। क्योंकि इसे लागू करने का सबसे सरल तरीका है । नक्शों का वर्णन करना मानवीय रूप से समझदारी नहीं है। आमतौर पर मानचित्र / स्तर / कण संपादकों के माध्यम से संपादित किया जाता है।
  • खिलाड़ी, आइटम, दुश्मन, कौशल और quests ऐसे आँकड़े हैं जो खेल संतुलन को प्रभावित करते हैं । उन्हें आमतौर पर बहुत सारे और बहुत सारे इनपुट और ट्विकिंग की आवश्यकता होती है। मैं इसे आसानी से कार्यान्वयन के लिए XML फ़ाइल में डालकर करना पसंद करता हूं, लेकिन अभी तक डिजाइनरों के साथ खेलने के लिए ऑब्जेक्ट संपादक नहीं है। दोनों दुनिया के सर्वश्रेष्ठ

आम तौर पर, आप टेक्स्ट को टेक्स्ट फॉर्मेट और ग्राफिक्स को बाइनरी फॉर्मेट के साथ वर्णन करना चाहते हैं। निम्नलिखित आपको एक उदाहरण देना चाहिए:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

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

चीयर्स, रॉय =)


5

BSON बहुत अच्छा है। http://bsonspec.org/ । तब JSON को पार्स करना आसान होता है और बाइनरी डेटा से बेहतर होता है, लेकिन फिर भी एक अच्छी संरचना होती है। यह प्रोटोकॉल बफ़र्स के समान है। नकारात्मक पक्ष यह है कि डोंगेंट मोंगोडब के बाहर इसके लिए बहुत सारे उपकरण का समर्थन करता है।

संपादित करें: MsgPack ( http://msgpack.org/ ) भी BSON के समान है और अधिक कर्षण प्राप्त कर रहा है।


1
जबकि मुझे लगता है कि "बाइनरी JSON" का विचार अच्छा है, मुझे BSON में बहुत कम विश्वास है, बहुत अधिक (निरर्थक) डेटा प्रकार हैं, और प्रलेखन बेकार है।
आआआआआआआआ आआआआआ आआआआआ

2

आपके कस्टम बाइनरी डेटा प्रारूप का क्या हुआ है? यदि आप कच्चे क्रम से डरते हैं, तो अपनी स्वयं की प्रणाली लिखें जो फ़ील्ड को आवश्यकतानुसार लिखती है, और उन्हें वापस पढ़ती है। एक्सएमएल की कोई आवश्यकता नहीं है, जो उन स्थितियों के लिए वास्तव में भारी और जटिल है, जहां आपको प्रारूप प्रदान करने वाली पारदर्शिता की आवश्यकता नहीं है। बस एक अच्छी तरह से निर्दिष्ट फ़ाइल प्रारूप को परिभाषित करें और इसे छड़ी करें, संभवतः प्रत्येक रिकॉर्ड में अपने डेटा सेट के विस्तार के लिए कुछ कमरे को शून्य मानों के साथ उन्हें पेडिंग करके (कहते हैं कि आपके पास अब 100 बाइट रिकॉर्ड है, भविष्य के उपयोग के लिए 150 तक पैड।
एक संस्करण संख्या और शायद एक चेकसम जोड़ें ताकि आप जान सकें कि किन क्षेत्रों को भरा जाना चाहिए और वैधता के लिए एक पवित्रता की जांच होनी चाहिए, और आप जाने के लिए अच्छे हैं।


1

आप XML या कुछ अन्य प्रारूप को बेस64 सम्मिलन के साथ कुछ विशिष्ट डेटा के लिए मिला सकते हैं, और उन क्षेत्रों के लिए जिन्हें आपको पठनीयता की आवश्यकता है, आप सामान्य पाठ का उपयोग कर सकते हैं

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