Android के लिए टिक-टीएसी-पैर की अंगुली का सामान्य कार्यान्वयन

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

परिचय

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

विचार

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

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

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

खेल का नाम और इसी तरह के खेल के लिए खोज

खेल बनाने से पहले, मैंने जल्दी से इसी तरह के खेलों की तलाश की। एंड्रॉइड के तहत, मुझे ऐसा कोई गेम नहीं मिला। मैंने गेम को "टिक-टैक-टो" + ड्राइंग कहने का सोचा। चूंकि एंड्रॉइड के लिए बहुत सारे टिक टीएसी पैर की अंगुली हैं, इसलिए मैंने इस मुश्किल को कम करने का फैसला किया, गेम बनाने का छोटा चरण और काम के प्रोटोटाइप के तैयार होने के बाद अंतिम नाम के साथ आना। काम के प्रोटोटाइप के बाद, मैंने गेम का नाम लिखना शुरू कर दिया। फिर, "टिक-टैक-टो" का अंग्रेजी में अनुवाद किया, और "ड्रा" शब्द उन्हें डाल दिया, मैंने पाया, शायद, ड्राइंग के साथ टिक-टैक-टो का एकमात्र प्रतियोगी। मुझे खेल के नाम पर "ड्राइंग" को शामिल करने की आवश्यकता थी। ड्रॉ शब्द पर विचार करने और गेम के नाम में ड्राइंग के बारे में शब्द को शामिल करने की आवश्यकता पर, खेल का नाम "टिक-टैक-टो ड्राइंग" रखने का निर्णय लिया गया था! यदि आप कहते हैं कि नाम दूसरों के साथ बहुत मेल खाता है, तो आप Google टिक में केवल 250 से अधिक टिक-टैक-टो का भुगतान कर सकते हैं, और 1000 से अधिक मुक्त कैसे कर सकते हैं?

कार्यान्वयन

UPD: खेल की विशेषताएं जिन्हें लागू करना आवश्यक था:

• खिलाड़ी आकृतियाँ, तैयार आकृतियों की मान्यता
• खेल मैदान के विभिन्न आकार: 3x3 से 12x12 तक (यह संभव है और अधिक है, लेकिन कई उपकरणों के स्क्रीन आकार प्रतिबंध लगाते हैं)
• तदनुसार, खेल एक पंक्ति में केवल 3 नहीं है, बल्कि एक पंक्ति में 4, 5, 6 भी है

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

विकास पर्यावरण और सृजन की सामान्य योजना का विकल्प

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

खेल का विकास

कार्यक्रम विकास चक्र

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

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

उपरोक्त चरणों में से प्रत्येक का जीवन चक्र:

1. बुनियादी आवश्यकताओं की एक सूची का संकलन
2. प्रोग्रामिंग
3. परिणाम और डिबगिंग की जाँच करना। कार्यक्रम के जीवन के साथ असंगत त्रुटियों की पहचान करते समय , पैराग्राफ 1 पर जाएं)

अगले चरण में, एल्गोरिदम पूर्ण किए गए थे। इन सुधारों का चक्र ऊपर वर्णित के समान है:

1. लिस्टिंग के मुद्दे
2. प्रोग्रामिंग
3. परिणाम और डिबगिंग की जाँच करना। अब मैं देख रहा था कि क्या सुधार किया जा सकता है।

मूल रूप से, ये सुधार फिगर रिकग्निशन और बॉट के खेल से संबंधित थे, जिसे बाद में लिखा जाएगा। दूसरे चरण में, गेम को ग्रहण में चित्रित किया गया था और एंड्रॉइड के लिए GUI का निर्माण शुरू हुआ। एंड्रॉइड के साथ इंजन की संगतता के साथ समस्याएं थीं। साधारण जावा में, कैनवस (ग्राफिक्स) के निर्देशांक एंड्रॉइड, फ्लोट में हैं। साथ ही, कई ड्राइंग फ़ंक्शंस और क्लासेस (Canvas = Drawable, इत्यादि) के नाम और drawLine के लिए डेटा संरचना में अंतर है। मुझे एक "प्रारूप कनवर्टर" (बैसाखी) लिखना था और डेटा प्रकारों के नामों को बदलना था। मैं एक घंटे से अधिक समय में यह सब करने में कामयाब रहा, क्योंकि मुख्य रूप से नामों में अंतर था, और तर्क में नहीं। फिर आगे के चित्र थे, चित्र बनाने और नए जीयूआई के एकीकरण के बाद, परीक्षण और डिबगिंग शुरू हुई। इन सुधारों का जीवन चक्र ऊपर के समान है। :

