ऑनलाइन खेल: कैसे, या मैं कैसे एक लड़की प्रोग्रामर के साथ बहस की

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

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



इस अवधि के अंत में, परियोजनाओं को "मूल्यांकन समिति" को सौंप दिया गया, जो हमारे पारस्परिक मित्र थे। और ... मेरा प्रोजेक्ट नहीं जीता। और उस समय सबसे अधिक आक्रामक यह लगा कि विवाद की स्थितियों के अनुसार, मुझे अपने खेल के विकास में अपने प्रतिद्वंद्वी की मदद करने के लिए एक और सप्ताह का कार्य समय आवंटित करना था। लेकिन एक तर्क एक तर्क है!

शुरू कर दिया

संयुक्त विकास की शुरुआत में हमारे पास क्या था? हाँ, लगभग कुछ भी नहीं! सिर में अवधारणा और स्रोत कोड का एक सा। साथ ही, दो लोगों की एक "टीम"। प्रोग्रामिंग मरीना द्वारा किया गया था। मैंने यूजर इंटरफेस विकसित करना शुरू किया।



"दासता" का मेरा सप्ताह बहुत तेज़ और दिलचस्प था। बग्स को ठीक किया गया और कई नई सुविधाएँ लागू की गईं। यह सप्ताह समाप्त हो गया, और मैं अपने हाथ धो सकता था, लेकिन ... परियोजना वास्तव में दिलचस्प बन गई, और हमने इसके विकास को जारी रखने का फैसला किया।



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

1 सप्ताह - अवधारणा

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



क्या अवधारणा थी? बस वाक्यांशों और वाक्यों का एक सेट ("जोर से विचार"), जिसमें, शायद, केवल हम अर्थ देख सकते थे। लेकिन, इसके बावजूद, इसमें सभी मुख्य बिंदुओं को बताया गया था, और परियोजना की विकास क्षमता रखी गई थी। इस पर पहला सप्ताह समाप्त हो गया।

2 सप्ताह - काम की शुरुआत, पहली गलतियाँ

मैं प्रोजेक्ट पर काम करना चाहता था। अपडेट वाली फाइलें अक्सर साबुन और ICQ पर फेंक दी जाती हैं। ग्राफिक्स के साथ कोड और psd-shki के पुराने संस्करणों को हटा दिया गया और पत्राचार किया गया, जैसे कि उन पर खर्च किए गए शाम भी नहीं थे।



प्रत्येक घर का अपना सर्वर कॉन्फ़िगर किया गया था, जहां काम किया गया था। काम के इस सिद्धांत को क्यों चुना गया? सब कुछ बहुत सरल है - खुद के लिए निर्धारित समय सीमा बहुत कम है, लेकिन मैं बहुत कुछ करना चाहता था, इसलिए हमने बेकार पर समय बर्बाद नहीं करने का फैसला किया, जैसा कि हमें तब लगा, एक साझा सर्वर और काम के अन्य सिंक्रनाइज़ेशन की स्थापना। मेरे सिर में केवल एक चीज थी: "केवल 3 सप्ताह बचे हैं ... खर्च करने का समय भी जब यह नहीं है।"

लेकिन सप्ताह के अंत तक हमने कैसे काम किया और सब कुछ करने का फैसला किया क्योंकि इसे तुरंत किया जाना चाहिए।

3 सप्ताह - तोड़फोड़ और रीफैक्टरिंग

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



इसके अलावा, मजबूत इरादों वाले फैसलों में से एक था इस तथ्य के बावजूद कि कम और कम समय बचा था।

उदाहरण के लिए, शुरुआत में, गेम मैप को नेविगेशन तीरों (विवेकपूर्वक) का उपयोग करके नियंत्रित किया गया था, और खेल की दुनिया के हिस्सों को एक बड़े कदम के साथ टुकड़ों में प्रदर्शित किया गया था।



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

और इस कोड को लगभग पूरी तरह से फिर से लिखे जाने के बाद, यह काफी अधिक कार्यों का प्रदर्शन करते हुए, 70% छोटा हो गया।

4 सप्ताह - पहली लाइन ली गई

शेष सप्ताह के लिए, समय सीमा समाप्त होने से पहले, उन्होंने लगभग वह सब कुछ पूरा कर लिया जो वे चाहते थे। कुछ के पास समय नहीं था, कहीं बहुत ज्यादा था। लेकिन, इस तथ्य के बावजूद कि किसी विशेष कार्यक्षमता के कार्यान्वयन पर निर्णय सहज स्तर पर किए गए थे, विकल्प हमेशा लगभग सही निकला। हमारे पहले परीक्षकों ने शुरू किए गए परिवर्तनों की सराहना की।



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

5-7 सप्ताह - ट्यूड्यूलिस्ट और बहुत सारे काम

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



