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

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


तस्वीर रूसी रोमाकिंग प्रोजेक्ट के अनुसार रूसी रोमाकिंग समुदाय के लोगो को दिखाती है।

पढ़ने से पहले

सबसे पहले, मैं यह कहना चाहता हूं कि मैं केवल उस अनुभव की समीक्षा करता हूं जो मुझे व्यक्तिगत रूप से देखने या अभ्यास करने का अवसर मिला था। तो यह इस तथ्य से बहुत दूर है कि सभी अनौपचारिक स्थानीय लोग नीचे वर्णित विधियों का पालन करते हैं, और यहां तक ​​कि उल्लिखित उपकरणों के लिए भी। सबसे पहले, मैं उस दृष्टिकोण के बारे में बात करूंगा जो मैंने खुद को लागू किया था। मेरा मानना ​​है कि यह पर्याप्त रूप से सांकेतिक है और अन्य उत्साही लोगों द्वारा प्रचलित कई अन्य तकनीकों को बेहतर बनाता है। हालांकि, यहां की कार्यप्रणाली की अवधारणा अस्पष्ट है, और कई के लिए बिल्कुल भी नहीं है।

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

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

अंत में, मैंने केवल तकनीकी भाग और केवल सामान्य तरीके से वर्णन करने का फैसला किया - उदाहरणों के साथ एक विस्तृत विवरण ऐसे लेखों के एक दर्जन, या यहां तक ​​कि एक और बेकार किताब के लिए पर्याप्त होगा, इसलिए अब इसे एक लंबे बॉक्स में रखें। इसके बावजूद, लेख, यहां तक ​​कि अपूर्ण रूप में, काफी बड़ा हो गया, और मैंने इसे कई पदों में तोड़ने का फैसला किया। आपके लिए यह कितना दिलचस्प या उपयोगी है, इसका अंदाजा आप लगा सकते हैं।

मुद्दे का तकनीकी पक्ष

यदि आप अनुवाद प्रक्रिया के एक छोटे से ब्रेक को उप-मुखौटे में बनाते हैं, तो आप इस सूची में कुछ प्राप्त कर सकते हैं:

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

यदि आप विवरण में तल्लीन करते हैं, तो अनुवाद के लिए खेल तैयार करने के लिए सभी मामलों के लिए समान अनुक्रम नहीं होना चाहिए, जो पूरा होना चाहिए। इसके अलावा, कोई सार्वभौमिक विधियां नहीं हैं, जिनके साथ आप कुछ कदम उठा सकते हैं। वास्तव में, यह हमेशा कामचलाऊ व्यवस्था है, लेकिन फिर भी ऐसे कार्यों की एक सूची है जो लगभग हमेशा पाए जाते हैं।

मैं सबसे अधिक बार उत्पन्न होने वाले और महत्वपूर्ण कार्यों को उजागर करने की कोशिश करूंगा, उनमें से प्रत्येक के बारे में अलग से बताऊंगा। हम किसी भी चीज को एक मंच के रूप में नहीं मानेंगे - अर्थात नीचे वर्णित सब कुछ पीसी और किसी भी अन्य प्लेटफॉर्म के लिए सही है - चाहे वह कोई भी प्लेस्टेशन, एक्सबीओएक्स, या सेगा या डेंडी (एनईएस) हो।

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

पाठ एन्कोडिंग की परिभाषा

---

यह पूरी तरह से तुच्छ कार्य प्रतीत होता है, जिसमें यह निर्धारित किया जाता है कि पाठ एन्कोडिंग है। और ज्यादातर मामलों में यह वास्तव में मुश्किल नहीं है, लेकिन यहां तक ​​कि डेवलपर्स के विचार में कोई सीमा नहीं है।

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

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

41=A 42=B ... 5A=Z 1E20=Hero 1E21=Item 1E22=Bonus 

उदाहरण के लिए, पाठ "हीरो आइटम प्राप्त करता है!" निम्नानुसार एन्कोड किया जाएगा: " 1E 20 20 6F 62 74 61 69 6E 73 20 1E 21 21 "। हालांकि, अगर यह पता चलता है कि परिणामी एन्कोडिंग किसी भी उपयुक्त एन्कोडिंग (यूनिकोड) के साथ पर्याप्त रूप से संगत है, तो आम तौर पर तालिका की आवश्यकता नहीं होती है और आप इस चरण को छोड़ सकते हैं।

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

