खेलों में एन्क्रिप्टेड सामग्री


45

मुझे प्रोग्राम के बाहर ही अपने प्रोग्राम में कंटेंट का पता लगाने से रोकने के लिए एन्क्रिप्शन का उपयोग करने का यह विचार रहा है। यूजर्स को ऐसा लग सकता है कि गेम में कभी भी इस्तेमाल किए गए टेक्सचर का इस्तेमाल गेम के डेटा के दौरान किसी तरह के ईस्टर एग का हिस्सा नहीं होगा। अगर यह ऑनलाइन पोस्ट किया गया है तो यह हर किसी के लिए इसे बर्बाद कर सकता है।

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

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

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

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

संपादित करें : यह स्पष्ट नहीं हो सकता है कि मैं क्या कह रहा हूं, इसलिए यहां एक अधिक ठोस उदाहरण है।

मान लीजिए कि मेरे पास एक फ़ंक्शन है जो 20 वर्णों की स्ट्रिंग में लेता है और एक सममित कुंजी बनाता है जिसका उपयोग मैं खेल में कुछ सामग्री को एन्क्रिप्ट / डिक्रिप्ट करने के लिए कर सकता हूं। उपयोगकर्ता को उस सामग्री को प्राप्त करने का एकमात्र तरीका उन 20 वर्णों को जानना और उसी कुंजी को उत्पन्न करना है। यह कुंजी कभी भी सीधे संग्रहीत नहीं होती है और उपयोगकर्ता इनपुट के आधार पर मक्खी पर उत्पन्न होती है। इन पात्रों को खेल में छिपाया जा सकता है जो किताबें, संवाद, एनपीसी के साथ हो सकते हैं, शायद बॉक्स के पीछे भी खेल के बाहर।

तो 2 * 10 ^ 28 संभावित संयोजनों के साथ इसे आज़माने के लिए संभवत: अधिक संभावना होगी कि लोग गेम-डेटा के माध्यम से सामग्री को उस तरीके से प्राप्त करेंगे जो इसके बजाय।

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

जैसा कि बहुत कुछ ने उल्लेख किया है कि इसमें एक स्पष्ट नकारात्मक पहलू है कि इसका उपयोग मामला सीमित है। एक बार एक व्यक्ति ने यह पता लगा लिया कि वह इसे हर किसी के साथ साझा कर सकता है, यदि कुंजी / समाधान नहीं है तो सामग्री ही। हालाँकि यदि आपका इरादा कुछ ऐसा गुप्त रखना है कि एक व्यक्ति को इसे हल करने में सक्षम नहीं होना चाहिए और इसे हल करने के लिए लोगों को एक साथ काम करना होगा, या आप डरते हैं कि आपका ईस्टर अंडे इतनी अच्छी तरह से छिपा हुआ है (डिजाइन द्वारा) कि यह अधिक संभावना है कि कोई इसे गेम खेलने के बजाय कोड में पाएगा। तब मुझे लगता है कि यह बहुत अच्छा काम कर सकता है।

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


56
उत्तर तकनीकी विवरण पर ध्यान केंद्रित करते हैं, लेकिन यदि आपका लक्ष्य बिगाड़ने वाले को छिपाना है, तो विचार करें कि यह जानकारी केवल गेम खेलने से उपलब्ध हो जाएगी , जिस बिंदु पर (यदि आपका गेम लोकप्रिय है) यह सीधे सभी के लिए विकिया लेख पर जाएगा। पढ़ें, खिलाड़ी या नहीं।
लेउशेंको

4
गेम डेवलपमेंट स्टैकएक्सचेंज पर डुप्लिकेट: "मैं अपने गेम डेटा को कैजुअल हैकिंग से कैसे बचा सकता हूं?"
फिलीपींस

5
क्या यह एक मनोरंजन उत्पाद के लिए थोड़ा अधिक नहीं है? मेरा मतलब है कि लोग एक वॉकथ्रू देखकर "कुंजी" प्राप्त कर सकते हैं या खेल सकते हैं या केवल उन लोगों से पूछ सकते हैं जिन्होंने पहले से ही इसे खेला है। इसके अलावा खेल चीजों के साथ काम करने के इस "अधिक या कम अस्पष्ट" तरीके के कारण अधिक त्रुटि प्रवण हो सकता है। अन्यथा मुझे यह विचार पसंद है और यह एक अच्छा नौटंकी होगा, लेकिन यह अभी भी लोगों को हैकिंग / धोखा देने से नहीं रोकेगा, बल्कि इसे और कठिन बना देगा
BlueWizard

3
मुझे लगता है कि यह विशेष रूप से अच्छा होगा यदि आपके उपयोगकर्ता आपके गेम को हैक करने के लिए जाने जाते हैं और पहेली वास्तव में बहुत कठिन है। आप मंचों पर कल्पना कर सकते हैं "यह अजीब एन्क्रिप्टेड फ़ाइल क्या है"।
प्युर्लेज़

