मोबाइल प्लेटफार्मों के लिए खेल के विकास में अतिसूक्ष्मवाद के सिद्धांत

प्रस्तावना

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

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

तो, क्रम में:

1. विचार की न्यूनतमता

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

यहाँ एक उदाहरण टिनी विंग्स है।


और एंग्री बर्ड्स।

2. डिजाइन का न्यूनतमवाद

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

इन मदों के तहत (लेकिन सभी नहीं) मैं JetPack JoyRide पर हस्ताक्षर करूंगा


और भीड़ में भागो।

3. ग्राफिक्स में न्यूनतमवाद

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

यहाँ Cut the Rope फिट है


और कॉन्ट्रे जर्स।

4. प्रोग्रामिंग की न्यूनतमता

• वर्तमान विकास का अधिकतम उपयोग करें।
• सरल डिजाइन को सरल एल्गोरिदम और डेटा संरचनाओं का नेतृत्व करना चाहिए।
• कोड जितना छोटा होगा, एप्लिकेशन आकार उतना ही छोटा होगा।

यहां मैं एंग्री बर्ड्स के सभी निरंतरता, कट रोप एक्सपेरिमेंट्स और मेगा रन का गुणन करूंगा।

5. न्यूनतम ध्वनि डिजाइन

• आसान, परेशान करने वाला बैकग्राउंड संगीत नहीं जो सभी को पसंद आएगा।
• ध्वनियों की एक छोटी संख्या (वे प्रोसेसर को लोड करते हैं और बिल्ड आकार बढ़ाते हैं)।
• ध्वनियाँ सरल होनी चाहिए, विचलित नहीं होनी चाहिए और लोडिंग नहीं होनी चाहिए, लेकिन गेमप्ले में डूबना।

कॉन्ट्रे जर्स, कट द रोप।

6. अन्य (अतिरिक्त) आवश्यकताएँ:

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

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

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