उदाहरण के लिए, शब्द "वर्ल्ड" के लिए दोनों क्रम "57 4F 52 4C 44" और "77 6F 72 6C 64" है। हां, कम से कम "13 0B 0E 08 00"! ऐसे सीक्वेंस पाए जाने और यह सुनिश्चित करने के बाद कि यह एन्कोड किया गया शब्द है, हम आसानी से एन्कोडिंग टेबल बना सकते हैं। इस कार्यक्षमता के साथ सबसे प्रसिद्ध कार्यक्रम हेक्स संपादक ट्रांसहेक्सियन है । खोज सापेक्ष जैसे विशिष्ट उपयोगिताओं के टन हैं। हां, और तकनीकी रूप से सक्षम अनुवादकों में से कई ने अपने लिए समान उपयोगिताओं को लिखा।



विशिष्ट मामला: यदि आप इस स्क्रीनशॉट को फ़ॉन्ट कैनवास से तुलना करते हैं, तो आप देख सकते हैं कि अनुक्रम पाया गया फ़ॉन्ट में वर्णों का सूचकांक है:


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

उदाहरण के लिए, गेम ब्वॉय एडवांस और निनटेंडो डीएस के लिए अंतिम फंतासी के कई हिस्सों के पुन: रिलीज में, फ़ॉन्ट के पात्रों को घटना की आवृत्ति द्वारा क्रमबद्ध किया जाता है, और यूटीएफ -8 के समान एक विधि का उपयोग अनुक्रमितों को एन्कोड करने के लिए किया जाता है। यानी 0x7F से अधिक कोड वाले किसी भी वर्ण को दो बाइट्स के साथ एन्कोड किया गया है, जबकि पहले 128 वर्ण केवल एक के साथ एन्कोडेड हैं:

 uint16 encode(uint16 code) { return 0x8000 | ((code << 2) & 0x1F00) | (code & 0x3F); } 

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

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

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

संकेत खोजते हैं

---

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

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

बहुत बार, सभी पॉइंटर्स को एक ही स्थान पर संग्रहीत किया जाता है, जिसे आमतौर पर "पॉइंटर्स टेबल" कहा जाता है - यह पॉइंटर्स या तत्वों की एक सरणी है। ऐसे मामलों में, खेल अनुक्रमित द्वारा पंक्तियों तक पहुंचता है, जिसके आधार पर, इस तरह की तालिका से एक सूचक लिया जाता है। तब यह पाठ के ब्लॉक में किसी भी रेखा के लिए एक संकेतक खोजने के लिए पर्याप्त है - और तालिका मिल गई है!



लेकिन इतना सरल नहीं ... या बल्कि, हमेशा इतना सरल नहीं। बिंदुओं की खोज में बाधा डालने वाली कठिनाइयों में से एक को "ऑफसेट अंतर" कहा जाता है। तथ्य यह है कि सूचक न केवल निरपेक्ष हो सकता है (संसाधन के तार्किक या भौतिक पते को इंगित करता है), बल्कि सापेक्ष (कुछ पते के लिए ऑफसेट के सापेक्ष संकेत)। या, कहें, जैसे कि PlayStation जैसे पुराने डिस्क कंसोल पर, डेटा को अक्सर मेमोरी में लोड करने के लिए तैयार किए गए फॉर्म में संग्रहीत किया जाता है - अर्थात। जब वे फ़ाइल में होते हैं, तो यह पता लगाना असंभव है कि सूचक उस पते को जाने बिना इंगित करेगा कि डाउनलोड कहां होगा।

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

 //    char* strings[] = {...}; //     ... struct Message { int characterId; int messageType; char* string; }; Message messages[] = {...}; 

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

तालिकाओं के उपयोग के बिना पॉइंटर्स निष्पादन योग्य फ़ाइल में कोड स्थान पर बिखरे हुए होंगे, और कभी-कभी एक कॉपी में नहीं। यदि पाठ को एक जगह संग्रहीत किया जाता है, तो इस समस्या को हल करके और प्रत्येक पंक्ति की शुरुआत में सभी बिंदुओं को ढूंढकर हल किया जा सकता है। और ज्यादातर मामलों में यह मुश्किल नहीं है - पते की जगह की प्रकृति के कारण, पॉइंटर मूल्य और एक अन्य मूल्य के बीच टकराव की संभावना न्यूनतम है (उदाहरण के लिए, स्मृति 0x08000000-0x09FFFFFF सीमा में संबोधित की जाती है या डेटा अनुभाग 0x00472000 पता के साथ शुरू होता है)।





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

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