5
@PyRulez आह हाँ! इसके पीछे मेरी मुख्य प्रेरणा रही है। मुझे इससे नफरत है जब उन pesky सरकारों ने गेम फ़ाइलों के माध्यम से सभी ईस्टर अंडे खोजने के लिए। सिर्फ इसलिए कि वे इसे अपने दुश्मन मंचों पर पोस्ट कर सकते हैं और देश के नैतिक को बर्बाद कर सकते हैं।
क्रिस्टर

जवाबों:


90

यह सवाल पूछ रहा है कि क्या यह संभव है (न केवल व्यावसायिक रूप से व्यवहार्य या कुछ अन्य व्याख्या) कुछ गेम सामग्री को अनलॉक करने के लिए हैकिंग के बजाय एक पहेली को हल करने के लिए कम से कम 1 उपयोगकर्ता को मजबूर करना।

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

पूर्ण सरलतम मामले में, कल्पना करें कि गेम स्वयं एक कीबोर्ड सिम्युलेटर है और यह सवाल पूछता है "मेरी एन्क्रिप्टेड फ़ाइलों का पासवर्ड क्या है?", स्पष्ट रूप से हम सभी सहमत हैं कि गेम के स्रोत कोड होने से मदद नहीं मिलेगी। अब कल्पना कीजिए कि खेल सवाल पूछता है "पृथ्वी पर सबसे बड़े जानवर का नाम क्या है जिसे सबसे छोटे जानवर के नाम से जाना जाता है?"। क्या यह स्पष्ट नहीं है कि गेम का सोर्स कोड होने से भी मदद नहीं मिलेगी, और आपको अभी भी पहेली को हल करना है?

इस संबंध में कि क्या यह संभव है उत्तर निरपेक्ष है, यह संभव है।


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

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

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

4
स्रोत कोड (या stringsनिष्पादन योग्य पर) के साथ, एक पहेली जैसे "सबसे बड़े जानवर का नाम क्या है ...?" अभी भी खिलाड़ी / हैकर द्वारा हल करने की आवश्यकता हो सकती है , लेकिन कम से कम वह उस गेम में खतरनाक यात्रा से बच सकता है जहां सवाल होता है। इसलिए, पहेलियों को खुद भी कुछ हद तक छिपाया जाना चाहिए (पाठ अक्सर ग्राफिक्स के रूप में पर्याप्त हो सकता है; अधिक विस्तृत रूप से, मुझे लगता है कि मुझे एक गेम याद है जहां सामान्य 3 डी ऑब्जेक्ट्स, जब एक विशिष्ट बिंदु से देखा जाता है, तो संक्षिप्त रूप से एक पहेली या अन्य महत्वपूर्ण के समाधान के लिए संयुक्त है। जानकारी ...)
हेगन वॉन एटिज़ेन

4
दिए गए उद्धरण जैसे "यह ऑनलाइन हो सकता है तो हर किसी के लिए इसे बर्बाद कर सकता है।" मूल प्रश्न से ... क्षमा करें, लेकिन यह उत्तर इस बिंदु को याद कर रहा है। यह हो सकता है सिर्फ के रूप में हर किसी के लिए यह बर्बाद करता है, तो इस सवाल का जवाब या decrypted फ़ाइलों या जो कुछ भी पोस्ट कर रहे हैं की चपेट में है, और है बस के रूप में उन्हें पोस्टिंग की चपेट में।
नाथन तुग्गी

57

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

इसे "क्रिप्टोग्राफी की मूलभूत समस्या" कहा गया है: ऐलिस बॉब को एक संदेश भेजना चाहता है, चार्ली के बिना इसे पढ़ने में सक्षम होने के बावजूद भी वह इसे प्राप्त नहीं करता है। आपके द्वारा प्रस्तावित किए जा रहे दृष्टिकोण के साथ समस्या यह है कि बॉब और चार्ली इस मामले में एक ही व्यक्ति हैं

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


3
इस मामले में हालांकि एन्क्रिप्शन को क्रैक करना एक बॉट लिखने के बराबर होगा जो पहेली को हल करता है। शायद खेल को पूरा करने और जवाब लिखने से ज्यादा कठिन है
इवान

15
मैं केवल यह कहना चाहता हूं कि यह उत्तर वास्तव में मेरे प्रश्न का उत्तर नहीं देता है! मैं वास्तव में चाहता हूं कि लोग "कोड क्रैक" करें या अपनी पहेली को हल करें। यह पूरी बात है, और हाँ एक बार किसी ने यह पता लगा लिया कि मैं उसे समाधान साझा करने से नहीं रोक सकता, मैं कोशिश नहीं कर रहा हूँ। हालाँकि आप यह कहते हुए गलत कह रहे हैं कि "इसे डिक्रिप्ट करने के लिए आवश्यक सभी जानकारी समाहित है" क्योंकि संपूर्ण बिंदु यह जानकारी उपयोगकर्ता द्वारा दी गई थी। विवरण के लिए अद्यतन प्रश्न पढ़ें।
क्रिस्टर

6
@ क्रिस यह करता है और यहाँ क्यों है: मेसन कह रहा है कि अगर वे गेम फ़ाइलों में शामिल हो सकते हैं तो पहेली का उत्तर जानने के लिए क्या करें क्योंकि केवल एक अल्पसंख्यक वास्तव में ऐसा करेगा ..
Insane

