खेल जाम में भागीदारी का इतिहास। Snowbox

2017 के अंत में, मुझे दुनिया के कई गेम जैम्स में से एक में एक प्रतिभागी के रूप में अपनी ताकत और उत्साह का परीक्षण करने का अवसर मिला।

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

बिल्ली के तहत, 30 दिनों के विकास और धीमी गति से 20 दिनों के परिणामों की प्रतीक्षा करने का कितना गहन वर्णन किया गया।

नोट: लेख कुछ तकनीकी विवरणों के साथ, प्रकृति में कथा है।

प्रस्तावना

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

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

इसलिए हमने हिस्सा लेने का फैसला किया। दो जावा डेवलपर्स, खेल बनाने में बिल्कुल अनुभव नहीं है। लेकिन कब शुरू करने की आवश्यकता है?

ट्रेनिंग

चुना गया खेल जाम विषयगत था, और आयोजकों को विकास की शुरुआत से पहले कड़ाई से विषय की घोषणा करनी थी। खेल को बनाने के लिए प्रतियोगियों को 1 महीने का समय दिया गया था।

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

घंटे X पर, आयोजकों ने प्रतियोगिता के विषय की घोषणा की - थ्रोबैक (वापसी वापस) और उलटी गिनती शुरू हुई।

सेलिम को खेल की एकमात्र इच्छा थी - गेम सर्वर की उपस्थिति और आवश्यक रूप से वास्तविक समय। वह सर्वर साइड विकसित करने में देरी और कठिनाइयों को जानने के लिए इच्छुक थे। इसके अलावा, खेल सरल होना चाहिए था, अन्यथा हमारे पास इसे पूरा करने का समय नहीं था।

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

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

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

विकास। सप्ताह 1

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


विकास की शुरुआत संयुक्त बैठक से हुई। पहले 2 घंटों में, मैंने "अस्थायी" स्प्राइट उठाया और एक दौड़ने वाले लड़के को महसूस किया जो जानता था कि स्नोबॉल कैसे फेंकना है। वहाँ "यह था / बन गया है" की एक तस्वीर हो सकती है, लेकिन यह किसी भी अर्थ से रहित है - नेत्रहीन क्या था, फिर बनी हुई है।

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

आगे विकास केवल काम से खाली समय में जारी रहा, सप्ताह में 6 दिन घरों के लिए अलग से और एक दिन एक साथ बंद। यह एक साधारण एपीआई और भूमिकाओं के कठोर वितरण के लिए काफी धन्यवाद था।

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

क्लाइंट-सर्वर इंटरेक्शन मॉडल

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

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

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

उदाहरण के लिए, किसी खिलाड़ी को उस नक्शे को स्थानांतरित करने के लिए जिसे आपको 4 घटनाओं की आवश्यकता है:

1. ग्राहक : कुंजी दबाया;
2. सर्वर : खिलाड़ी ने बिंदु [x, y1 ] से कोण α पर, गति ν के साथ बढ़ना शुरू किया;
3. ग्राहक : कुंजी दबाया;
4. सर्वर : खिलाड़ी ने बिंदु [x, y2 ] पर जाना समाप्त कर दिया है।

इस दृष्टिकोण में पेशेवरों और विपक्ष दोनों हैं।

विपक्ष

• ग्राहक पर बहुत अधिक तर्क: ग्राहक को स्वयं आंदोलन, टकरावों आदि की गणना करनी चाहिए।
• क्लाइंट पर तर्क को सर्वर पर तर्क को बहुत सटीक रूप से दोहराना होगा, अन्यथा वस्तुओं के आंदोलन में कूदता है। लेख में आगे इस विषय पर कई उदाहरण होंगे;
• नेटवर्क समस्याओं के मामले में, बाद में घटनाओं को प्राप्त करने से गलत स्थिति हो सकती है (सीमा से बाहर जाना, वस्तुओं से गुजरना, आदि);
• सामान्य तौर पर, सर्वर और क्लाइंट पर राज्य को सिंक से बाहर निकालना बहुत आसान है।

आकर्षण आते हैं

• I / O पर बहुत कम भार;
• अतिरिक्त तर्क घटनाओं पर लटकाए जा सकते हैं। उदाहरण के लिए, किसी आंदोलन की शुरुआत / अंत में, आप एनीमेशन को शुरू / बंद कर सकते हैं;
• नेटवर्क की समस्याएं आंदोलन की चिकनाई को कम प्रभावित करती हैं। जबकि स्नोबॉल उड़ रहा है, एक सेकंड की देरी भी कुछ भी प्रभावित नहीं करेगी, क्योंकि सर्वर को कुछ भी नहीं भेजना चाहिए;
• API और इंटरैक्शन स्वयं अधिक पारदर्शी हो जाता है।

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