पाठ निष्कर्षण

---

तालिकाओं से पाठ को "निकालने" का तरीका अनुवादकों के संगठन के स्तर पर निर्भर करता है। तो, सबसे असंगठित लोग (आमतौर पर शुरुआती) बिल्कुल भी परेशान नहीं होते हैं और पाठ को सीधे हेक्स संपादकों में अनुवाद करते हैं। थोड़ा और अधिक गंभीर - वे निकालने के लिए PokePerevod या समान Translhexion जैसे सभी-सौदा कार्यक्रमों का उपयोग करते हैं। गहरे ज्ञान वाले लोग क्रुटर जैसे अधिक विशिष्ट स्वचालन उपकरणों का उपयोग करते हैं। सबसे उन्नत विशेषज्ञ आमतौर पर इसके लिए अपनी स्क्रिप्ट या टूल लिखते हैं, जो उन्हें पूरी तरह से प्रक्रिया को नियंत्रित करने की अनुमति देता है।

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



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

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

 1E40=[size=0] 1E41=[size=1] 1E42=[size=2] ... 1E4F=[size=15] 

इसलिए, इस प्रारूप के लिए कई ऐड-ऑन हैं - मैंने अपना स्वयं का एक्सटेंशन भी विकसित किया है, जिसने मुझे मापदंडों के साथ मार्कअप कोड और अन्य बाइट्स का वर्णन करने की अनुमति दी है, और इसमें समर्थित निर्देशों जैसे शामिल हैं (यह अलग-अलग भाषाओं के लिए तालिकाओं के होने पर सुविधाजनक है, लेकिन उनके समान तत्व हैं) ।

एक विस्तारित प्रारूप में एक उदाहरण तालिका पर विचार करें:

 ;   escape- ( \n  ..) .format ;      ( ) ;    ,     C2A5=[Av-0] C2B3={Hero} ;    ,  «»   ("~") ;    (  ,    ..) C2B7C391~=\n-> C2B7~=\n- ;   —    ,  «»  "^" ;      ...   :) C28E^=\n ;    .include opcodes.tbl .include avatars.tbl ;    ( -  C string),  «»   ;  ,          , ;        0D!= 

टेबल में कुछ गड़बड़ होने के बावजूद, आउटपुट एक खेल स्क्रिप्ट के लिए बहुत साफ पाठ था:

जेनिका: मैंने इस महल में काफी सेवा की है
कुछ समय। मैंने दोनों राजकुमारी की देखभाल की
लेनना और राजकुमारी सरिसा।
-
[Av-0] {हीरो}: सरिसा?
->
जेनिका: राजकुमारी लेनना की बड़ी बहन।
सरिसा जब अपने पिता के साथ नौकायन कर रही थी
एक तूफान मारा, और वह समुद्र में खो गया था।

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

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

बाइटकोड निर्देश को कुछ बिट्स के कुछ मानों द्वारा पहचाना जाता है। मान लीजिए कि हमारे पास दो बाइट आकार के निर्देश हैं। एक निर्देश के लिए, चार में से एक बिट 0101 , अर्थात्। वह 0101nnnn की तरह 0101nnnn ; दूसरे पर, पहले दो बिट्स 11 , अर्थात्। हम इसे 11nnnnnn रूप में 11nnnnnn । एक निर्देश की पहचान करने का सबसे आसान तरीका मुखौटा तुलना है - अर्थात। बिट मास्क द्वारा मान्यता प्राप्त कोड का तार्किक गुणन करना आवश्यक है, जिससे आवश्यक बिट्स पर प्रकाश डाला जा सके, और परिणाम की तुलना संदर्भ डेटा (बाद में निर्देश पहचानकर्ता के रूप में संदर्भित) के साथ की जा सकती है। इस प्रकार, पहले निर्देश के लिए, मुखौटा 11110000 होगा, क्योंकि हमें केवल पहले 4 बिट्स लेना चाहिए, और पहचानकर्ता क्रमशः 01010000 होगा। दूसरे निर्देश के लिए, मुखौटा और पहचानकर्ता दोनों 11000000 ।



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