1. खेल की जाँच: विभिन्न स्क्रीन आकार, खेल के साथ एक एमुलेटर पर चल रहा है।
2. लिस्टिंग के मुद्दे
3. समस्याओं को ठीक करें

यह प्रक्रिया तब तक जारी रही जब तक यह तय नहीं हो गया कि खेल में कोई खामियां नहीं थीं। पहला संस्करण, संस्करण 1.0 जारी किया गया था।

कैसे AI लिखा गया

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

कोड

जावा में खेल के कोड के बारे में संक्षेप में: कुल मिलाकर, स्रोत कोड 275 kB है, जिसमें से 75% इंजन हैं। कोड को तीन पैकेजों में विभाजित किया गया है, लगभग 22 वर्गों का उपयोग किया जाता है। कोड की केवल 5670 लाइनें, लेकिन बहुत सारी टिप्पणियां, टिप्पणी वाले हिस्से और खाली लाइनें, इसलिए लगभग 4000 शुद्ध कोड हैं, प्रति वर्ग औसत 250 लाइनें (फ़ाइल)। मुख्य इंजन कुछ हफ़्ते में लिखा गया था, इसे एक सप्ताह में त्वरित किया जा सकता है। कोड लिखते समय, खतरनाक स्थान जहां एक त्रुटि हो सकती है (उदाहरण के लिए, निर्माण बहुत भ्रामक निकला), मैंने टिप्पणियों के साथ चिह्नित किया // FIXME और //DDO। टिप्पणियों की एकाग्रता: कोड की प्रति 400 लाइनों में से एक FIXME और कोड की 60 लाइनों के बारे में 1 TODO। जब परीक्षण प्रक्रिया के दौरान खामियों का पता चला था, तो मुझे तुरंत पता था कि इन पंक्तियों में क्या ठीक करना है या क्या त्रुटियां हैं। इसके अलावा, प्रत्येक रिलीज़ से पहले, मैंने गेम का परीक्षण किया, विभिन्न सेटिंग्स के साथ 5-10 बार खेल रहा था।परिणाम एक विश्वसनीय अनुप्रयोग था, जैसा कि "विफलताओं और ANR" रिपोर्ट द्वारा स्पष्ट किया गया था। हालांकि, इसके लिए अभी भी स्पष्टीकरण हैं: कोशिश - कैच ब्लॉक का उपयोग किया गया था, जो बहुत अच्छा नहीं है, लेकिन कुछ मामलों में जब यह विफल हो जाता है, तो एप्लिकेशन को स्वचालित रूप से "प्रयोगात्मक" फ़ंक्शन को अक्षम करना चाहिए और अपने पुराने संस्करणों पर स्विच करना चाहिए; या यह पृष्ठ Google के लिए काम नहीं करता है; या बहुत कम लोग खेल का उपयोग करते हैं।

विज्ञप्ति और अनुवाद

