ड्रीम-टीम ZeptoLab टीम में एक जगह के लिए एंड्रॉइड और आईओएस डेवलपर-एस के बलों की प्रतियोगिता के लंबे समय से प्रतीक्षित परिणाम, आखिरकार, सारांशित हैं। पिछले छह महीनों में, हमने वादा किया है कि हमने किया: हम 2 गुना बढ़ चुके हैं और हमारे मठ को वैचारिक रूप से डिजाइन किया है:
कैसा था 
उसी अवधि के दौरान, हम एक बार फिर से केवल शासन की पुष्टि करने के लिए पर्याप्त काम देखने में कामयाब रहे: बहुत कम विशेषज्ञ हैं, और वे छिप रहे हैं। स्थिति के सुधार में योगदान करने के लिए, हमने इन दो मोबाइल प्लेटफार्मों पर विकासशील खेलों के मुख्य बिंदुओं के विषय में टिप्पणियों को साझा करने का निर्णय लिया: कुछ बिंदुओं के लिए, अपनी सिफारिशें दें, हमने एंड्रॉइड और आईओएस विकास गुरुओं और स्वागत से टिप्पणियों के लिए भी जगह छोड़ दी।
याद रखें कि प्रोग्रामर के लिए हमारा परीक्षण कार्य Android के लिए iOS और NDK के लिए ऑब्जेक्टिव-सी का उपयोग करके आर्कानॉइड गेम का प्रोटोटाइप विकसित करना था।
IOS के लिए भेजे गए कार्यों के अनुसारआइओएस के लिए अरकानोइड्स की एक संक्षिप्त समीक्षा के साथ शुरू करते हैं (वे काफी अधिक भेजे गए थे) - सबसे यादगार और खुलासा:
1. मूल विचार।
सुविधाजनक प्रबंधन।
अच्छी टक्कर संभाल।
मंच के किनारों के करीब, गेंद की दिशा बदल जाती है
2. सुंदर ग्राफिक्स। सुविधाजनक प्रबंधन। बहुत तेज गेमप्ले। अच्छी टक्कर संभाल।
3. आदिम पर आधारित सरल ग्राफिक्स।
सुविधाजनक प्रबंधन।
अच्छी टक्कर संभाल।
पिंच जेस्चर प्रभावित करता है
खेल की गति।
जैसे-जैसे आप आगे बढ़ेंगे
बनावट नीचे से उभरती है
शिलालेख "वाना गो ज़ेप्टो" के साथ
4. केवल 3 डी में पूरा किया गया कार्य और हमें भेजा गया =)
5. एटलस का उपयोग।
फ़्रेम-बाय-फ़्रेम एनीमेशन।
सुविधाजनक प्रबंधन।
सुंदर ग्राफिक्स।
6. एक सुंदर परीक्षा कार्य, एक पुराने स्कूल टेट्रिस की शैली में बनाया गया।
उपयुक्त ध्वनि संगत।
सुविधाजनक प्रबंधन।
7. एक बहुत ही सुंदर परीक्षण कार्य, यह लगभग एक तैयार परियोजना की तरह दिखता है।
सुविधाजनक प्रबंधन।
अच्छी टक्कर संभाल।
फास्ट गेमप्ले।
8. मूल कार्य और केवल एक जिसमें एक भूखंड है (एक कर्मचारी के साथ एक जादूगर शहर को orcs से बचाता है)।
अच्छा फ्रेम-बाय-फ्रेम कैरेक्टर एनीमेशन।
सामान्य गलतियाँ:1. मेमोरी लीक। दुर्भाग्य से, स्वचालित संदर्भ गणना तकनीक के उपयोग के बिना किए गए लगभग सभी कार्यों में मेमोरी लीक थी।
2. टकराव से निपटने। कई कार्यों में, गेंद क्यू बॉल में या "ईंटों" में फंस जाती है। सबसे अधिक ध्यान देने वाली बात यह है कि यह बहुत ही तंग स्तरों पर हुआ है। इसके अलावा, सबसे अधिक बार यह पहली बार लॉन्च में देखा गया था। लगभग सभी कार्यों में, प्रसंस्करण फ्रैमर्ट पर निर्भर करता था।
3. प्रबंधन। कभी-कभी नियंत्रण को एक स्वाइप जेस्चर या एक्सेलेरोमीटर पर लटका दिया जाता था, और क्यू बॉल के साथ इसे नियंत्रित करना बहुत मुश्किल हो जाता था। बेशक, इस बिंदु को पूरी तरह से त्रुटियों के लिए जिम्मेदार नहीं ठहराया जा सकता है, इसलिए हमने इसके लिए ठीक नहीं किया। लेकिन, फिर भी, हमारी राय में, सबसे सुविधाजनक नियंत्रण तब है जब क्यू बॉल आपकी उंगली का सख्ती से पालन करती है।
4. आवेदन वास्तुकला। कभी-कभी दो अति होते थे। या तो जब पूरे आवेदन का मुख्य कोड एक कक्षा में था, या इसके विपरीत, यह पचास वर्गों के तहत बनाया गया था, जो इस आवेदन के लिए पूरी तरह से अनावश्यक है।
5. कोड में सकल त्रुटियां। वे अक्सर ओओपी के सिद्धांतों के उल्लंघन से जुड़े होते हैं। सौभाग्य से, ऐसी बहुत कम त्रुटियां थीं।
6. कभी-कभी विभिन्न तृतीय-पक्ष रूपरेखाओं का उपयोग करते हुए कार्य किए जाते थे, उदाहरण के लिए Cocos2D। ऐसे कार्यों को तत्काल समाप्त कर दिया गया।
7. ऐसे कार्य भी थे जो अतिरिक्त जोड़तोड़ के बिना शुरू नहीं करना चाहते थे। यह प्रोजेक्ट सेटिंग्स के कारण सबसे अधिक बार होता है। उदाहरण के लिए, संसाधनों को वैश्विक रास्तों के साथ जोड़ा गया है। यदि ऐसी त्रुटि को 5 मिनट के भीतर ठीक किया जा सकता है, तो प्रतियोगिता से कार्य वापस नहीं लिया गया था।
8. संकल्प। कोड में, अक्सर एक विशिष्ट रिज़ॉल्यूशन से जुड़े कई मैजिक नंबर होते थे। अन्य प्रस्तावों के अनुसार, सब कुछ बाहर चला गया।
9. पुनः आरंभ करें। एक आवेदन जब रोका गया तो बस रुका हुआ। स्तर को पुनरारंभ करने के लिए, आपको संपूर्ण एप्लिकेशन को पुनरारंभ करना होगा।
यह भी काफी गलती नहीं है, लेकिन यह इस तरह के कार्य के मूल्यांकन को जटिल बनाता है।
सुखद से:सुखद trifles से प्रसन्न कुछ कार्य: साउंड डिज़ाइन, स्टाइलिश ग्राफिक्स, सुंदर एनीमेशन। खूबसूरती से डिजाइन की गई परियोजना को देखना निश्चित रूप से अच्छा है, और इस तरह की परियोजना को अच्छी तरह से याद किया जाता है, लेकिन हम मुख्य कार्य एल्गोरिथ्म के पॉलिश होने तक विभिन्न सुंदर चीजों को जोड़ने को स्थगित करने की सिफारिश करेंगे। क्योंकि, सबसे पहले, यह ठीक से संगठन और कोड की पठनीयता, प्रसंस्करण टकराव के लिए एल्गोरिदम, नियंत्रण की सुविधा और कार्यान्वयन, और, निश्चित रूप से, त्रुटियों की संख्या को ध्यान में रखता था।
Android के लिए भेजे गए कार्यों के अनुसारइस तथ्य के बावजूद कि एंड्रॉइड के लिए विकास के लिए आईडीई की पहुंच की सीमा कुछ हद तक अधिक है, और हार्डवेयर आवश्यकताओं को iOS के लिए Xcode से कम है, इस OS के लिए परीक्षणों के कुल प्रवाह का लगभग एक चौथाई भेजा गया था। इसे आंशिक रूप से डिफ़ॉल्ट आईडीई (हम सभी ग्रहण का मतलब है) में मूल वातावरण के लिए सामान्य एकीकृत डिबगर की कमी से समझा जा सकता है, आंशिक रूप से प्रोग्रामर के लिए कम से कम 2 प्रोग्रामिंग भाषाओं को जानने के लिए: सी ++ और जावा, या जल्दी से उन्हें समझने में सक्षम होने के लिए।
इस तथ्य को पहली बार भेजे गए स्रोत कोड से कई लोग Android विकास में पारंगत थे। साथ ही, कई प्रोग्रामरों ने ईमानदारी से पत्रों और साक्षात्कार में इसका उल्लेख किया। हमने ऐसे परीक्षण मामलों को अधिक सख्ती से नहीं देखा, क्योंकि हमने डेवलपर्स को इस तथ्य के लिए प्रेरित नहीं किया कि यह एंड्रॉइड के लिए उनका पहला प्रोजेक्ट है। हर कोई एक समान पायदान पर था।
पहली बार, मूल वातावरण के साथ काम करते हुए इस परियोजना के आधार ने एंड्रॉइड एनडीके के साथ आपूर्ति किए गए उदाहरणों का उपयोग किया - एक बढ़िया तरीका काम करने वाली परियोजना को प्राप्त करने के लिए ताकि निर्माण करने के लिए कुछ हो। अधिक अनुभवी प्रोग्रामर ने अपने पुस्तकालयों और सर्वोत्तम प्रथाओं का उपयोग किया है जो अन्य पुस्तकालय आकर्षित करते हैं। नतीजतन, परियोजना के स्रोत कोड की मात्रा कभी-कभी परिमाण के आदेशों से बढ़ जाती है, और हमारे पास विश्लेषण के लिए पर्याप्त सामग्री थी। वैसे, सबसे हल्के "प्रोजेक्ट" में स्रोत कोड की मात्रा 14 किलोबाइट बनाम 1.6 मेगाबाइट (केवल कोड!) सबसे "भारी" है। वैसे, सबसे आसान कोड का लेखक अभी भी हमारी टीम में शामिल हो गया है
कार्यक्रम के लिए मुख्य आवश्यकताओं में से एक किसी भी स्क्रीन रिज़ॉल्यूशन के तहत सही संचालन था। एंड्रॉइड के मामले में, आईओएस की तुलना में यह आवश्यकता अधिक महत्वपूर्ण है, क्योंकि डिवाइस अनुमतियों की सूची "थोड़ी" लंबी है: (इस विषय पर उपयोगी लेख:
Openignalmaps.com/reports/fragmentation.php ) और उन सभी के लिए 2 शर्तें पूरी होनी चाहिए:
1. सामान्य रूप से भौतिकी और गेमप्ले का व्युत्क्रम। सीधे शब्दों में कहें, यदि आप उपयोगकर्ता के कार्यों को रिकॉर्ड करते हैं (उदाहरण के लिए, स्क्रीन को छूना अगर इस तरह की नियंत्रण विधि को चुना गया था) सापेक्ष निर्देशांक में और उन्हें किसी अन्य डिवाइस पर खेलते हैं, तो स्तर का मार्ग नहीं बदलना चाहिए।
2. दृश्य भाग में स्वीकार्य परिवर्तन।
विभिन्न लेखक इन स्थितियों से अलग-अलग तरीके से निपटते हैं।
छवि का एक सरल स्केलिंग स्पष्ट रूप से उपयुक्त नहीं है, क्योंकि यह एक गोल गेंद (या एक वर्ग के बजाय एक आयत, जो कुछ कार्यों में एक गेंद की भूमिका निभाई थी) के बजाय एक दीर्घवृत्त प्रदर्शित करता है।
कुछ प्रोग्रामर ने सबसे छोटे रिज़ॉल्यूशन के लिए पिक्सेल में खेल के मैदान के आकार को लागू किया, और बड़े उपकरणों पर स्क्रीन के केंद्र या कोने में खेल के मैदान को प्रदर्शित किया।
वैसे, विभिन्न उपकरणों पर ओपनजीएल कोड का उपयोग करके एक गेंद को प्रदर्शित करने का बहुत ही कार्य अपने आप में तुच्छ नहीं है। कुछ ने एक बनावट का उपयोग किया, जो स्क्रीन के आकार में वृद्धि के साथ दृश्यता खो गया; कुछ ने गेंद को प्रोग्रामिक रूप से आकर्षित किया। वैसे, हम इस विषय पर उदासीन फेरीवालों की टिप्पणियों को नहीं सुनकर खुश होंगे: आप पहली सीमा (गेमप्ले के आक्रमण) को ध्यान में रखे बिना ओपनगैल की गेंद कैसे खींचेंगे?
कोड के बारे में थोड़ानीचे Android के लिए प्रस्तुत कुछ कार्यों के स्क्रीनशॉट हैं:
अर्कानॉइड का अच्छा कार्यान्वयन।
लेखक को ध्यान देना चाहिए
गेंद के व्यवहार पर जब
ब्लॉक से दूर धकेलना,
कोणों का संरक्षण
विरोध करता है। साथ ही समान में भी
गेम यह टूलबार को छिपाने के लिए वांछनीय है।
गेम में रेंडरिंग को लेकर समस्या है
फर्मवेयर 2.3.2 के साथ सोनी एक्सपीरिया प्ले।
बहुत दिलचस्प कार्यान्वयन। इस मामले में, हम एक एक्सेलेरोमीटर का उपयोग करके गुरुत्वाकर्षण नहीं बल्कि गुरुत्वाकर्षण को नियंत्रित करते हैं। मुझे उच्च एफपीएस और एनीमेशन में ट्विचिंग की कमी पसंद है। गेमप्ले काफी दिलचस्प निकला, और स्थितियों के हिस्से के रूप में एक ही समय में। लेखक को कुछ उपकरणों पर गेंद के आकार पर ध्यान देना चाहिए और फर्मवेयर 2.3.4 के साथ सैमसंग गैलेक्सी नोट और फर्मवेयर 4.0.4 के साथ गूगल नेक्सस एस को लॉन्च करने में समस्याओं का सामना करना चाहिए।
अर्कानॉइड का विहित कार्यान्वयन। क्लासिक गेमप्ले और समस्या की स्थितियों का सख्त पालन। बैट को एक्सीलेरोमीटर द्वारा नियंत्रित किया जाता है। पेशेवरों की, एक काफी चिकनी प्रतिपादन ध्यान दिया जा सकता है। Minuses की - बिट के निचले हिस्से के साथ टकराव के प्रसंस्करण में गलतियां और एक मामले की संभावना जब शुरू में गेंद की दिशा सख्ती से लंबवत सेट होती है - इस मामले में स्तर अगम्य हो जाता है।
ठोस कार्य, सर्वोत्तम कार्यान्वयन में से एक। सुविधाजनक नियंत्रण, अच्छा ग्राफिक्स और सामान्य में अच्छा गेमप्ले। गिरने वाले ब्लॉकों के एनीमेशन की उपस्थिति से प्रसन्नता से प्रसन्न। लेखक को उन मामलों में दीवारों से प्रस्थान के एक बड़े कोण पर गेंद के व्यवहार को देखना चाहिए जहां खिलाड़ी बार-बार गेंद को बिट के किनारे से टकराता है, प्रक्षेपवक्र के कोण को बढ़ाता है, और फर्मवेयर 2.3.6 के साथ सैमसंग गैलेक्सी नोट पर एप्लिकेशन की निष्क्रियता पर भी ध्यान देता है।
एक और अच्छा काम। यहां, सभी तत्व पिक्सेल शेड्स के साथ तैयार किए गए हैं, और जब स्तर पास हो रहा है, तो पुराने स्कूल के शेडर प्रभाव एक ला "90 के दशक से हैलो" है। प्लसस में से, एक गेमप्ले और उच्च एफपीएस की चिकनाई को भी नोट कर सकता है। कार्यक्रम सभी परीक्षण उपकरणों पर काम किया। लेखक को थोड़ा ऊपर उठाना चाहिए और स्पर्श क्षेत्र को कम करना चाहिए, क्योंकि उंगली एक छोटे से कवर करती है।
चूंकि पर्याप्त संख्या में विकल्प भेजे गए थे, इसलिए हमें उसी स्थानीय समस्याओं के समाधान की तुलना करने का अवसर मिला।
उदाहरण के लिए, गेंद को प्रदर्शित करने के अलावा, मानचित्र को आरंभ करने का कार्य सांकेतिक है।
किसी ने इसे इस तरह से चलाया (iOS):
const int स्तर [LD_HEIGHT] [LD_WIDTH] = {
{} 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
{} 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
{} 0,0,0,0,0,0,0,0,0,1,1,1,0,0,0,1,
{} 0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,1,
{} 0,0,0,0,0,0,0,1,1,1,1,1,1,0,0,1,
{} 0,0,0,0,0,0,1,1,1,1,1,1,1,1,0,1,
{} 0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,1,
{} 0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,1,
{} 0,0,0,0,1,1,1,1,1,1,1,1,1,1,0,1,
{} 0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,
{} 0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,
{} 0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,
{} 0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,
{} 0,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,
{} 0,0,1,1,1,1,1,1,1,1,0,0,0,0,0,0,
{} 0,0,1,1,1,1,1,1,1,0,0,0,0,0,0,0,
{} 0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,
{0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0}};
ऐसा कोई (Android):
for (int i = 0; मैं <MAP_W * MAP_H; ++ i)
(ब्लॉक [i] = नया ब्लॉक ()) -> init ((i% MAP_W - MAP_W / 2) * 0.2, (i / MAP_W) * 0.2, i% 3> 0? 1: 0, (i + 2) % 4> 0; 0.7: 0, (i + 3)% 5> 0; 0.9; 0);
और कोई ऐसा भी (iOS):
// नक्शा पीढ़ी
नक्शा [0,0] = 1;
मानचित्र [0,1] = 2;
मानचित्र [0.2] = 4;
नक्शा [0.3] = 1;
नक्शा [०.४] = २;
नक्शा [0.5] = 0;
नक्शा [0.6] = 3;
नक्शा [0.7] = 2;
नक्शा [1,0] = 1;
नक्शा [1,1] = 3;
नक्शा [1,2] = 0;
नक्शा [1,3] = 1;
नक्शा [1,4] = 2;
नक्शा [1,5] = 3;
मानचित्र [1,6] = 4;
नक्शा [1.7] = 2;
मानचित्र [२.०] = १;
नक्शा [2,1] = 0;
नक्शा [2,2] = 2;
नक्शा [2,3] = 3;
नक्शा [2,4] = 4;
नक्शा [2,5] = 3;
मानचित्र [२.६] = ०;
नक्शा [२. Map] = २;
...
नक्शा [4.7] = 1;
यह तुरंत स्पष्ट है कि किस कोड को स्पष्टता के उद्देश्य से लिखा गया था, जो - समस्या के समाधान में तेजी लाने के उद्देश्य से, और जो - किसी को आश्चर्यचकित करने के लिए।
इसके अलावा, जब से इस विषय को छुआ गया है, हम ऐसे कोड के बारे में फेरीवालों की राय में रुचि रखते हैं: ऐसे मामलों में जिनमें यह अस्तित्व का अधिकार है, और जिसमें यह इसे लूप (आईओएस कोड) के साथ बदलने के लायक है:
[player_pic addFrame: [UIImage imageNamed: @ "0.png"]];
[player_pic addFrame: [UIImage imageNamed: @ "1.png"]];
[player_pic addFrame: [UIImage imageNamed: @ "2.png"]];
[player_pic addFrame: [UIImage imageNamed: @ "3.png"]];
[player_pic addFrame: [UIImage imageNamed: @ "4.png"]];
[player_pic addFrame: [UIImage imageNamed: @ "5.png"]];
...
[player_pic addFrame: [UIImage imageNamed: @ "12.png"]];
IOS और Android प्लेटफार्मों की तुलना में, हम कह सकते हैं कि iOS के लिए कोड परिवर्तनशीलता अधिक स्पष्ट है - अपठनीय उदाहरण वास्तव में अपठनीय हैं, स्पेगेटी कोड अपने नाम तक रहता है, और अच्छी तरह से डिज़ाइन किए गए कार्य वास्तव में सुंदर दिखते हैं।
मैं आईओएस की तुलना में एंड्रॉइड प्रोग्रामर द्वारा समस्या के निर्माण के लिए एक कम रचनात्मक दृष्टिकोण को भी नोट करना चाहूंगा, जहां सिगरेट के बिट्स की मदद से मानव फेफड़े टूट गए थे (हालांकि विचार उधार लिया गया था), और टेट्रिस गोन, और यहां तक कि एक काल्पनिक कहानी वाला एक प्रोजेक्ट भी।
सामान्य तौर पर, कोड द्वारा: iOS और Android के लिए कार्यों की तुलना करते हुए, हमने कुछ इस तरह से देखा: iOS के लिए कोड कम प्रलेखित और काफी अक्सर गंदा है। किसी ने फ़ंक्शंस में ऑटो-जनरेट किए गए कमेंट्स को छोड़ दिया, जो मूल रूप से स्टब्स थे, जबकि अन्य ने बड़े मॉड्यूल को पूरी तरह से टिप्पणी की।
दोनों प्लेटफार्मों पर, KO टिप्पणियों की कमी की तरह
Void initGame(); //लेकिन अनिवार्य रूप से अधिक टिप्पणियां हो सकती थीं।
कार्यान्वयन में अशुद्धियों के बारे मेंप्रोग्रामर के लिए कार्य था: "एक बल्ले को नियंत्रित करना ... स्क्रीन पर एक निश्चित स्थान पर स्थित एक ईंट को तोड़ना"। कई ईंटों से युक्त कई ड्रू स्तर, यहां तक कि 3 डी विकल्प भी थे, और यहां तक कि असली बेसबॉल बैट के साथ एक विकल्प भी था।
परीक्षण कार्य एक तकनीकी कार्य नहीं है, हमने साहित्यिक अध्ययन नहीं किया, क्योंकि दोनों पक्ष समझते हैं कि परीक्षण कार्य क्या है। यदि प्रोग्रामर ने कुछ अधिक जटिल या दिलचस्प किया, तो यह केवल एक प्लस था। हालांकि, तैयार कार्य का कड़ाई से पालन भी एक प्लस था, और अपने आप में एक व्यक्ति के बारे में बहुत कुछ कहता है। लेकिन पहले से ही चुनी गई दिशा का गंभीरता से मूल्यांकन किया गया था, और यह मुख्य रूप से गेमप्ले के चयनित संस्करण में बग थे जिनका मूल्यांकन किया गया था।
कीड़ेलगभग सभी में कीड़े थे। कुछ हद तक, हमने प्रतिपादन में त्रुटियों को महत्व दिया, और हमने खेल इंजन में अशुद्धियों पर ध्यान दिया। यदि ग्राफ़ में त्रुटियां तुरंत ध्यान देने योग्य हैं, तो तर्क में त्रुटियां अधिक कपटी हैं। एक परीक्षण के माध्यम से, हमने ऐसे प्रोग्रामर्स की तलाश की जो तुरंत अच्छे कोड का उत्पादन कर सकें। इस मामले में, इसका मतलब टकरावों की सही हैंडलिंग, मेमोरी लीक की अनुपस्थिति और निश्चित रूप से, गेम क्रैश है।
तर्क में सामान्य त्रुटियां:1. ईंट से गेंद के प्रस्थान की दिशा का निर्धारण। जैसा कि यह निकला, इस तुच्छ कार्य को सावधानीपूर्वक परीक्षण की आवश्यकता थी, क्योंकि लगभग सभी में त्रुटियां थीं। सबसे आम दो हैं:
• गेंद एक्स और वाई कुल्हाड़ियों के साथ विपरीत दिशाओं में उड़ती है, अगर यह दो ईंटों के जंक्शन के कोने में गिरती है।
• गेंद घटना के कोण से अलग कोण पर ईंट से उड़ जाती है।
2. इस समय गेंद के व्यवहार की गलत गणना जब यह पहले से ही बिट के स्तर से गुजर चुका है, और बिट इसे कवर करता है। इस मामले में, कीड़े बहुत विविध थे, गेंद को स्क्रीन के नीचे से दूर धकेलने के लिए, जो सीधे समस्या के बयान का खंडन करता है।
एंड्रॉइड के लिए कोड में तर्क की त्रुटियों के अलावा, सिस्टम त्रुटियां थीं, मुख्य रूप से मेमोरी के साथ काम करते समय विशिष्ट त्रुटियां। उन्हें विस्तार से वर्णन करने का कोई मतलब नहीं है। किसी ने एप्लिकेशन को क्रैश नहीं किया।
निष्कर्षनीचे आदर्श कार्य का वर्णन है, जैसा कि हम देखते हैं:
1. टकराव। आदर्श रूप से, एक निरंतर टक्कर ट्रैकिंग सिस्टम यहां बनाया जाना चाहिए ताकि कम एफपीएस, आदि से जुड़ी कोई समस्या न हो।
2. कोई स्मृति लीक नहीं। iOS 5.0 अपनी तकनीक के साथ मेमोरी हैंडलिंग को सरल बनाता है - ऑटोमैटिक रेफरेंस काउंटिंग।
3. अच्छा अनुप्रयोग वास्तुकला। यह दिखाना अच्छा होगा कि आप जानते हैं कि ओओपी क्या है और इसे सही तरीके से कैसे उपयोग किया जाए।
4. सुविधाजनक प्रबंधन। इस कार्य में, जैसा कि यह हमें लगता है, सबसे सुविधाजनक नियंत्रण उंगली द्वारा मंच का सख्त पालन है। इसके अलावा, प्लेटफ़ॉर्म आपकी उंगली से ओवरलैप नहीं होना चाहिए (इसे स्क्रीन के नीचे से उठाया जा सकता है)। टच ज़ोन को पूरे स्क्रीन पर काम करना चाहिए ताकि उंगली के ऊर्ध्वाधर आंदोलनों के दौरान नियंत्रण खो न जाए। मल्टीटच यहां पूरी तरह से बेकार है, इसलिए त्रुटियों से बचने के लिए इसे बंद कर दिया जाना चाहिए।
5. वैयक्तिकता। यदि कार्य में कुछ उत्साह है - यह एक प्लस है।
इसके साथ, हम आधिकारिक तौर पर अर्कानॉइड प्रतियोगिता को बंद करने की घोषणा करते हैं। लेकिन जब से हमारी ड्रीम टीम कंपनी अपरिवर्तनीय रूप से बढ़ रही है, हम आईओएस और एंड्रॉइड प्लेटफॉर्म (लीड्स और साधारण, लेकिन प्रतिभाशाली) के लिए प्रोग्रामरों के एक नए सेट की घोषणा करते हैं और एक
नया कार्य प्रदान करते हैं
:पचमन का प्रोटोटाइप बनाना सबसे सरल संस्करण में आवश्यक है: एक भूलभुलैया है जिसमें हमारा चरित्र स्थित है, और एक राक्षस जो उसके साथ पकड़ने की कोशिश कर रहा है।
यदि हमने भूलभुलैया में बिखरे हुए सभी भोजन एकत्र किए - हम जीत गए, लेकिन अगर राक्षस ने हमें छुआ, तो हम हार गए। जिस तरह से आप चरित्र को नियंत्रित करते हैं वह आपके ऊपर है।
प्रोटोटाइप आवश्यकताएँ:
- ओपनिंग (किसी भी संस्करण) का उपयोग करके रेंडरिंग को लागू किया जाना चाहिए;
- खेल को iOS के मामले में Objective-C या C ++ में लिखा जाना चाहिए, या Android के मामले में NDK (C ++) का उपयोग करके (प्रोग्राम पूरी तरह से C ++ में होना चाहिए, जावा में केवल कोड बाइंडिंग हो सकता है), बिना उपयोग किए किसी भी तीसरे पक्ष के पुस्तकालय (जैसे Cocos2D या GLKit);हमारे हिस्से के लिए, हम किसी भी तरह से निष्पादन समय को सीमित नहीं करते हैं, क्योंकि हमें हमेशा प्रतिभाशाली प्रोग्रामर की आवश्यकता होगी। दक्षता निस्संदेह प्रतिस्पर्धात्मकता को बढ़ाएगी, लेकिन अपने काम से संतुष्ट रहना बेहतर है, बस पहले की तुलना में। हम
job@zeptolab.com पर प्रश्नों, सुझावों और समाप्त कार्यों की
प्रतीक्षा करेंगे।हमारा काम दिलचस्प, रचनात्मक और जितना संभव हो टीम-उन्मुख है - यही कारण है कि हमारा कार्यक्रम लचीला है, लेकिन हमारे सुंदर कार्यालय में उपस्थिति एक अनिवार्य तत्व होगी।
अगर अचानक आपके पास अभी इनमें से कोई भी कौशल नहीं है, लेकिन ZeptoLab- एक विकास टीम में शामिल होने की आपकी इच्छा कम नहीं हुई है, तो आप इनमें से किसी भी टूल (हमारे पहले से ही हमारे) एंड्रॉइड डेवलपर्स ने एक महीने में एंड्रॉइड से प्रोग्रामिंग सीखी है (C ++ अच्छी तरह से जानते हुए) और हमें सबसे अच्छे कार्यों में से एक भेजा।) इसलिए, जैसा कि वे कहते हैं, एक इच्छा होगी :)
हमें उम्मीद है कि उपरोक्त समीक्षा डेवलपर्स को अपने काम की उच्च गुणवत्ता के दावे के साथ यह समझने में मदद करेगी कि मास्टरपीस बनाते समय क्या देखना है। किसी के लिए - यह उनके क्षेत्र में पेशेवरों के सर्कल में अपना हाथ आज़माने और बहुत कुछ सीखने का एक और मौका है।
सभी में।
यदि आपके पास विषय पर साझा करने के लिए कुछ है - जैसा कि वे कहते हैं, स्वागत भी करते हैं।
अलविदा न कहना।
ZeptoTeam