9
@JonasDralle यह एक घृणित निंदक दृष्टिकोण है, और यह भी सच नहीं है। Morrowind और Oblivion के आसपास बना मजबूत, स्थायी समुदाय Skyrim को बेचने से नहीं रोकता था ; अगर कुछ भी, यह इसे और अधिक सफल बना दिया!
मेसन व्हीलर

3
@ क्रोनैक्स यदि आप "एक समय पैड" शैली एन्क्रिप्शन का उपयोग करते हैं, तो इस मामले में- कुंजी आपके पहेली हमलावर हल होने के नाते कुंजी स्थान के आकार पर ब्रूट-फोरिकंग की तुलना में बेहतर विकल्प नहीं है। सही प्रकार की पहेली के साथ, जो ब्रह्मांड के जीवन काल के भीतर हल करने के लिए बड़ी मात्रा में हो सकता है। इसके अलावा, अगर ईस्टर अंडा है, तो कहें, डेवलपर का एक संदेश, एक हमलावर के पास एक यादृच्छिक सही-ईग्निलिस से वास्तविक संदेश को अलग करने का कोई तरीका नहीं होगा।
बेन एरनसन

10

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

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

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


यद्यपि स्थानीय रूप से संग्रहीत कुंजी के साथ एन्क्रिप्ट किया गया डेटा हमेशा हैक किया जा सकता है। व्यवहार में सभी आधुनिक ऐप और गेम एक हद तक इसका उपयोग करते हैं।
इवान

सोमला देखें और यह कैसे सिक्के करता है
इवान

मेरा मानना ​​है कि यह सवाल उत्सुक खिलाड़ियों से भविष्य की सामग्री को छिपाने के बारे में था, न कि मुद्राओं और खिलाड़ी आंकड़ों को छेड़छाड़ से बचाने के लिए कैसे
axl

1
चूंकि यह एक ईस्टर अंडे के बारे में है, ध्यान आकर्षित करना बिल्कुल वैसा ही है जैसा आप चाहते हैं।
प्युर्लेज़

6
इसे कठिन बनाना सिर्फ और अधिक दृढ़ लोगों को आकर्षित करेगा मुझे लगता है कि यह एक गेम के लिए एक महान विपणन रणनीति है :)
सम्पथ्र्स

9

इसका मुख्य कारण यह है कि यह gamedev.SE पर होना चाहिए क्योंकि इस एन्क्रिप्शन को करने से गेमप्ले के परिणाम होते हैं।

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

और यहाँ परिणाम है। डिक्रिप्शन आमतौर पर बाइनरी है। या तो आपके पास डेटा को अन-एन्क्रिप्ट करने के लिए आवश्यक सटीक एन्क्रिप्शन कुंजी है, या आप नहीं हैं।

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

उदाहरण के लिए पोर्टल, टेस्ट चैंबर 10 लें। आपको बाईं ओर जाना है, कुछ सामान करना है, फिर दाएं जाना है और कुछ सामान करना है, सभी एक प्लेटफॉर्म को कम करना है।

या आप बस अपने आप को कुछ वेग दे सकते हैं और जब आप सही तरीके से चलते हैं तो अपने आप को प्लेटफॉर्म तक ला सकते हैं।

GLDDOS: तो आप एक पहेली खेल बना दिया। एक पहेली खेल जो उन लोगों को सजा देता है जो पहेली खेल का सबसे अधिक आनंद लेते हैं। बहुत बढ़िया। लेकिन कम से कम उन हैकर्स को आपके कीमती डेटा पर नहीं मिलेगा। क्योंकि जो लोग पहेली गेम को हल करने का आनंद लेते हैं, वे सटीक प्रकार के लोग हैं, जो ऑनलाइन पहेली गेम के समाधान को देखते हैं।

तो वह पूरी तरह से इसके लायक है।

इसलिए, एडवेंचर्स ऑफ लोलो, स्पेसचैम और पोर्टल ( लाखों लोगों के बीच ) जैसे पहेली गेम सही हैं। इसके बजाय, आपको अपना गेम ऐसे डिज़ाइन करना होगा कि एक पहेली बनाना असंभव है जिसमें एक से अधिक समाधान हैं। इसके लिए बहुत अधिक देखभाल की आवश्यकता होती है, और आमतौर पर गेमप्ले को काफी हद तक प्रतिबंधित करने की आवश्यकता होती है।

GLDDOS: तो आप एक पहेली खेल बना दिया। एक ऐसा खेल जो उन लोगों द्वारा खेला जाता है जो पहेली के रचनात्मक समाधान खोजना पसंद करते हैं। और आपने एक ऐसा खेल बनाया जिसमें पहेली का कोई रचनात्मक समाधान नहीं है। *धीमी ताली*

मैं यह नहीं कह रहा हूं कि आप ऐसा खेल नहीं बना सकते। या ऐसा खेल अच्छा नहीं हो सकता। केवल इस तरह के खेल को एक निश्चित तरीके से डिजाइन करना होगा।