एंड्रॉइड के लिए अनुप्रयोगों का अनुवाद बहुत सरल है: सभी तार स्ट्रिंग्स में संग्रहीत किए जाते हैं। xml फ़ाइल, जो मान फ़ोल्डर में स्थित है। डिफ़ॉल्ट भाषा अंग्रेजी है। रूसी भाषा (और अन्य) को जोड़ने के लिए, आपको मान-आरयू फ़ोल्डर बनाने की आवश्यकता है, और स्ट्रिंग्स की एक प्रतिलिपि बनाएँ। xml फ़ाइल, जिसमें अनुवादित स्ट्रिंग प्रतिस्थापन शामिल होंगे। एप्लिकेशन की सभी पंक्तियां एपीआई के माध्यम से प्राप्त की जाती हैं। अनुवाद में तेजी लाने के लिए, आप इलेक्ट्रॉनिक अनुवादकों का उपयोग कर सकते हैं, उदाहरण के लिए, मैंने ट्रांसलेटर का उपयोग किया है। खेल के अनुवाद से पहले, मुझे अंग्रेजी भाषा के अपने ज्ञान के बारे में पता नहीं था, अनुवाद के बाद, अंग्रेजी के ज्ञान में अनिश्चितता को Google अनुवादक को स्थानांतरित कर दिया गया था। अनुवाद करते समय, न्यूनतम, मूल भाषा में आपके द्वारा प्राप्त वाक्यों का अनुवाद करने का प्रयास करें। और बेहतर है, स्वयं शब्दों का अनुवाद करें और अनुवादक के अनुवाद के साथ तुलना करें। ऐसे मामले थे जब एक कंप्यूटर अनुवादक ने अर्थ को बहुत अधिक विकृत कर दिया और कुछ शब्दों को अर्थ में दूसरों के रूप में स्वीकार कर लिया। आवेदन का अंग्रेजी में अनुवाद किया गया था, इसलिए दो भाषाओं के लिए समर्थन था। मैं आपको डाउनलोड पर अनुवाद के प्रभाव के बारे में अधिक बताऊंगा। खेल की पहली रिलीज 9 दिसंबर 2012 की शाम को हुई थी। अगले दिन, आंकड़ों में, मैंने देखा कि पहले दिन 1 डाउनलोड हुआ था। रिलीज़ होने से पहले, मैंने सोचा कि पहला संस्करण देने के लिए कौन सी संख्या है: 0.99 या 1.0? चूंकि मैंने फैसला किया कि एमुलेटर पर लगभग सब कुछ काम करता है और मैं इस पर खेल सकता हूं, मुझे 1.0 नंबर देने का अधिकार है। मैं तब बहुत गलत था, क्योंकि कई उपयोगकर्ताओं ने शिकायत की कि वे इस गेम को नहीं खेल सकते हैं। उपयोगकर्ताओं ने शिकायत की कि उनके पास गेम में बड़े ब्रेक थे, अन्य जो ग्राफिक्स सही तरीके से प्रदर्शित नहीं हुए थे। और वे सही थे, 90% वास्तविक उपकरणों को खेलना असंभव था। ब्रेक के साथ समस्या इस तथ्य के कारण थी कि ग्राफिक्स को पूरे ड्रॉएबल कैनवास को फिर से तैयार करके तैयार किया गया था, और इस पर बहुत सारे संसाधन खर्च किए गए थे। मुझे जल्दी से एक समाधान की तलाश करनी थी, और यह पाया गया था। नहीं, OpenGL के माध्यम से नहीं। आप पूरे कैनवास (रेपेंट (), ऑनपेंट ()), और टुकड़े (रेपेंटक्लिपिंग) (ऑनपेंट (रेक्ट)) दोनों को फिर से तैयार कर सकते हैं। मुझे आवश्यक रेड्रावा क्षेत्रों को निर्धारित करने के लिए खेल सीखना था, और अग्रिम में रेड्रा जोन की योजना बनाना (कॉम्प्लेक्स ओवरलैपिंग ज़ोन, अलग-अलग रेडर ज़ोन)। कुछ लोगों के इन सभी सुधारों और सुझावों को एक नए संस्करण में एकत्र किया गया था, जिसे एक सप्ताह बाद जारी किया गया था। प्रत्येक अद्यतन के दौरान, मैंने सोचा था कि प्रत्येक पिछला संस्करण खराब था और इसे खेलना असंभव था, और नया एक सबसे अच्छा है, और एक भी कमी नहीं है। .Testing रिलीज केवल एमुलेटर पर ही किए गए थे। यह उपकरण केवल दो उद्देश्यों के लिए मेरे लिए उपयोगी था: 1) यह महसूस करने के लिए कि यह कितना टेढ़ा है कि एमुलेटर नहीं दिखा; 2) मल्टीटच का परीक्षण करने के लिए। जब ​​तक मैंने विकसित किया और इतने लंबे समय तक खेल का परीक्षण किया, तब तक मुझे आंकड़े भी आकर्षित करने की आदत थी, और यह नहीं देखा कि सभी खिलाड़ी ऐसे आंकड़े भी नहीं खींचते हैं, इसलिए अक्सर आंकड़ों को मान्यता नहीं मिली। इसलिए, जब मैंने अपने दोस्तों को खेलने दिया, तो मुझे आश्चर्य हुआ कि कार्यक्रम लगभग उनके चित्र को नहीं समझ पाया। मुझे फिर से मान्यता में सुधार करना पड़ा। चूँकि गेम पेज पर बदलावों की एक सूची है, इसलिए मैं अपडेट करके मुख्य समस्याओं को सूचीबद्ध करूँगा। संस्करण 1.1: चूंकि सतह को एक अतिभारित दृश्य के रूप में लागू किया गया था और संपूर्ण कैनवास को फिर से तैयार किया गया था, इसलिए ग्राफिक्स धीमा हो गया। पेंटक्लिपिंग () के लिए समर्थन लागू किया गया था, जिसने पूरी स्क्रीन को फिर से तैयार करने की अनुमति नहीं दी, लेकिन केवल बदलते हिस्से, जिसने ड्राइंग को तेज किया। निम्नलिखित अद्यतन: इसे अक्षम करके चलती एनिमेशन के साथ निश्चित समस्याएं; डिजाइन; मल्टी टच; रिकॉर्ड। पहली अनुकूलन: मैंने देखा कि मैंने गलती से 2 बार रेंडरिंग बचाई, मैंने एक ही चीज़ को 2 बार चित्रित किया; caches का उपयोग करके अनुकूलन।

