कभी-कभी आपको खुद को क्यों पीटना पड़ता है?

शुभ दिन मेरा नाम इल्या है और मैं एक पूर्णतावादी हूं।

अधिकांश स्टार्टअप की मुख्य समस्याओं में से एक यह है कि वे कभी भी स्टार्टअप नहीं बनते हैं: वे बस अपनी पहली परियोजना को पूरा करने में सक्षम नहीं हैं। कुछ फ्रीलांसरों द्वारा इसी तरह की कठिनाइयों का अनुभव किया जाता है - वे हमेशा समय पर परियोजना को पूरा करने के लिए नहीं निकलते हैं।

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

एक महीने पहले, हमारी टीम, जिसमें डेढ़ डिजाइनर और डेढ़ कोडर शामिल थे, ने हाई-स्पीड गेम डेवलपमेंट पर क्षेत्रीय चैम्पियनशिप में पहला स्थान हासिल किया। विकास को केवल 48 घंटे दिए गए थे। दो दिन, पूरी तरह से कॉफी और नसों से मिलकर, प्रतियोगिता की परियोजनाओं में सबसे पूरा हुआ। मैं आपको बताऊंगा कि मुझे अपने साथ क्या करना था और सही कोड लिखने की मेरी इच्छा जो लोगों को दिखाने के लिए डरावना नहीं होगा।



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

टीके के बिना काम करें। प्रारंभिक चरण

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

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

गौटिंग की एक लहर, या जब नियोजन को रोकना और करना शुरू करना है।

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

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

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

इसे ज़्यादा मत करो

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

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

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

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

पूर्णता, रिलीज़ पथ

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

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

Postreliz। पैच और रीफैक्टरिंग

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

और आप पहले से ही जानते हैं कि अगले प्रोजेक्ट को कैसे करना है।

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

PPS: यदि कोई हमारा गेम खेलने के लिए उत्सुक है: लिंक का अनुसरण करें । अगर किसी को वास्तव में दिलचस्पी है: अगले लिंक पर आप मेरी प्रस्तुति के लिए स्लाइड पा सकते हैं