गेम स्टेट (प्रोफाइल) को बचाने के लिए सबसे अधिक उपयोग की जाने वाली विधि या एल्गोरिथ्म क्या है, डेटाबेस टेक्स्ट फाइलें कैसे एन्क्रिप्शन जाती हैं और संबंधित चीजें।
मैंने देखा है सीज़र IV ने mySQL का उपयोग किया है।
कोई सुझाव।
गेम स्टेट (प्रोफाइल) को बचाने के लिए सबसे अधिक उपयोग की जाने वाली विधि या एल्गोरिथ्म क्या है, डेटाबेस टेक्स्ट फाइलें कैसे एन्क्रिप्शन जाती हैं और संबंधित चीजें।
मैंने देखा है सीज़र IV ने mySQL का उपयोग किया है।
कोई सुझाव।
जवाबों:
मुझे पूरा यकीन है कि यह सबसे अधिक बार एक मालिकाना (बाइनरी) प्रारूप में किया जाता है, बस जो भी गेम स्टेट स्ट्रक्चर से आप एक फाइल में उपयोग करते हैं, या उस फाइल को स्ट्रक्चर के एक इंस्टेंस में वापस पढ़ते हैं। C ++ में उदाहरण के लिए आप किसी ऑब्जेक्ट को बाइट्स के एक सरणी की तरह व्यवहार कर सकते हैं और बस फ़ाइल में इसे फिर से लिखना (या फ़ाइल से फ़्रेड) (और) अपने ऑब्जेक्ट फॉर्म में वापस डाल सकते हैं।
यदि आप जावा या किसी अन्य भाषा का उपयोग कर रहे हैं, तो आप कार्य को वास्तव में आसान बनाने के लिए क्रमांकन का उपयोग करने का विकल्प चुन सकते हैं । जावा स्पष्टीकरण इस उत्तर के निचले भाग में है; अन्य भाषाएं (C ++ की तुलना में उच्चतर) के पास निश्चित रूप से अपने स्वयं के क्रमांकन पुस्तकालय या अंतर्निहित कार्य हैं, जिन्हें आपको उपयोग करने का विकल्प चुनना चाहिए। कोई फर्क नहीं पड़ता कि कैसे क्रमिक दिनचर्या नियमित हो सकती है, आजकल हार्ड ड्राइव स्थान सस्ता है, खासकर जब खेल राज्य बहुत बड़ा नहीं होना चाहिए, और यह आपको लिखने और अपनी खुद की क्रमबद्ध दिनचर्या को बनाए रखने से रोकता है ।
आपको MySQL का उपयोग बिल्कुल नहीं करना चाहिए (बस इस समीक्षा का पहला वाक्य पढ़ें )। यदि आपको वास्तव में किसी कारण के लिए रिलेशनल डेटाबेस की आवश्यकता है , तो SQLite का उपयोग करें ; यह एक हल्का डेटाबेस सिस्टम है और एकल डेटाबेस फाइल में मौजूद है। लेकिन ज्यादातर खेलों के लिए, रिलेशनल डेटाबेस जाने का तरीका नहीं है, और जो कंपनियां उनका उपयोग करने की कोशिश करती हैं, वे आमतौर पर एक सच्चे रिलेशनल डेटाबेस के बजाय एक कुंजी-मूल्य लुकअप तालिका के रूप में उपयोग करते हैं।
स्थानीय डिस्क फ़ाइलों के एन्क्रिप्शन का कोई भी प्रकार केवल मोटापा है ; कोई भी हैकर आपके कार्यक्रम को ठीक करने के तुरंत बाद डेटा को सूँघ लेगा। मैं व्यक्तिगत रूप से उस तरह की चीज के खिलाफ हूं, ESPECIALLY एक खिलाड़ी के खेल के साथ। मेरा विचार है कि यदि वे चाहें तो खेल के मालिकों (ग्राहकों, मन को आप को भुगतान करना) को खेल में हैक करने की अनुमति दी जानी चाहिए। कुछ मामलों में यह समुदाय की अधिक समझ पैदा कर सकता है, और आपके गेम के लिए "मॉड्स" विकसित किया जा सकता है जो आपके लिए अधिक ग्राहक चलाते हैं। सबसे हालिया उदाहरण जो दिमाग में आता है वह Minecraft मॉड में पोर्टल है जिसे हाल ही में जारी किया गया था। यह पूरे इंटरनेट पर गेमर समाचार साइटों में प्रकाशित हुआ है, और आप इसे Minecraft की बिक्री को बढ़ा सकते हैं।
अगर किसी कारण से आप वास्तव में खेल के विकास के लिए जावा का उपयोग करने के लिए पर्याप्त रूप से पागल हैं, तो मैं यहां जावा में क्रमबद्धता का एक त्वरित विवरण प्रस्तुत करता हूं:
अपने सभी गेम स्टेट डेटा को एक कक्षा में रखें
Serializable, लागू करके कक्षा को क्रमबद्ध बनाएं ,transientयदि आप विशेष त्वरित संस्करण को वर्ग में मिलाते हैं तो कीवर्ड का उपयोग करें (क्षणिक वस्तुएं अनुक्रमित नहीं हैं), और बसObjectOutputStreamफ़ाइल से लिखने और फ़ाइलObjectInputStreamसे पढ़ने के लिए उपयोग करें । बस।
[field: NonSerialized]
यदि आप अपना कोड लिख रहे हैं, तो C ++ में कहें, आप बाइनरी फ़ाइलों का उपयोग कर सकते हैं । द्विआधारी फाइलें आपको ओफ़्फ़्यूशन के माध्यम से एन्क्रिप्शन का एक रूप देती हैं। लेकिन जैसा कि सभी इंटर्नेट्स में प्रलेखित है, यह सुरक्षा का बहुत कमजोर रूप है।
या, यदि आप मानव पठनीय समाधान चाहते हैं तो आप रैपिडएक्सएमएल जैसी किसी चीज़ का उपयोग कर सकते हैं।
यदि आप किसी प्रकार की रूपरेखा का उपयोग कर रहे हैं, तो इसे फ़ाइल समर्थन कार्यों में देखें। HTH
अधिकांश गेम जो मैंने देखे हैं, वे बाइनरी फाइलों को पढ़ने / लिखने के लिए सिर्फ हाथ से लिखे गए कोड का उपयोग करते हैं। अक्सर डिस्क प्रारूप पर किसी ऑब्जेक्ट की मेमोरी लेआउट की एक सटीक प्रतिकृति होगी ताकि लोड हो रहा है:
यह तेज़ है, लेकिन यह मंच-विशिष्ट, और अनम्य बनाए रखने के लिए एक घर का काम है।
हाल ही में, मैंने देखा है कि कुछ गेम SQLite का उपयोग करते हैं। जिन लोगों से मैंने बात की है, वे इसे पसंद करते हैं।
कुछ अन्य उत्तरों में सीरियललाइज़ेशन का उल्लेख किया गया है, और मैं मानता हूं कि यह एक उचित समाधान है। एक तरह से यह विफल रहता है, हालांकि संस्करण में है।
कहते हैं कि आप अपना गेम जारी करते हैं और लोग इसे खेलते हैं और कुछ गेम बचाते हैं। फिर बाद के पैच में आप एक बग को ठीक करना चाहते हैं या कुछ विशेषताएं जोड़ सकते हैं। यदि आप एक सरल बाइनरी क्रमांकन पद्धति का उपयोग करते हैं और आप अपनी कक्षाओं में एक सदस्य जोड़ते हैं तो आपके क्रमांकन पुराने सहेजे गए गेम के साथ संगत नहीं हो सकते हैं जब ग्राहक आपके पैच को स्थापित करते हैं।
आप जो भी दृष्टिकोण का उपयोग करते हैं, खेल को पहली बार जारी करने से पहले सुनिश्चित करें कि आप इस मुद्दे पर सोचते हैं! पैच अप्लाई करने के बाद शुरू होने पर ग्राहकों को खुशी नहीं होगी।
इससे बचने का एक तरीका यह है कि प्रत्येक बेसिक डेटा टाइप में सेव (वर्जन) और लोड (वर्जन) तरीके हों, जो यह जानने के लिए पर्याप्त स्मार्ट हों कि गेम के प्रत्येक वर्जन के लिए कौन सा डेटा सेव और लोड करना है। इस तरह से आप अपने सहेजे गए गेम की बैकवर्ड संगतता का समर्थन कर सकते हैं और यदि उपयोगकर्ता चल रहे हैं तो गेम के नए संस्करण से किसी गेम को सहेजने का प्रयास करने पर शालीनतापूर्वक असफल हो जाते हैं।
यदि आप उसी प्रारूप का उपयोग कर सकते हैं जिसका उपयोग आप अपने स्तरों को स्टोर करने के लिए करते हैं, तो यह एक बोनस है।
उदाहरण के लिए, Peggle जैसे गेम में प्रारंभिक बोर्ड लेआउट, गेंदों की संख्या, वर्तमान स्कोर (प्रारंभिक बोर्ड के लिए 0) आदि हो सकते हैं, फिर एक सहेजा गया खेल बिल्कुल उसी प्रारूप का उपयोग कर सकता है।
यदि आप एक ही प्रारूप का उपयोग करते हैं तो सेव गेम और लेवल लोड आपके काम को आसान बनाने वाले कोड को साझा कर सकते हैं!
वास्तव में बड़ी मैप फ़ाइलों वाली गेम के लिए, सेव गेम को मैप फाइल को संदर्भ में शामिल किया जा सकता है। प्रारंभिक स्तर की फाइलें वही काम कर सकती हैं, यहां तक कि, जो उस नक्शे पर वापस आना आसान बनाती है, भले ही किसी कारण से कहानी में चरित्र उसी स्थान पर वापस आ गया हो, सिवाय कुछ एनपीसी के मृत हैं और सभी मृत शरीर पड़े हुए हैं ऊपर।