सिंगलेरिटी: यूनिवर्सल बैकएंड फ्रेमवर्क के साथ गेम डेवलपमेंट को सुव्यवस्थित करना

नमस्ते! मैं एंड्री माखोरिन हूँ, पिक्सोनिक (MY.GAMES) में सर्वर डेवलपर। इस लेख में, मैं साझा करूँगा कि कैसे मेरी टीम और मैंने बैकएंड डेवलपमेंट के लिए एक सार्वभौमिक समाधान बनाया। आप अवधारणा, इसके परिणाम और हमारे सिस्टम, जिसे सिंगलैरिटी कहा जाता है, ने वास्तविक दुनिया की परियोजनाओं में कैसा प्रदर्शन किया, इसके बारे में जानेंगे। मैं उन चुनौतियों के बारे में भी विस्तार से बताऊंगा जिनका हमने सामना किया।

पृष्ठभूमि

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

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

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

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

इसके अलावा, कोर सिस्टम को अक्सर एक विशिष्ट शैली या खेल को ध्यान में रखकर डिज़ाइन किया जाता है, जिससे नए प्रोजेक्ट के लिए इसे अनुकूलित करना मुश्किल हो जाता है।

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

अब, चलिए अपनी कहानी पर आते हैं।

सिंगुलैरिटी की आवश्यकता

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

जब नया गेम विकसित करने का समय आया, तो हमें एहसास हुआ कि वॉर रोबोट्स के सर्वर घटकों का पुनः उपयोग करने की कोशिश करना समस्याग्रस्त होगा। कोड बहुत अधिक परियोजना-विशिष्ट था और इसके लिए उन तकनीकों में विशेषज्ञता की आवश्यकता थी, जिनकी नई टीम में कमी थी।

हमने यह भी माना कि नए प्रोजेक्ट की सफलता की गारंटी नहीं थी, और अगर यह सफल भी हो गया, तो हमें अंततः एक और नया गेम बनाना होगा, और हम उसी "रिक्त स्लेट" समस्या का सामना करेंगे। इससे बचने और भविष्य के लिए कुछ सुरक्षा करने के लिए, हमने गेम डेवलपमेंट के लिए आवश्यक आवश्यक घटकों की पहचान करने और फिर एक सार्वभौमिक ढांचा बनाने का फैसला किया, जिसका उपयोग सभी भविष्य की परियोजनाओं में किया जा सके।

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

इसके अतिरिक्त, हम न केवल अपने नए फ्रेमवर्क के साथ विकास को गति देना चाहते थे, बल्कि क्लाइंट प्रोग्रामर्स को नेटवर्किंग, डीबीएमएस या बुनियादी ढांचे के गहन ज्ञान के बिना सर्वर-साइड लॉजिक लिखने में सक्षम बनाना चाहते थे।

इसके अलावा, सेवाओं के एक सेट को मानकीकृत करके, हमारी DevOps टीम सभी गेम प्रोजेक्ट्स को समान रूप से व्यवहार करने में सक्षम होगी, केवल IP पते बदलकर। यह हमें पुन: प्रयोज्य परिनियोजन स्क्रिप्ट टेम्प्लेट और मॉनिटरिंग डैशबोर्ड बनाने में सक्षम करेगा।

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

(यह भी ध्यान देने योग्य है कि फ्रेमवर्क का विकास एक द्वीप नहीं था - इसे एक अन्य परियोजना के समानांतर बनाया गया था।)

मंच का निर्माण

हमने सिंगलेरिटी को गेम की शैली, सेटिंग या मुख्य गेमप्ले से अलग कार्यों का एक सेट देने का निर्णय लिया, जिसमें शामिल हैं:

• प्रमाणीकरण
• उपयोगकर्ता डेटा संग्रहण
• गेम सेटिंग्स और बैलेंस पार्सिंग
• भुगतान प्रक्रिया
• एबी परीक्षण वितरण
• एनालिटिक्स सेवा एकीकरण
• सर्वर एडमिन पैनल

ये फ़ंक्शन किसी भी बहु-उपयोगकर्ता मोबाइल प्रोजेक्ट के लिए मौलिक हैं (कम से कम, वे पिक्सोनिक में विकसित परियोजनाओं के लिए प्रासंगिक हैं)।

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

कुछ उदाहरणों में शामिल हैं:

• खोज
• ऑफर
• मित्रों की सूची
• मंगनी करना
• रेटिंग तालिकाएं
• खिलाड़ियों की ऑनलाइन स्थिति
• खेल में सूचनाएं

तकनीकी रूप से, सिंगलेरिटी प्लेटफॉर्म में चार घटक होते हैं:

• सर्वर SDK: यह लाइब्रेरीज़ का एक सेट है जिसके आधार पर गेम प्रोग्रामर अपने सर्वर विकसित कर सकते हैं।
• क्लाइंट SDK: यह भी लाइब्रेरीज़ का एक सेट है, लेकिन मोबाइल एप्लिकेशन विकसित करने के लिए।
• तैयार माइक्रोसर्विस का एक सेट: ये तैयार सर्वर हैं जिन्हें संशोधन की आवश्यकता नहीं होती है। इनमें प्रमाणीकरण सर्वर, बैलेंस सर्वर और अन्य शामिल हैं।
• एक्सटेंशन लाइब्रेरीज़: ये लाइब्रेरीज़ पहले से ही विभिन्न सुविधाओं को क्रियान्वित करती हैं, जैसे कि ऑफर, क्वेस्ट आदि। गेम प्रोग्रामर इन एक्सटेंशन को सक्षम कर सकते हैं यदि उनके गेम को इसकी आवश्यकता हो।

