कहानी की निरंतरता खोए बिना AI वर्ल्डबिल्डिंग बाइबिल कैसे तैयार करें

आपकी AI वर्ल्डबिल्डिंग बाइबिल में क्या होना चाहिए?

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

बाइबिल को छह परस्पर जुड़े वर्गों में व्यवस्थित करें:

स्प्रेडशीट, लिंक्ड दस्तावेज़ों, या ऐसे डेटाबेस का उपयोग करें जिसे आप आसानी से बनाए रख सकें। संस्थाओं (एंटीटीज़) को LOC-01 और CHAR-02 जैसी स्थिर ID दें; डिस्प्ले नाम और उपनामों (उर्फ़) को अलग-अलग फ़ील्ड में रखें। "ग्लास ऑब्जर्वेटरी" का नाम बदलने से उसके स्थान रिकॉर्ड के हर संदर्भ में गड़बड़ी नहीं होनी चाहिए।

कथा सारांशों को लेज़र के सुविधाजनक दृश्यों (व्यूज़) के रूप में देखें। जब कोई सारांश किसी अंतर्निहित रिकॉर्ड से मेल न खाए, तो स्रोत की जाँच करें और किसी भी संस्करण से लेखन शुरू करने से पहले उस विरोधाभास को हल करें।

किसी तथ्य का स्वामी कौन है, और क्या चीज़ उसे कैनन बनाती है?

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