विकास। सप्ताह 2 और 3

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

इसलिए, हमने एक चालू लड़की को जोड़ने का फैसला किया! जिस तरह से, लड़की के लिए मुझे एक चरित्र चयन खिड़की बनाना था। और चूँकि खिड़की अभी भी बननी थी, इसलिए नाम नहीं जोड़ना भी पाप है। इसके अलावा, मुझे 9-पैच दृष्टिकोण के समान, छवियों को फैलाना पड़ा।


यह लॉगिन विंडो के पहले संस्करण जैसा दिखता था

इस सब के कारण, एक लड़की को जोड़ने का इतना सरल और महत्वपूर्ण कार्य एक शाम को ले लिया, लेकिन यह स्पष्ट रूप से इसके लायक था। और फिर समान कार्यों के साथ ग्रे रोजमर्रा की जिंदगी में आया: नए सरल कार्य, बग फिक्स, मामूली दृश्य सुधार।

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

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

मॉक सर्वर का एक और निश्चित प्लस था। इसमें बॉट्स थे जो शूट करना नहीं जानते थे, इसलिए कम से कम किसी को जीतने का मौका था।

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

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

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

यह समस्या मास्क को पेश करने से हल की गई थी, अर्थात, उन वस्तुओं के वर्गों को निर्दिष्ट करके जो एक दूसरे से टकरा नहीं सकते। उदाहरण के लिए, एक खिलाड़ी और उसके स्नोबॉल के लिए, मुखौटा समान बनाया गया था।

सेलिम ने एक दूसरे के साथ स्नोबॉल टकरावों की विशेष हैंडलिंग पर समय बर्बाद नहीं करने का फैसला किया और इस तरह की टक्कर पर टिप्पणी की:

// for the unlikely event that we collide with a sibling snowball

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

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


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

डिलीवरी के एक हफ्ते पहले, डेवलपर्स मीटिंग में, हम सामान्य संस्करण भी नहीं दिखा पा रहे थे और मॉक सर्वर दिखाना पड़ा।

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

विकास। सप्ताह 4, अंतिम

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

कीड़े को ठीक करने के अलावा, मैं यूआई में अंतिम चमक भी लाया: संगीत और ध्वनियों को जोड़ना, फोंट के साथ खेलना और छोटे विवरणों में सुधार करना।

सभी कार्यक्षमता में से, इस सप्ताह केवल अंक प्रणाली को जोड़ा गया था, साथ ही स्नोबॉल के स्टॉक की सीमा और उनकी बहाली भी।

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


इसलिए, एक बंद बग और काम करने वाले खिलौने से खुश, समय सीमा से 2 घंटे पहले, हम आत्मसमर्पण करने के लिए तैयार थे। यह केवल प्रोजेक्ट वेबसाइट पर गेम भेजने के लिए बना रहा।

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


खेल के अंतिम संस्करण का स्क्रीनशॉट

वोट

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

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

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

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



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

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

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

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



इस प्रकार, हमने 200 से अधिक प्रतिभागियों में से 36 वां स्थान प्राप्त किया। जो एक तरफ, पहली परियोजना के लिए बुरा नहीं है, लेकिन दूसरी तरफ, यह गर्व के लिए कुछ अप्रिय है। विशेष रूप से यह देखते हुए कि शीर्ष 10 को अच्छे खेल मिले, लेकिन सभी ने कुछ खास ध्यान नहीं दिया।

सबक सीखा

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

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

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

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

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

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

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

संसाधनों के लिंक:

• selim.co/snowbox - खेल ही है। हमने इसे तनाव परीक्षण पर नहीं धकेला, इसलिए मैं यह सुनिश्चित करने से बहुत दूर हूं कि यह सभी कामर्स का सामना करेगा। यदि सर्वर झूठ होगा, तो आप mock - selim.co/snowbox/#mock आज़मा सकते हैं
• github.com/wowselim/gameserver - सर्वर कोड रिपॉजिटरी
• github.com/bugy/snowbox-ui - क्लाइंट रिपॉजिटरी
• itch.io/jam/game-off-2017 - खेल जाम पेज
• itch.io/jam/game-off-2017/rate/199650 - खेल मतदान पृष्ठ
• opengameart.org - खेल संसाधनों का मुख्य स्रोत
• freesound.org - खेल की आवाज़ यहाँ से ली गई थी

आप सभी को अपने समय और अच्छे मूड के लिए धन्यवाद!