एन्कोडिंग तालिका में इस तरह के एक निर्देश रिकॉर्ड का रूप इस प्रकार है:

 <OpcodeMask>?<OpcodeID>:<ValuesMasks>=<FormatString> 

जहाँ OpcodeMask मुखौटा है, OpcodeID पहचानकर्ता है, ValueMasks मापदंडों के लिए बिट मास्क की अल्पविराम से अलग की गई सूची है, और FormatString निर्देश के पाठ प्रतिनिधित्व को प्रारूपित करने और इसे वापस करने के लिए इसे बिटकोड (यह प्रिंटफ फ़ंक्शन के लिए प्रारूपित स्ट्रिंग का एक संशोधित समकक्ष है) के लिए स्ट्रिंग है।

उदाहरण के लिए, हमारे पास फॉर्म 1010iiii cccccccc का एक निर्देश है, जो पॉप-अप विंडो में आइटम नंबर i के साथ रंगों को दिखा रहा है। चलो इसे "पॉपअप (आइटम, रंग)" कहते हैं। इस निर्देश का मुखौटा 11110000 00000000 , जो हेक्साडेसिमल प्रतिनिधित्व में 11110000 00000000 होगा। निर्देश पहचानकर्ता 10100000 00000000 बराबर होगा, अर्थात C000 , और पैरामीटर मास्क क्रमशः 00001111 00000000 और 00000000 11111111 , 0F00 और 00FF ।

हमें ऐसा कोडित टेक्स्ट दें:
0000: 4F 62 74 61 69 6E 65 64 20 61 6E 20 69 74 65 6D Obtained an item
0010: 21 C1 0F 0A 4E 6F 77 20 79 6F 75 20 63 61 6E 20 !##\nNow you can
0020: 6F 70 65 6E 20 74 68 65 20 64 6F 6F 72 2E open the door.

आइए इसे एक तालिका का उपयोग करके इसे डिकोड करने का प्रयास करें जिसमें ऐसी प्रविष्टि है:

 F000?C000:0F00,00FF=popup(%d, %d) 

हमें निम्न परिणाम मिलते हैं:

एक आइटम प्राप्त किया! पॉपअप (1, रंग)
अब आप दरवाजा खोल सकते हैं।

पाठ के साथ बहुत अच्छी तरह से संयुक्त नहीं है। इसलिए, हम टैग की मदद का सहारा लेने की कोशिश करेंगे। इसे XML टैग होने दें:

 F000?C000:0F00,00FF=<popup item="%d" color="%d"/> 

पहले से बहुत बेहतर:

एक आइटम प्राप्त किया! <पॉपअप आइटम = "1" रंग = "255" />
अब आप दरवाजा खोल सकते हैं।

लेकिन यह और भी बेहतर होगा अगर हम "जादू की कमी" के बजाय मापदंडों के एक पाठीय प्रतिनिधित्व को देखें। ऐसा करने के लिए, मैंने फॉर्म में स्थानान्तरण घोषित करने की क्षमता का परिचय दिया:

 %{<member1>[=value],<member2>[=value],...} 

मान लीजिए कि यह निर्देश केवल तीन मदों पर लागू होता है: नंबर 0 के साथ बम, नंबर 1 के साथ एक कुंजी और नंबर 10 के साथ एक सिक्का:

 F000?C000:0F00,00FF=<popup item="%{Bomb,Key,Coin=10}" color="#%2x"/> 

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

फिर हमें केवल टैग हाइलाइटिंग चालू करने की आवश्यकता है और हम अधिक या कम पठनीय पाठ प्राप्त कर सकते हैं:

 Obtained an item!<popup item="Key" color="#0F"/> Now you can open the door. 

यदि निर्देशों का शब्दार्थ इतना महत्वपूर्ण नहीं है (यानी अनुवाद उन्हें संपादित नहीं करता है), तो बेहतर है कि छोटे रिकॉर्ड का सहारा लिया जाए, अन्यथा कोड के कुछ स्थानों पर पाठ की तुलना में अधिक हो सकता है। उदाहरण के लिए, इस तरह:

एक आइटम प्राप्त किया! {पॉपअप: कुंजी, 0F}
अब आप दरवाजा खोल सकते हैं।