ओह, और आपको इस गेमप्ले को ऐसे डिज़ाइन करना होगा कि यह यंत्रवत् समाधान खोजने के लिए असंभव (या अत्यधिक कठिन) है ।

GLDDOS: तो आप एक पहेली खेल बना दिया। एक पहेली खेल जो खेलने की तुलना में हैक करने के लिए अधिक दिलचस्प है । बहुत बढ़िया।


बेशक, इसके लिए एक चेतावनी है: "समाधान" का अर्थ। या इस बिंदु पर अधिक, आप समाधान के किन तत्वों को ध्यान में रखते हैं?

किसी भी गेम में एक मूविंग कैरेक्टर शामिल होता है, आप संभवतः डिक्रिप्शन कुंजी बनाने के लिए कैरेक्टर के सटीक मूवमेंट का उपयोग नहीं करने वाले हैं। उदाहरण के लिए, यदि आपके पास एक पहेली गेम है जहां खिलाड़ी को पहेली को "हल" करने के लिए कुछ वस्तुओं को लेने की आवश्यकता है, तो आप कुंजी को उस क्रम पर निर्भर कर सकते हैं जिसमें उन वस्तुओं को छुआ गया है।

बेशक, यह ऊपर उस समस्या में चलता है, जहां एक खिलाड़ी चीजों को आउट-ऑफ-ऑर्डर करने का तरीका ढूंढता है। जिसका मतलब है कि आपको पहेली को ऐसे डिजाइन करना है कि केवल एक ही आदेश है जो आप संभवतः चीजों को उठा सकते हैं।

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

आजकल, आपको इसे थोड़ा चुनौतीपूर्ण बनाने के लिए कम से कम 128 की आवश्यकता है। अब इसका मतलब है कि प्रत्येक स्तर को इसमें बहुत सारे सामान रखने की आवश्यकता है, फिर भी आपके खेल के डिजाइन को प्रभावित कर रहा है।


2
@ क्रिस: आपका उदाहरण केवल आपके समग्र प्रश्न की अप्रासंगिकता को धोखा देता है। "किसी भी खोज के बाहर एक गुप्त वेदी" की सामग्री, परिभाषा के अनुसार, किसी भी खेल के लिए अप्रासंगिक है जो मूल रूप से quests को पूरा करने के बारे में है । और यदि आपका खेल quests पूरा करने के बारे में नहीं है, तो आप इसमें quests क्यों करते हैं? किसी भी तरह से, समग्र तथ्य यह है: आप अपने खेल या अपने खिलाड़ियों के लिए कोई वास्तविक प्रासंगिकता नहीं है। आपको अपने बहुत सीमित समय और ऊर्जा पर ध्यान केंद्रित करना चाहिए जो मायने रखती है
निकोल बोल

2
@ क्रिस: " इस तथ्य के बाद से कि एन्क्रिप्शन का उपयोग किया जाता है 99.9% उपयोगकर्ताओं के लिए पारदर्शी है, यह एक भयानक विचार होने के लिए एक वैध तर्क नहीं है। " अगर यह एक ईस्टर अंडे को विकास में अधिक समय लेता है। वास्तव में उपयोगी सुविधाओं के लिए जाना, तो हाँ, यह एक भयानक विचार है। आपने इस सुविधा के योग्य होने के बजाय अपने प्रश्न और उत्तरों को तैयार करने में अधिक समय बिताया है । उस समय में, आप अपना वास्तविक खेल लिख रहे होंगे। यदि यह ९९.९% उपयोगकर्ताओं के लिए पारदर्शी है ... तो इसे एन्क्रिप्ट किया गया है तो यह उनके लिए क्यों मायने रखता है? 0.1% लोगों के लिए समय क्यों व्यतीत करें?
निकोल बोल

2
मुझे क्षमा करें, लेकिन मुझे अपने गेम बनाने में कुछ मज़ा आ रहा है! हर कोई रोबोट बनाने वाला गेम नहीं हो सकता। मुझे यह भी जानने में मदद करें कि मुझे कितना समय लगेगा और मैं कितना खर्च करने को तैयार हूं। कम से कम लागू करने के लिए पारिस्थितिकीय हिस्सा ही आगे सीधे होगा।
क्रिस्टर

1
The consequence here is that whatever game you design must be so narrowly focused that there is only one possible solution to every level.जरूरी नहीं: वह प्रत्येक संभव समाधान के लिए सामग्री को एन्क्रिप्ट कर सकता है और सभी संभव समाधानों के लिए डुप्लिकेट एन्क्रिप्टेड सामग्री को शिप कर सकता है। दो-स्तरीय एन्क्रिप्शन का उपयोग करके अंतरिक्ष को बचाया जा सकता है - लिंक किए गए उत्तर में उपयोगकर्ता कुंजी एक विशिष्ट समाधान से मेल खाती है , दस्तावेज़ सामग्री से मेल खाती है।
मुस्तहो

4
@ मुमुहो: इसके लिए "पहले से संभव उपाय" जानना आवश्यक है।
निकोल बोल

8

