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

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

1. यदि आप 2-3 सप्ताह में प्रोटोटाइप पूरा नहीं कर सकते, तो आप 1 वर्ष में गेम पूरा नहीं कर सकते

जब डैनियल ने हमें Realities.io के लोगों के इस “व्यावहारिक कानून” के बारे में बताया, तो हमारी प्रतिक्रिया मूलतः यह थी:

यह “कानून” (जिसे Realities.io द्वारा तैयार किया गया है) शाह) बहुत दिलचस्प है क्योंकि यह एक सामान्य नियम के रूप में सत्य है: यह पज़लिंग प्लेसेस के लिए सत्य था, और यह बीट सेबर के लिए भी सत्य था। मुझे स्पष्ट रूप से याद है कि मैंने पढ़ा था कि बीट सेबर का प्रोटोटाइप कुछ सप्ताह में तैयार कर लिया गया था, और फिर टीम ने वास्तविक गेम को जारी करने से पहले लगभग एक वर्ष का समय बिताया।

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

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

2. कम वादा करना, कम प्रदर्शन करना

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

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

मैं 10 साल से XR स्टार्टअप्स में हूं और मैंने देखा है कि हर बार, हर परियोजना में अपेक्षा से कहीं अधिक समय लगता है, और अंत में, आपको डिलीवरी की तारीख से पहले ही सुविधाओं में कटौती करने के लिए मजबूर होना पड़ता है। हर कोई हमेशा डिलीवरी को लेकर बहुत तनाव में रहता है क्योंकि बहुत कम समय में हमेशा बहुत सारे काम करने होते हैं। समय और समय के बारे में यथार्थवादी होना शायद अधिक समझदारी भरा होगा कुछ ऐसी सुविधाओं को अधिक प्रदान करने का प्रयास न करें जो वैसे भी उपलब्ध नहीं होने वाली हैं। इसके विपरीत, संभवतः सबसे अधिक यहां तक ​​कि समय की कमी के कारण “सामान्य प्रसव” के लिए पूर्वानुमानित कुछ सुविधाओं में भी कटौती करनी पड़ती है, इसलिए शायद कम प्रदर्शन के लिए भी योजना बनाना अधिक समझदारी भरा कदम होगा।

बिल्कुल, यह आलसी होने का सुझाव नहीं होना चाहिए: महत्वाकांक्षी होना और सीमा से आगे बढ़ने की कोशिश करना हमेशा अच्छा होता है। लेकिन साथ ही, समय के बारे में बहुत यथार्थवादी होना महत्वपूर्ण है।

3. अपने काम का दायरा अच्छी तरह परिभाषित करें

डैनियल गेमिंग ट्रैक के मेंटर थे। उन्होंने हैकाथॉन में भाग लेने वाली टीमों के साथ टेबल पर घूमे और उनकी सबसे कीमती सलाह में से एक थी कार्य के दायरे को बहुत अच्छी तरह से परिभाषित करना।

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

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

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

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

जब आपके संसाधन सीमित हों, तो अपने कार्य का दायरा निर्धारित करना ही सही रास्ता है।बहुत अधिक करने की कोशिश मत करो, जो महत्वपूर्ण है उस पर ध्यान केंद्रित करो।

4. केवल उन उत्पादों के लिए प्रतिबद्ध रहें जो “क्लिक” करते हैं

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

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

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

कहानी का दूसरा सबक बहुत अधिक सूक्ष्म है और यह इस बारे में है जब आप भावनात्मक रूप से अपने प्रोटोटाइप के प्रति प्रतिबद्ध हों तो उसका मूल्यांकन न करना। जब आप कुछ करते हैं, तो वह चीज़ आपकी बच्ची होती है, इसलिए आप भावनात्मक रूप से उससे बंधे होते हैं: बेशक, जैसे ही आप इसे आज़माएँगे, आपको यह पसंद आने लगेगा। और शायद जब कोई इसकी आलोचना करता है तो आप नाराज़ हो जाते हैं। लेकिन यह किसी व्यवसाय का मूल्यांकन करने का स्वस्थ तरीका नहीं है: आपको अपने दिल से नहीं, बल्कि दिमाग से सोचना होगा। और यही कारण है कि Realities.io की टीम ने प्रोटोटाइप बनने के बाद कुछ समय तक उसका मूल्यांकन करने का इंतज़ार किया। कुछ हफ़्तों के बाद, आप अपने एप्लीकेशन के प्रति प्रतिबद्ध नहीं होते, इसलिए आप फिर से वही करते हैं जो आपने नए नज़रिए से किया था, और आप यह मूल्यांकन करने में अधिक तर्कसंगत हो सकते हैं कि यह अच्छा है या नहीं। और यदि यह फिर से “क्लिक” करता है, तो इसका मतलब है कि संभवतः आपने जो किया वह वास्तव में अच्छा है और आप इससे व्यवसाय बना सकते हैं।

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

(शीर्षक छवि द्वारा मैपबॉक्स से unsplash)