बिल्कुल एक पैरामीटर के निर्देशों के लिए, मैंने एक छोटा रिकॉर्डिंग फॉर्म प्रदान किया। निम्नलिखित दो समतुल्य तार हैं:

 FF00?3C00:00FF=<pause time="%d"> 3C??=<pause time="%d"> 

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

पाठ प्रस्तुति

---

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

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

जेनिका: मैंने इस महल में काफी ^ के लिए सेवा की है
कुछ समय। मैंने दोनों राजकुमारी ^ की देखभाल की
लेनना और राजकुमारी सरीसा। ^ {CLS}
[# C2] [# A5] [# C2] [# B3]: सरीसा? ^ {CLS} [# C3] [# 91]
जेनिका: राजकुमारी लेनना की बड़ी बहन। ^
सरिसा जब ^ के साथ अपने पिता के साथ नौकायन कर रही थी
एक तूफान मारा, और वह समुद्र में खो गया था। {END}

अनुवादक के स्थान पर, मैं कहूंगा: "और आप इसका अनुवाद कैसे करते हैं?"

काश, खंडित जानकारी को देखते हुए, यह आधिकारिक स्थानीयकरण की प्रक्रिया में भी होता है: यहां वे XML या INI प्रारूप में लाइन ब्रेक के रूप में "\ n" के साथ पाठ देंगे, और जैसा चाहें अनुवाद करें। इसी समय, ऐसे मामलों में भी बहुत से लोग वर्ड को नहीं बदलते हैं, जो किसी भी तरह के ऑटो-प्रतिस्थापन द्वारा लगभग किसी भी प्रारूप के कुछ संरचना को मारने में सक्षम है, या इससे भी बदतर है।

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

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

&push;&main-color=#E67E00FF;Energy Cell ID:&pop;
SN-3871S-7

&push;&main-color=#E67E00FF;Status:&pop;
&if=hasitem:Fuse7Used;Used&else;&if=hasitem:Fuse7;Acquired&else;Unknown&endif;&endif;&if=scan:SCAN,0x6479E69556A56AC8;
&if=(hasitem:Fuse7Used)|(hasitem:Fuse7);
&push;&main-color=#E67E00FF;Previous Coordinates:&pop;&else;
&push;&main-color=#E67E00FF;Coordinates:&pop;&endif;
&if=mapped:PirateCommand;04P-MET, Pirate Homeworld&else;04P-MET, Unknown&endif;

&just=left;Data indicates Energy Cell is connected to &push;&main-color=#FF6705B3;processing&pop; containment core.&endif;

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

इससे पहले, मैंने पाठ और अन्य डेटा को विघटित करने की कोशिश की थी, जितना कि विशिष्ट मामला अनुमति देता है। उदाहरण के लिए, टैग्स को "अलग कोड" में रखते हुए "{कोड}" या "{<group_number>}" जैसे एकल टैग के साथ समूहीकृत किया जा सकता है। लेकिन, चूंकि टैग पाठ से निकटता से संबंधित हैं, और इस तरह के समाधान से सिरदर्द केवल बढ़ता है, मैंने बाद में इसे मना कर दिया।

लेकिन अभी भी कोई रास्ता नहीं था, और इसमें सिंटैक्स हाइलाइटिंग शामिल है। क्योंकिचूँकि सभी तकनीकी डेटा को आमतौर पर आसानी से स्वचालित रूप से संसाधित किया जाता है, फिर बाकी पाठों के बीच उन्हें उजागर करना भी कोई समस्या नहीं है।

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


इसके साथ यह पहले से ही जीना संभव है। और कभी-कभी मैं और भी आगे बढ़ता गया और विज़ुअलाइज़र - प्रोग्राम लिखता था जो टेक्स्ट को खेल में देखने के तरीके को प्रदर्शित करता था। खैर, या लगभग एक ही ...


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

जारी रखा जाए

निम्नलिखित भागों में पढ़ें:

• एल्गोरिदम का विश्लेषण - एल्गोरिदम को निर्धारित करने के लिए किन तरीकों का उपयोग किया जाता है, इसके डेरिवेटिव्स का अध्ययन किया गया डेटा है।
• फाल्ट को कम करने के लिए वर्णों के चित्रमय प्रतिनिधित्व और साथ ही उन्हें संसाधित और संपादित करने के तरीकों को संग्रहीत करने और उपयोग करने के विभिन्न तरीकों के बारे में है।
• — , , .
• — , « ».
• — .
• — .
• — , .
• — , , .