यहाँ के उत्तर अच्छे हैं; मैं इसे दूसरे दृष्टिकोण से देखूंगा। आप जो वर्णन कर रहे हैं वह एक विशेषता है । सुविधाओं की लागत और लाभ हैं। लागत में फीचर बनाने की डॉलर की लागत और "अवसर लागत" दोनों शामिल हैं। वे हैं: एक ऐसी दुनिया में जहां आपके पास परिमित डॉलर और परिमित घंटे और परिमित प्रोग्रामर हैं, आपके द्वारा की जाने वाली प्रत्येक सुविधा का अर्थ है अनंत संख्या में संभव सुविधाएँ जो इसके स्थान पर नहीं की गईं।

तो सवाल यह है कि क्या आप इस सुविधा की लागत को वास्तविक रूप से बता सकते हैं? कोई मुफ्त सुविधाएँ नहीं हैं, इसलिए लागतों के बारे में यथार्थवादी बनें। क्या आप इस सुविधा के लिए एक हज़ार डॉलर देने को तैयार हैं? एक सौ हजार? दस लाख? इस सुविधा के लिए आप किन विशेषताओं में कटौती करना चाहते हैं?

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


5

ऐलिस बॉब और ईव समस्या इसे अच्छी तरह से दर्शाती है। जैसा कि मेसन ने अपने जवाब में कहा, आप ईव से एक रहस्य नहीं रख सकते हैं यदि ईव भी बॉब है।

इस प्रकार, किसी भी समाधान में बॉब शामिल होगा जिसमें सभी आवश्यक जानकारी नहीं होगी। आपको प्रत्येक स्तर को एक व्यक्तिगत संदेश के रूप में मानना ​​होगा , एक-दूसरे से अलग-अलग एन्क्रिप्ट किया जाएगा, और अगले स्तर के लिए संदेशों का एक बाहरी स्रोत होगा जो संदेशों को ठीक से रखने में सक्षम था।

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

लेकिन आप यहां एक प्रमुख तत्व भूल रहे हैं। यह एक खेल है। अगर कोई खेल में धोखा देता है, तो बड़ा जो। आपने चीटर्स के लिए गेम नहीं लिखा। यह खोज वॉकथ्रू या लेवलिंग गाइड के साथ एक ही बात है: जो लोग इसे अपने दम पर निकालने की चुनौती चाहते हैं, वे पोस्ट किए गए समाधानों की अनदेखी करेंगे। भले ही आप इसे बिना खेले गेम को क्रैक करना असंभव बना दें (हम जानते हैं कि यह तार्किक रूप से असंभव है, लेकिन EVEN IF आप कर सकते हैं) यह केवल एक आदमी को चलने से पहले ले जाएगा क्योंकि उसने इसे हराने के लिए आवश्यक सब कुछ पोस्ट किया था। तो आप केवल अपरिहार्य में देरी कर रहे हैं।

अपना समय एक भयानक खेल बनाने में बिताएं। वहाँ दस चीजें हर खेल की जरूरत है और पिछले मैंने देखा, एन्क्रिप्शन उनमें से एक नहीं था।


2

मेरा मानना ​​है कि आपका विचार व्यर्थ है।

जब कोई आपके खेल को खेलता है, तो वे इसे खेलना पसंद करते हैं, वे इसे पुरस्कार जीतने के लिए नहीं कर रहे हैं, वे इसे मज़े के लिए कर रहे हैं।

उपयोगकर्ताओं को पता है कि सबसे मज़ेदार तरीका आपके खेलने के तरीके से आता है और धोखा नहीं देगा , क्योंकि आपके ग्राहक वे पहले से ही एक कहानीकार के रूप में आप पर भरोसा करते हैं।

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


हालाँकि, यदि आपका गेम सुपर मारियो लैंड गुप्त स्तरों की तरह कई समाधान प्रस्तुत करता है, तो अपनी संपत्ति को एन्क्रिप्ट करने से उन समाधानों को आसानी से रोका जा सकेगा।

जबकि यह आपके विचार के पक्ष में एक बिंदु लगता है, अंत में यह नहीं है।

एन्क्रिप्शन के साथ भी यह जानना संभव होगा कि ऐसे गुप्त समाधान मौजूद हैं।
एक बार जब यह पता चल जाएगा कि एक गुप्त समाधान मौजूद है, तो खिलाड़ियों को गुप्त संपत्तियों को देखने से रोकना अप्रासंगिक होगा क्योंकि वे अभी भी खेल के छिपे हुए हिस्सों को खेल के माध्यम से एक्सेस करना चाहते हैं (हाँ, भले ही वे पहले से ही हर छिपे हुए को देख लें। बनावट / क्लिप / ऑडियो / पाठ)।

आप कुछ अनजान तकनीक 1 का उपयोग करके गुप्त समाधान के अस्तित्व को लीक होने से रोक सकते हैं , लेकिन यह अभी भी संदिग्ध होगा (ऐसा क्यों कर रहे हैं कि अगर कोई गुप्त समाधान नहीं है?), खिलाड़ी उन्हें खोजने में रुचि खो देंगे और आपके पास खिलाड़ी कम होंगे? , और नहीं।
आखिरकार, हम कुछ ईस्टर-अंडे को ट्रिगर करने के लिए एक गेम पूरा करने के बाद कुछ घंटों तक खेल सकते हैं लेकिन हम एक मिनट अधिक नहीं खेलेंगे अगर उन्हें ट्रिगर करना एक टाइटैनिक प्रयास की आवश्यकता होगी!