स्वामित्व के साथ-साथ स्रोत उत्पत्ति (प्रोवेनेंस) भी दर्ज करें। W3C का PROV विवरण (https://www.w3.org/TR/prov-overview/) प्रोवेनेंस को किसी चीज़ के निर्माण में शामिल संस्थाओं, गतिविधियों और लोगों की जानकारी के रूप में परिभाषित करता है। कहानी की बाइबिल पर लागू होने का अर्थ है यह सुरक्षित रखना कि कोई कथन कहाँ से शुरू हुआ, वह कैसे बदला, और उसे किसने स्वीकार किया। यहाँ दिया गया लेज़र इसी सिद्धांत को अपनाता है; यह कोई औपचारिक PROV कार्यान्वयन नहीं है।

प्रत्येक रिकॉर्ड को एक स्पष्ट स्थिति (स्टेटस) दें:

मौजूदा पांडुलिपि को आयात करते समय, AI को सटीक दृश्य संदर्भों और छोटे सहायक उद्धरणों के साथ संभावित तथ्यों को निकालने दें। संदर्भों की स्वयं जाँच करें। किसी पात्र का यह कहना कि "वेधशाला हमेशा बंद रहती है" केवल यह स्थापित करता है कि यह कथन कहा गया था; यह अपने आप कोई वस्तुनिष्ठ नियम स्थापित नहीं करता।

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

समयरेखा और स्थानों को एक साथ कैसे ट्रैक करें?

कहानी के समय को संशोधन के समय से अलग दर्ज करें। "पुल दिन 6 को बंद होता है" एक घटना का वर्णन करता है। "लेखक ने संशोधन 4 में पुल के बंद होने की तारीख बदल दी" एक संपादकीय निर्णय का वर्णन करता है। इन दोनों को मिलाने से यह अस्पष्टता पैदा होती है कि दुनिया बदली है या उसका विवरण सुधारा गया है।

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

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

इस स्पष्ट रूप से उदाहरणात्मक निरंतरता जाँच पर विचार करें: एक कूरियर सुबह 09:00 बजे बाग से निकलता है, उसे वेधशाला तक पहुँचने के लिए तीन घंटे चाहिए, और एक लेंस लेने में 30 मिनट और लगते हैं। सबसे पहले वह 12:30 बजे पहुँच सकता है। कूरियर को दोपहर 12:00 बजे वहाँ दिखाने वाला दृश्य इन इनपुट्स के साथ मेल नहीं खाता, जब तक कि कोई स्वीकृत अपवाद लागू न हो।

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

आप दुनिया की सच्चाई और पात्र के ज्ञान को अलग कैसे करते हैं?

ज्ञान के रिकॉर्ड को वस्तुनिष्ठ तथ्यों से अलग रखें। हर महत्वपूर्ण खुलासे के लिए, पात्र, तथ्य या विश्वास, ज्ञान प्राप्ति की घटना, समय और किसी भी शाखा की शर्त को दर्ज करें। "जानता है," "संदेह है," "गलत मानता है," और "नहीं सीखा है" में अंतर करें। रिकॉर्ड न होने का मतलब यह है कि ज्ञान दर्ज नहीं है; यह अज्ञानता को साबित नहीं करता।

इंटरएक्टिव कथाओं में इसका सीधा समानांतर रूप देखने को मिलता है। Inkle का आधिकारिक ink ट्यूटोरियल (https://www.inklestudios.com/ink/web-tutorial/) कहानी के पहले देखे गए हिस्सों के आधार पर सशर्त टेक्स्ट और विकल्पों को दर्शाता है। यह कस्टम वेरिएबल्स का भी वर्णन करता है। ये तंत्र जानकारी तक पहुँच को प्रदर्शित कर सकते हैं, हालाँकि लेखकों को अभी भी यह तय करना होगा कि किसी दृश्य में जाने से वास्तव में पात्र को कोई विशेष तथ्य पता चलता है या नहीं।

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

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

एक पुन: प्रयोज्य निरंतरता लेज़र

निम्नलिखित फ़ील्ड का उपयोग स्प्रेडशीट कॉलम के रूप में या अपने नोट्स में दोहराए जाने वाले रिकॉर्ड के रूप में करें। प्रति रिकॉर्ड एक स्वतंत्र रूप से संशोधित करने योग्य दावा रखें। ये उदाहरण पूरी तरह से वर्कफ़्लो को समझाने के लिए गढ़े गए हैं।

यहाँ तीन जुड़े हुए रिकॉर्ड्स का एक संक्षिप्त दृश्य दिया गया है। पूर्ण लेज़र में प्रत्येक पंक्ति के लिए ऊपर दिए गए साक्ष्य और स्वामित्व फ़ील्ड शामिल होंगे।

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

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

ड्राफ्टिंग के दौरान AI को बाइबिल का उपयोग कैसे करना चाहिए?

एक सीन पैकेट तैयार करें जिसमें लक्षित दृश्य का समय, स्थान, दृष्टिकोण (viewpoint), शाखा, प्रासंगिक कैनन रिकॉर्ड और अनसुलझी निर्भरताएँ शामिल हों। केवल दृश्य के कीवर्ड साझा करने वाली प्रविष्टियाँ ही नहीं, बल्कि जुड़ी हुई पूर्व-आवश्यकताओं को भी शामिल करें। दरवाज़े का एक दृश्य किसी अन्य स्थान पर पहले हुए प्रदर्शन पर निर्भर हो सकता है।

इस पुन: प्रयोज्य निर्देश जैसे प्रॉम्प्ट का उपयोग करें:

संलग्न निरंतरता रिकॉर्ड और उनके बताए गए संशोधन के आधार पर दिए गए दृश्य की समीक्षा करें। प्रत्येक संभावित विरोध के लिए, दृश्य के अंश को उद्धृत करें और प्रासंगिक रिकॉर्ड ID की पहचान करें। इसे विरोधाभास, गायब जानकारी, या प्रस्तावित जोड़ के रूप में वर्गीकृत करें। कालक्रम, यात्रा, स्थान तक पहुँच, पात्र के ज्ञान और शाखा की शर्तों की जाँच करें। अनसुलझे प्रश्नों को सुरक्षित रखें। सुधार के सुझाव अलग से दें; कैनन को न बदलें और न ही मनगढ़ंत स्रोत संदर्भ बनाएं। यह बताएं कि दी गई सामग्री से कौन सी जांच पूरी नहीं की जा सकी।

रचनात्मक कार्य के लिए, स्पष्ट सीमाओं के भीतर विकल्पों की मांग करें: "F-014 को बदले बिना या E-008 से पहले मीरा को ज्ञान दिए बिना उसमें देरी करने के तीन तरीके सुझाएं।" वांछित वातावरण, गति और परिवेश की विशेषताओं का वर्णन अपने शब्दों में करें।

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

इतिहास को मिटाए बिना रेटकॉन को कैसे संभालें?

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

संस्करण इतिहास (वर्जन हिस्ट्री) पिछली स्थितियों को पुन: प्राप्त करने योग्य बनाता है। Git की आधिकारिक पुस्तक का वर्ज़न कंट्रोल से परिचय (https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) बताता है कि वर्ज़न कंट्रोल कैसे परिवर्तनों को रिकॉर्ड करता है, तुलना का समर्थन करता है, और पिछले संस्करणों को वापस लाने की अनुमति देता है। Git एक विकल्प है; यदि कोई अन्य दस्तावेज़ प्रणाली आपके काम के लिए अधिक उपयुक्त है जिसमें उपयोगी इतिहास की सुविधा हो, तो उसे चुनें। अलग से यह दर्ज करें कि कोई कथा-संबंधी निर्णय क्यों बदला गया।

प्रत्येक प्रस्तावित रेटकॉन के लिए:

एक पुन: प्रयोज्य चेंज-लॉग प्रविष्टि में चेंज ID, संशोधन तिथि, निर्णयकर्ता, कारण, पुराना रिकॉर्ड, प्रतिस्थापन रिकॉर्ड, प्रभावित सामग्री और सत्यापन स्थिति होनी चाहिए। उदाहरण के लिए: "CH-006 दो संरेखित डिस्क की आवश्यकता का प्रस्ताव करता है; F-014, E-008, K-009 और S-12 को प्रभावित करता है; निर्णय लंबित।" केवल स्वीकृति का मतलब यह नहीं होगा कि उन निर्भर दृश्यों को पहले ही ठीक कर लिया गया है।

किसी दृश्य को स्वीकार करने से पहले आपको क्या जाँचना चाहिए?

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

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

इस विषय को आगे पढ़ें