ऐसा गेम डिज़ाइन डॉक्यूमेंट कैसे लिखें जिसे लोग वास्तव में पढ़ें

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

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

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

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

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

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

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