आप जो करना चाहते हैं, वह एक लेखन पुस्तक की तरह है जहां अगले अध्याय को वर्तमान अध्याय के एक शब्द के साथ एन्क्रिप्ट किया गया है, ताकि पाठकों को खुद को समाप्त करने से रोका जा सके।
इसके बारे में सोचो, क्या यह व्यर्थ नहीं है?

1 वेरा क्रिप्ट की तरह बहुत सुंदर यह छिपे हुए संस्करणों के साथ करते हैं।


1
मैं वास्तव में उस पुस्तक विचार को पसंद करता हूं। मैं समझता हूं कि यह बहुत से लोगों को निराश कर सकता है, लेकिन मैं कल्पना भी कर सकता हूं कि लोग वास्तव में ऐसी किताब चाहते हैं। मैं ऐसे लोगों को जानता हूं जो आगे नहीं बढ़ने पर भी अपने आप को खत्म करने में मदद कर सकते हैं। इसलिए मुझे लगता है कि इस तरह की किताब मदद कर सकती है। हालांकि वे तब भी ऑनलाइन कुंजियों को देख सकते थे जब तक कि चाबियों को अलग-अलग नहीं किया जाता। तब भी वे सीधे अंत को देख सकते थे। फिर भी अगर वे उस हताश थे तो यह नहीं होगा कि आप उन्हें आगे बढ़ने से रोकने की कोशिश करें।
क्रिस्टर

1

मैं व्यावसायिक व्यवहार्यता पर टिप्पणी नहीं करूंगा, हालांकि शुद्ध तकनीकी दृष्टिकोण से यह एक मनोरंजक चुनौती है।


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


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

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

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

  • समस्या की जड़ यह है कि छवि पहचान अभी भी कंप्यूटर के लिए कुछ कठिन है
  • जिसके ऊपर हम इस तथ्य को परत करते हैं कि कैप्चा पटाखे अक्षरों और अंकों के लिए तैयार किए गए हैं, न कि कस्टम ग्लिफ़ के लिए
  • जिसके शीर्ष पर हम इस तथ्य को परत करते हैं कि खिलाड़ी को ग्लिफ़ प्रकट करने के लिए कई बनावट (पारदर्शिता के साथ) के संयोजन से खेल में कोई एकल संपत्ति नहीं होती है जिसमें ग्लिफ़ दिखना चाहिए
  • अन्य जगहों पर अन्य बनावट (टुकड़ों के साथ) का उपयोग करें, लेकिन कभी भी इस तरह से न करें कि छिपी जगहों को छोड़कर एक पूर्ण ग्लिफ़ उत्पन्न हो जो खिलाड़ी को कभी भी नहीं मिल पाए

और जीतने वाले ग्लिफ़ संयोजन को स्वचालित रूप से निकालने के किसी भी कार्यक्रम में एक दिन का नरक होगा।


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

स्पष्ट हमला वेक्टर या तो जनरेटर को हमेशा एक ही पासवर्ड चुनने या हमेशा एक ही पासवर्ड को स्वीकार करने में सत्यापनकर्ता को धोखा देने के लिए (उदाहरण के लिए किसी और की रहस्य फ़ाइल डाउनलोड करके) को धोखा दे रहा है।

यहां, उपयोगकर्ता के खाते में फ़ाइलों को लिंक करने के लिए एक संभावित समाधान होगा, और पासवर्ड को नमक के रूप में आमतौर पर अनुशंसित किया जाता है:

  • जब उपयोगकर्ता फ़ाइलों के एक सेट का अनुरोध करता है, तो बेतरतीब ढंग से एक नमक उत्पन्न करें और जितने पासवर्ड आपके पास हैं, उतने ही रहस्य हैं तो गुप्त संपत्ति बनाएं (आप इस प्रक्रिया को एक बार / दिन / उपयोगकर्ता के लिए सीमित कर सकते हैं, उदाहरण के लिए, अपने सर्वर को ओवरलोड करने से बचने के लिए)
  • उपयोगकर्ता के खाते की जानकारी में पीढ़ी और नमक के टाइमस्टैम्प को स्टोर करें
  • उपयोगकर्ता को टाइमस्टैम्प और वैयक्तिकृत गुप्त फ़ाइलों को वापस भेजें