आगे, आइए इनमें से प्रत्येक घटक की जांच करें।

सर्वर SDK

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

यह दृष्टिकोण ASP.NET अनुप्रयोग के निर्माण के समान है, जहां फ्रेमवर्क निम्न-स्तरीय HTTP प्रोटोकॉल कार्यक्षमता प्रदान करता है, इस बीच, डेवलपर व्यवसाय तर्क वाले नियंत्रक और मॉडल बनाने पर ध्यान केंद्रित कर सकता है।

उदाहरण के लिए, मान लीजिए कि हम गेम के भीतर उपयोगकर्ता नाम बदलने की क्षमता जोड़ना चाहते हैं। ऐसा करने के लिए, प्रोग्रामर को एक कमांड क्लास लिखना होगा जिसमें नया उपयोगकर्ता नाम और इस कमांड के लिए एक हैंडलर शामिल हो।

ChangeNameCommand का एक उदाहरण यहां दिया गया है:

 public class ChangeNameCommand : ICommand { public string Name { get; set; } }

इस कमांड हैंडलर का एक उदाहरण:

 class ChangeNameCommandHandler : ICommandHandler<ChangeNameCommand> { private IProfile Profile { get; } public ChangeNameCommandHandler(IProfile profile) { Profile = profile; } public void Handle(ICommandContext context, ChangeNameCommand command) { Profile.Name = command.Name; } }

इस उदाहरण में, हैंडलर को IProfile कार्यान्वयन के साथ आरंभ किया जाना चाहिए, जिसे निर्भरता इंजेक्शन के माध्यम से स्वचालित रूप से नियंत्रित किया जाता है। कुछ मॉडल, जैसे कि IProfile, IWallet, और IInventory, अतिरिक्त चरणों के बिना कार्यान्वयन के लिए उपलब्ध हैं। हालाँकि, ये मॉडल अपने अमूर्त स्वभाव के कारण काम करने के लिए बहुत सुविधाजनक नहीं हो सकते हैं, डेटा प्रदान करते हैं और ऐसे तर्क स्वीकार करते हैं जो विशिष्ट परियोजना आवश्यकताओं के अनुरूप नहीं हैं।

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

यहाँ डोमेन मॉडल का एक उदाहरण दिया गया है:

 public class WRProfile { public readonly IProfile Raw; public WRProfile(IProfile profile) { Raw = profile; } public int Level { get => Raw.Attributes["level"].AsInt(); set => Raw.Attributes["level"] = value; } }

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

डोमेन मॉडल का उपयोग करने वाले कमांड हैंडलर का एक उदाहरण:

 class LevelUpCommandHandler : ICommandHandler<LevelUpCommand> { private WRProfile Profile { get; } public LevelUpCommandHandler(WRProfile profile) { Profile = profile; } public void Handle(ICommandContext context, LevelUpCommand command) { Profile.Level += 1; } }

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

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

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

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

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

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

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

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

क्लाइंट SDK

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

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

कमांड कॉल का एक उदाहरण यहां दिया गया है:

 var result = _sandbox.ExecSync(new LevelUpCommand())

तैयार माइक्रोसर्विसेज

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

तैयार सेवाओं के समूह में निम्नलिखित शामिल हैं:

• ग्राहक अनुरोधों के लिए एक प्रवेश द्वार
• एक प्रमाणीकरण सेवा
• सेटिंग्स और बैलेंस तालिकाओं को पार्स करने और संग्रहीत करने के लिए एक सेवा
• एक ऑनलाइन स्थिति सेवा
• एक मित्र की सेवा
• लीडरबोर्ड सेवा

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

मैं बाद में बड़ी संख्या में सेवाओं के प्रबंधन से संबंधित मुद्दों पर बात करूंगा, लेकिन अभी के लिए, इस बात पर ज़ोर देना ज़रूरी है कि वैकल्पिक सेवाएँ वैकल्पिक ही रहनी चाहिए। जैसे-जैसे सेवाओं की संख्या बढ़ती है, नई परियोजनाओं के लिए जटिलता और ऑनबोर्डिंग सीमा भी बढ़ती जाती है।

एक्सटेंशन लाइब्रेरीज़

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

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

अब तक के परिणाम

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

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

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

चुनौतियों का सामना डेवलपर्स से लेकर इंफ्रास्ट्रक्चर एडमिनिस्ट्रेटर तक के लोगों को करना पड़ता है। इन पेशेवरों के पास अक्सर Postgres और Kafka जैसे जाने-माने समाधानों को तैनात करने और बनाए रखने में गहरी विशेषज्ञता होती है। हालाँकि, Singularity एक आंतरिक उत्पाद है, जिसके लिए उन्हें नए कौशल हासिल करने की आवश्यकता होती है: उन्हें Singularity के क्लस्टर की पेचीदगियों को सीखने, आवश्यक और वैकल्पिक सेवाओं के बीच अंतर करने और यह समझने की आवश्यकता होती है कि निगरानी के लिए कौन से मीट्रिक महत्वपूर्ण हैं।

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

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

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

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

भविष्य

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

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