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

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

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

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

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

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

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

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