फिर, जब उपयोगकर्ता पासवर्ड जमा करने के लिए तैयार हो:

  • उपयोगकर्ता लॉग इन है (यदि वह पहले से नहीं था)
  • सॉफ्टवेयर दोनों टाइमस्टैम्प और ग्लिफ़ पासवर्ड भेजें
  • अगर टाइमस्टैम्प एक संग्रहीत से भिन्न है, तो उपयोगकर्ता को सलाह दें कि वह गुप्त फाइलों के अप्रचलित सेट का उपयोग कर रहा है
  • यदि पासवर्ड पहले ही बहुत बार प्रयास किया जा चुका है, तो उपयोगकर्ता को सलाह दें कि वह गुप्त फाइलों के अप्रचलित सेट का उपयोग कर रहा है
  • अन्यथा, कुंजी का उत्पादन करने के लिए नमक + पासवर्ड हैश करें
  • अन्यथा, उपयोगकर्ता को वापस कुंजी भेजें ताकि वह उसकी व्यक्तिगत फाइलें देख सके
  • इस खाते द्वारा इस पासवर्ड का प्रयास करने की संख्या में वृद्धि हुई है

यहाँ लक्ष्य जितना संभव हो उतना खाता साझा करना है:

  • गुप्त फ़ाइलों को बनाने के लिए एक खाता साझा करना (ए) सीमित है, क्योंकि प्रति दिन केवल एक उत्पन्न किया जा सकता है और (बी) बेकार है, क्योंकि नवीनतम उत्पन्न दूसरे को अप्रचलित बनाता है
  • एक खाते को साझा करना और संबंधित गुप्त फ़ाइलों को वितरित करना बेकार है, क्योंकि किसी दिए गए पासवर्ड का उपयोग केवल N बार ही किया जा सकता है, इससे पहले कि वह किसी भी कुंजी को प्राप्त नहीं करता है

और हम लगभग वहाँ हैं।


अंत में, वहाँ भी, एक पटाखा खेल का एक संशोधित संस्करण जारी कर सकता है जिसमें गुप्त संपत्ति को डिक्रिप्ट किया जाता है और सीधे एकीकृत किया जाता है (आपकी सावधानीपूर्वक सत्यापन योजना को दरकिनार)।

समाधान सरल है (और अप्रचलित 1 के ऊपर लगभग सब कुछ बनाता है ): ग्राहक पर भरोसा मत करो।

अपनी वेबसाइट पर एक लीडरबोर्ड बनाएं, और उनके खाते में खिलाड़ियों की प्रगति का ट्रैक रखें। खिलाड़ी यह दावा कर सकते हैं कि उन्होंने अपने द्वारा चाहा गया खेल समाप्त कर लिया है, लेकिन जब तक उनका खाता यह दर्शाता नहीं है, हर कोई जानता है कि वे धोखा दे रहे हैं ...

... इसे सामाजिक दबाव कहा जाता है;)

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


विचारशील जवाब के लिए धन्यवाद। आप अच्छे अंक बनाते हैं। हालांकि मैं यह जोड़ना चाहूंगा कि कुंजी / समाधान को आपके द्वारा कहे गए गेम में संग्रहीत करने की आवश्यकता नहीं है। यह उदाहरण के लिए गेम वेबपेज के HTML में छिपा हो सकता है, शायद आप उस तरह के सामान के माध्यम से देखने वाले लोगों को पुरस्कृत करना चाहते हैं। लेकिन यहां तक ​​कि खेल में आप पहेलियों को एक समाधान के रूप में उपयोग करने की तरह अधिक रचनात्मक हो सकते हैं, ज्यामिति जो कोण से देखने पर जानकारी का खुलासा करती है, संदर्भ से संबंधित चीजों का उपयोग करें जो आपको तब तक नहीं मिलेगा जब तक कि आप बहुत सारे विद्या के माध्यम से नहीं पढ़ते हैं। खेल। जैसे कि कंप्यूटर टर्मिनलों में स्किरीम की किताबें या लॉग कैसे हैं।
क्रिस्टर

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

@ क्रिस: बेकार है कि किसी के द्वारा बर्बाद बस खेल संपत्ति के माध्यम से देख रहे हैं। => यह वास्तव में जगह का वर्णन करने के लिए गुप्त फ़ाइलों का उपयोग करके हल करने योग्य है (मौजूदा बनावट का पुन: उपयोग करना), एक बार जब रहस्य एक बार फिर से बाहर निकल जाता है, तो ...
मैथ्यू एम।

0

यह एक दिलचस्प विचार है; पहेली डिस्क पर एक वेरिएंट और मैनुअल-द-द-द-द-द-द-मैनुअल मैनुअल प्रोटेक्शन सिस्टम। मुझे लगता है कि कुछ "एआरजी" गेम इस तरह से काम करते हैं, जहां यह समझा जाता है कि खिलाड़ी गेम डिजाइनर के खिलाफ सामूहिक रूप से काम कर रहे हैं।

जाहिर है एक बार जब पहला व्यक्ति इसे डिक्रिप्ट करता है तो वे इसे इंटरनेट पर प्रकाशित करेंगे।

सामान्य या प्रक्रियात्मक सामग्री उसी तरह से काम कर सकती है: जब तक आप "बीज" साझा नहीं करते, तब तक आप उसी दुनिया को किसी अन्य खिलाड़ी के रूप में नहीं देखते हैं।

मैं इसके साथ कोई कानूनी समस्या नहीं देख सकता, हालांकि Apple इसे अपने ऐप स्टोर से अस्वीकार कर सकता है और आपको इसे गेम कंसोल पर अनुमोदित करने के लिए समाधान प्रदान करना पड़ सकता है।