सबसे पहले, उन्होंने विशेष ऑनलाइन सेवाओं की ओर रुख किया, जो सहयोग में मदद करने वाली थीं। कई कोशिश करने के बाद, हमें यकीन हो गया था कि वे सब हमारे अनुरूप नहीं हैं। कुछ को कार्यक्षमता के साथ ओवररेट किया गया था, जबकि अन्य, इसके विपरीत, कुछ गायब थे, दूसरों को भुगतान किया गया था।



अंत में, हमने googledocs के पक्ष में सेवाएँ छोड़ दीं। वांछित कॉलम के हाइलाइटिंग को समायोजित करके, हमें एक बहुत ही सुविधाजनक टूडू-सूची मिली।



यह वह जगह है जहाँ मुख्य काम उबलने लगा। कार्य सक्रिय रूप से बंद थे। अब हमने प्रगति देखी है, उत्साह दिखाई दिया है। और इससे विकास की गति में उल्लेखनीय वृद्धि हुई है।



इस स्तर पर, हमें एक वैचारिक गलती का सामना करना पड़ा: हमने कई बड़े, अनिर्दिष्ट कार्यों की रूपरेखा तैयार की।

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



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



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



महीना व्यर्थ नहीं गया - बहुत कुछ फाइनल हो गया। परीक्षण पहले ही स्पष्ट रूप से अधिक सफलता के साथ पारित हो चुका है।

8 वें सप्ताह - पेरेटो सिद्धांत, कई परिणाम

मुझे लगता है कि आपको 80/20 नियम के बारे में बात नहीं करनी चाहिए, जिसके बारे में आपने पहले ही सुना होगा। मैं आपको केवल यह बताऊंगा कि हम इस समस्या में कैसे भागे, और हम आपत्तिजनक 20% परिणाम के साथ कैसे लड़े।



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



चैट करें। यहां सब कुछ सरल है। कार्य को दो चरणों में विभाजित करने का निर्णय लिया गया - 80/20। प्रारंभ में, एक नियमित चैट बनाई गई थी, जहां आप संदेश भेज सकते थे। सरल और तेज: सर्वर कोड की 40 लाइनें और एक दर्जन क्लाइंट कोड। निजी और निजी संदेश, प्रतिबंध आदि जैसी चीजें। बाद के लिए स्थगित कर दिए गए।



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



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



सप्ताह का परिणाम यह था कि हमने उपयोगी 80% लागू किया था, और शेष 20% बाद में स्थगित कर दिए गए थे।

सप्ताह 9 - पेरेटो सिद्धांत, कुछ परिणाम

सप्ताह की शुरुआत कठिन थी। हमारे कार्य 20% परिणामों में शामिल थे। लेकिन हम क्या कर सकते हैं ... और फिर हमने एक अप्रत्याशित, लेकिन बहुत सुखद खोज की। यह पता चला है कि हमारे कार्यों को दो डेवलपर्स के बीच समान रूप से विभाजित किया गया था, जबकि अतिव्यापी नहीं। इससे काम से एक दूसरे को विचलित किए बिना कार्यों के कार्यान्वयन को पूरा करना संभव हो गया।



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

10-13 सप्ताह - बहुत सारे गंदा कीड़े

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



बदले में, प्रतिगमन त्रुटियों ने हमें स्पष्ट कर दिया कि स्वचालित परीक्षण लिखना जीवन को बहुत आसान बनाता है। लेकिन यह अगला कदम है।

निष्कर्ष:

1) यदि परियोजना में कोड की सौ से अधिक लाइनें होंगी - एक तैयार अवधारणा है। यदि कोड की 1000 से अधिक लाइनें - एक लिखित अवधारणा है।

2) अवधारणा को बदलने से डरो मत, लेकिन इसका दुरुपयोग न करें। सब कुछ छोड़ते हुए जैसा कि आप करते हैं, "आप धारा में नहीं मिल रहे हैं।" अन्यथा, आप अपना प्रोजेक्ट कभी पूरा नहीं करेंगे।

3) संस्करण नियंत्रण प्रणालियों का उपयोग करने के लिए आलसी मत बनो, भले ही आपको लगता है कि परियोजना कोड की 100 लाइनों में फिट होगी।

4) रिफ्लेक्टर से डरो मत, भले ही यह आपको लगता है कि उत्पाद कल समाप्त हो जाएगा और समर्थन की आवश्यकता नहीं होगी।

5) बड़े कार्यों को छोटे, मूर्त में तोड़ो। वे अधिक दिलचस्प और अधिक उत्पादक हैं।

6) रिग्रेशन टेस्ट लिखना न भूलें।

7) प्रोग्रामिंग के बारे में भी लड़कियों से बहस न करें। खासकर अगर यह आपको लगता है कि उनसे प्रोग्रामर खराब हैं :)



सर्वर अस्थायी रूप से नीचे था, इसके लिए तैयार नहीं थे।

जीवन में लौट आए।



और अंत में, हमारे प्रोग्रामर, काम पर :)