संकलक त्रुटियां? क्या वे आते हैं?

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

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

अलग से, मैं अंतर्निहित ProGuard के बारे में कहना चाहता हूं। बहुमत की राय के विपरीत, यह काम करता है, लेकिन शर्तों के साथ: एसडीके के रास्ते में, होम फ़ोल्डर, प्रोजेक्ट और उसके नाम के साथ फ़ोल्डर, कोई स्थान या सिरिलिक नहीं होना चाहिए। तब यह काम करता है (Project.properties में आवश्यक लाइनों को अनसुना करने के लिए मत भूलना)। आप मैन्युअल रूप से ऑबफिकेशन को पूरा कर सकते हैं (मुझे यह तब तक करना पड़ा जब तक मैंने प्रोगार्ड को समायोजित नहीं किया)। ऐसा करने के लिए, पहले प्रोजेक्ट की एक प्रति बनाएँ। फिर हम प्रोजेक्ट सेटिंग्स पर जाते हैं (जहां इसे जोड़ने के लिए) और "क्लास कंपाइल जेनरेशन" समूह में "जावा कंपाइलर" अनुभाग में अनावश्यक चेकमार्क को अनचेक करें। अगला, "रिफ्रैक्टर> मूव ..." और "रिफ्रैक्टर> नाम बदलें ..." टूल का उपयोग करके हम कोड को कुछ समझ से बाहर कर देते हैं। जैसा कि आप इस प्रक्रिया के माध्यम से आगे बढ़ते हैं, कोड के अवशिष्ट प्रदर्शन की जांच करना याद रखें।

ग्राफिक्स

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

सांख्यिकी और विपणन

मुझे खेल के माध्यम से पैसा मिलने की उम्मीद नहीं थी, इसलिए मैंने कहीं भी इसका विज्ञापन नहीं किया। इसके अलावा, मैंने विज्ञापन के अभाव में वास्तविक आंकड़े एकत्र करने का निर्णय लिया, इसलिए कभी-कभी मैंने इसे बढ़ावा भी नहीं दिया, लेकिन इसे बढ़ावा देने के लिए कुछ प्रयास किए गए थे।

पदोन्नति

4PDA. ( +15 — +40), , . , , (+10), Google Play (+2). , , , , . - , - «.com», - .

Google Play

वे कहते हैं कि आपको Google Play पर एकल समीक्षाओं और रेटिंग के बारे में चिंता करने की आवश्यकता नहीं है। यह ऐसा है - लोग अलग-अलग हैं, अलग-अलग राय रखते हैं, किसी को लगता है कि आप जितना सोचते हैं उससे कुछ अलग है। खेल का वर्णन न पढ़ें, जिससे कोई ऐसी चीज़ डाउनलोड हो, जिसकी किसी को ज़रूरत न हो, या कोई दिलचस्प खेल याद न हो। , , « », «» (« 2»), . , . , . , , 5000 1000 e-mail 5 : 4 — ( , 100$ 60000$). Opera Mobile Store (apps.opera.com), , , Google Play.

SEO

पहले पदों के लिए प्रतिस्पर्धा अधिक है, विशेष रूप से इस तरह के खेल की शैली में "टिक-टैक-टो"। लगभग एक ही नाम के साथ हजारों, हजारों समान टिक-टैक-टो हैं। उनमें से बहुत सारे हैं, क्योंकि उन्हें "हैलो दुनिया" की तुलना में लिखना थोड़ा मुश्किल है। यह समझा जाता है कि उपयोगकर्ता बीसवीं से अधिक फ्लिप करने के लिए परेशान नहीं करेंगे , (3000/20=100...). … ( 20 ), , 70% . , , , . , «-» 20 , «- » , , . , « », « » , . « » 3,636 ( ). , , , , , , . , , , - . : ? : (58%), ( 20% + 11% + 2% = 33% ), (3%), 6%. , ; , ; , . चार्ट रूसी में हरा दिखाता है, अन्य दो लाइनें अंग्रेजी में हैं। रूसी-बोलने वाले उपयोगकर्ताओं के तेज वृद्धि का मुद्दा खेल के वर्णन के लिए "दो के लिए" के अलावा है। "पहेली" खंड में भाषा के उपयोग पर औसत आंकड़े (Google Play डेवलपर कंसोल में प्रदान किए गए): लोग खेल के पृष्ठ पर कैसे आते हैं, कौन इसे डाउनलोड करता है और कौन खेल छोड़ता है? यह निम्नलिखित चित्र दिखाएगा।