0

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

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

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


0

मेसन व्हीलर के पास यह अधिकार है: आप ऐसा नहीं कर सकते। कोई हमेशा अपने खेल को इंजीनियर को उल्टा कर सकता है अगर वे चाहते हैं।

आपको अपने खेल को वैसे भी "संरक्षित" करने की आवश्यकता नहीं है जिस तरह से आप वर्णन करते हैं। जैसे ही एक व्यक्ति को ईस्टर अंडे का पता चलता है वह रहस्य बैग से बाहर हो जाता है। यदि गेम की प्रत्येक कॉपी में एक अलग ईस्टर अंडा होता है, तो केवल हैकर कॉपी का पता चल जाएगा। क्या आप वास्तव में परवाह करते हैं कि 1000 लोगों में से एक हैकर को गेमप्ले से गुजरे बिना ईस्टर अंडा मिला?

कॉपीराइट कानून ऐसा है कि कोई गंभीर मुकदमे को जोखिम में डाले बिना आपके खेल को बंद कर सकता है, इसलिए कॉपीराइट आपकी रक्षा करता है।

जहाँ तक यादृच्छिक उपयोगकर्ताओं को अपने मंच अवतार पर अपने textures डाल रहा है, तो क्या? इसे घास की जड़ों का विज्ञापन मानें।

"सुरक्षा" सामान के बारे में जुनूनी हो जाना आपको कठिन वास्तविकताओं से विचलित कर देगा जैसे: खेल बनाना

जब मैं किसी ऐसे उत्पाद के साथ लोगों को देखता हूं जो अपनी आईपी सुरक्षा योजनाओं के बारे में ऐसी चीजों के बारे में बात करता है जो मौजूद नहीं हैं, तो मेरे लिए इस तरह का एक बड़ा क्षण है क्योंकि यह पूरी परियोजना पर एक बहुत बड़ा लाल झंडा उठाता है।


-1

कुछ संभावनाएँ:

  • सादा पुराना कोड ऑबफ्यूजन । यह कोड को डीकोड करना असंभव नहीं होगा लेकिन कम से कम यह कठिन होगा।

  • सर्वर-साइड समाधान। आप सर्वर को कुछ विशेष कमांड भेजते हैं और सर्वर आपको कोड भेज सकता है ... या डीएलसी भी डाउनलोड कर सकता है।

  • आप अन्य सामग्री में निष्पादन योग्य कोड छिपाने के लिए स्टेग्नोग्राफ़ी का उपयोग कर सकते हैं ।

यह आपके रहस्य को 100% सुरक्षित नहीं करेगा, लेकिन ऐसा लगता है कि यदि कोई रहस्य उजागर नहीं करता है, तो कोई भी पैसे को ढीला नहीं करेगा।


-1

यह किसी भी अन्य स्कीमा की तरह बेकार है जहां आप क्लाइंट पर कुंजी और एल्गोरिथ्म दोनों संग्रहीत करते हैं। यदि आप पूछते हैं "कुंजी कहां है, तो मैं उपयोगकर्ताओं के इनपुट पर भरोसा करता हूं और इसे स्वयं संग्रहीत नहीं करता हूं?", याद रखें कि आपकी पहेली में इसकी परिभाषाओं द्वारा नियम और संसाधन हैं - यह कुछ एल्गोरिथ्म द्वारा हल किया गया है, न कि क्रूरता से। यह सटीक एल्गोरिथ्म और इसके संसाधन प्रमुख पीढ़ी के एल्गोरिथ्म है जिसे आपने खेल में केवल राज्य में हार्डककोड किया है। कोई भी आपके "गैर-मौजूद" कुंजी को केवल एक छोटा प्रोग्राम लिखकर प्राप्त कर सकता है जो आपकी पहेली को आपके नियमों के अनुसार हल करता है।


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

@ क्रिस, यह कोई अलग नहीं है जो किसी अन्य "सुरक्षा को अस्पष्टता से" होममेड एन्क्रिप्शन द्वारा पता लगाता है। "बॉक्स पर" - आपने बस "पेपर कवर" संसाधन की कुंजी लिखी है जो आप उपयोगकर्ता को "फाइल" संसाधन के बजाय देते हैं जो आप उपयोगकर्ता को देते हैं । बड़ी बात।
ओलेग वी। वोल्कोव

@ क्रिसर, जिसका अर्थ है "एक पहेली जो पहले नहीं बनाई गई है" को हल करना "एक होममेड एन्क्रिप्शन एल्गोरिथम को हल करने के बराबर है जो पहले नहीं बनाया गया है"।
ओलेग वी। वोल्कोव

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

पढ़ने के स्रोत से कितना अलग है यह नर्क? आप निर्धारित नियमों के अनुसार कार्य करते हैं -> आपको कुंजी मिलती है। बस इतना ही। सिवाय आप वास्तव में खेल खेलने के बजाय अन्य खेल संसाधनों से अपने "सुराग" पढ़कर शॉर्टकट ले सकते हैं।
ओलेग वी। वोल्कोव
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.