वीडियो

« », , , . () — . . , , , ( ). google play, , . , , . 1,5 15 , ffmpeg. . . 2 , 1 48 (). , , 1 . / .

: 5113, 4017 (78%), 1096. 10 ( ): 56 , 22 , 34 (+3,4 ). , 4PDA. . 10 , 20 . . , . UPD: 2 13000 , «». : 13000 1% , .: +180 (1,38% ). Android 4.1 4.2. , 50 . , 43% (40% , 70% ). 1110 1230, 120 ( , , 0,8% ). , 3-4 . , .मैंने देखा कि अगर कुछ उपयोगकर्ता व्यक्तिगत संचार (फोरम थ्रेड्स, लेख) द्वारा उत्पाद में शामिल होते हैं, तो टिप्पणियों और रेटिंग की संख्या बढ़ जाती है। इस लेख के प्रकाशन के कारण, खेल पर Google Play पर बहुत सारी समीक्षाएं दिखाई दीं, और वास्तविक दोषों की आलोचना के बावजूद समीक्षाएँ सकारात्मक थीं, जिन्हें ठीक करने की आवश्यकता है।मोबाइल उपकरणों से सभी विचारों में प्रति दिन केवल 7 वीडियो की वृद्धि हुई। अजीब तरह से पर्याप्त है, वे वीडियो की तुलना में गेम के बारे में मेरी साइट पर पृष्ठ पर अधिक दिखते हैं। ई-मेल पर पहले दो अक्षर उन लोगों से आए जिन्होंने गेम को स्थापित करने की कोशिश की। इससे पहले, केवल स्पैम आया था।

खेल और अन्य सामग्री बनाने के लिए उपयोग किए जाने वाले कार्यक्रमों की सूची

विकास पर्यावरण:

• NetBeans
• ग्रहण (+ Android SKD)

चित्र और वीडियो:

• GIMP - रेखापुंज ग्राफिक्स संपादक
• इंकस्केप - वेक्टर संपादक
• ओपनशॉट - वीडियो एडिटर
• ffmpeg - स्क्रीन से वीडियो कैप्चर करने के लिए उपयोग किया जाता है

विकास लिनक्स के अंतर्गत था, ये सभी कार्यक्रम निशुल्क हैं।

लागत

विकास, ग्राफिक्स, सॉफ़्टवेयर के लिए 0 (शून्य) साइट समर्थन, बैंकिंग संचालन और Googlelaylay डेवलपर खाते के लिए ~ $ 30 से अधिक। मुझे क्या मिला: 0 रूबल, एंड्रॉइड एप्लिकेशन विकसित करने में अनुभव, Google Play पर गेम इंस्टॉल करने के आंकड़े, एक अच्छा लेख।

निष्कर्ष में

आप एक सरल और अच्छा गेम बनाने के लिए कंप्यूटर, $ 30 और समय दे सकते हैं। एक अच्छे खेल के लिए, आपको गेमप्ले (विचार) और एक ही समय में एक सुंदर कार्यान्वयन (ग्राफिक्स) दोनों की आवश्यकता होती है। बहुत से उपयोगकर्ताओं को अर्जित करने के लिए , आपको वह करने की आवश्यकता है जो उपयोगकर्ताओं को चाहिए, भले ही उन्हें यह संदेह न हो कि यह मौजूद है, और जो अभी भी नहीं है, हजारों tic-tac-toe से कम प्रतिस्पर्धी क्षेत्र में भी ऐसा ही करें। अब खेल मुफ्त है, विज्ञापनों के बिना , इसके लिए किसी भी अतिरिक्त अनुमति की आवश्यकता नहीं है (उदाहरण के लिए, व्यक्तिगत डेटा एकत्र करना, सशुल्क एसएमएस भेजना आदि)। (Google Play पर गेम पेज पर क्लिक करने योग्य)