रॉब्लॉक्स बिल्ड गेम निर्माण का मूल्यांकन कैसे करता है

Build, हमारा नया मोबाइल-प्रथम क्रिएशन टूल, एक Roblox उपयोगकर्ता को टेक्स्ट प्रॉम्प्ट्स का उपयोग करके एक गेम बनाने और उसे दुनिया भर के खिलाड़ियों के लिए प्रकाशित करने की अनुमति देता है। एक समग्र गेम उत्पन्न करने के लिए गेम निर्माण हेतु एक एंड-टू-एंड एजेंटिक सिस्टम की आवश्यकता होती है: एक ऐसा सिस्टम जो कोड, विज़ुअल एसेट्स, गेमप्ले सिस्टम्स, UI, और कंट्रोल्स को एक एकल संयुक्त आर्टिफैक्ट में समन्वयित करता है। इस सिस्टम को खिलाड़ी इनपुट और मल्टीप्लेयर इंटरैक्शन से उत्पन्न होने वाले विभिन्न परिदृश्यों को मजबूती से संभालना चाहिए। न्यूजीलैंड में अल्फा लॉन्च के बाद से, 100,000 से अधिक खिलाड़ियों ने गेम बनाने की कोशिश करने के लिए बिल्ड का उपयोग किया है, और लगभग 9,000 बिल्ड गेम प्रकाशित किए गए हैं।¹ गेम बनाने के लिए बिल्ड का उपयोग करने वाले हजारों लोगों में से, 71% ने पहले कभी रॉब्लॉक्स स्टूडियो का उपयोग नहीं किया था,¹ जो यह दर्शाता है कि वे बिल्ड के साथ कुछ नया आज़मा रहे हैं।

लेकिन निर्माता इस नए टूल का उपयोग तभी करेंगे जब इसका उपयोग करना आसान हो और इसके द्वारा बनाए गए खेलों की गुणवत्ता आगे बढ़ाने के लिए पर्याप्त उच्च हो। Build के साथ बनाए गए खेलों की गुणवत्ता को समझने के लिए, हम एंड-टू-एंड निर्माण यात्रा का मूल्यांकन करते हैं और उत्पाद में सुधार करने के लिए उन मूल्यांकनों के साथ-साथ निर्माताओं की प्रतिक्रिया का भी उपयोग करते हैं। हमारे मूल्यांकन (eval) फ्रेमवर्क ने हमें इरादे की समझ, 3D प्लेएबिलिटी और पॉलिश को प्राथमिकता देने और बेहतर बनाने में मदद की है। न्यूजीलैंड में बिल्ड के अल्फा लॉन्च के बाद से, निर्माता संतुष्टि में 10% की सुधार हुई है, अनपेक्षित आउटपुट 18% से घटकर 3% हो गए हैं, और लगभग 14% प्रॉम्प्टेड सत्र और 19% प्लेटेस्ट प्रकाशित किए जाते हैं।² ये प्रगति के वर्णनात्मक संकेतक हैं, न कि केवल मूल्यांकन के प्रभाव के कारण संबंधी अनुमान।

गेम निर्माण का मूल्यांकन क्यों अलग है

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

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

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

चार संकेत, एक फ्रेमवर्क

हमारा बिल्ड निर्माण मूल्यांकन फ्रेमवर्क चार संकेतों को जोड़ता है। प्रत्येक एक अलग प्रश्न का उत्तर देता है, विफलता की एक अलग श्रेणी को पकड़ता है, और एक ठोस मात्रात्मक स्कोर प्रदान करता है:

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

2. स्थिर गेम गुणवत्ता (0 - 100 स्कोर): स्थिर प्लेस मूल्यांकनकर्ता Roblox Studio संपादन मोड में उत्पन्न गेम का निरीक्षण करता है। इसमें गेम की संरचना, स्क्रिप्ट, एसेट्स, प्रॉपर्टीज़, कनेक्शन और क्लाइंट/सर्वर सीमाएँ शामिल हैं। इस चरण में हम दो प्रश्नों का उत्तर खोजना चाहते हैं। पहला यह है कि क्या गेम सही ढंग से बनाया गया है: आवश्यक सिस्टम का कार्यान्वयन, इंजन-एपीआई और नेटवर्किंग विकल्प, अपेक्षित नियंत्रणों और यूआई घटकों की उपस्थिति, गेम आर्किटेक्चर की मजबूती और सुसंगति। 

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

इन दोनों दृष्टिकोणों को अलग करना और सर्वोत्तम प्रथाओं के आधार पर मापना हमें इस बारे में अधिक विस्तृत जानकारी देता है कि गेम कहाँ विफल हो रहा है।

3. प्लेटेस्ट (0 - 100% पास रेट): प्लेटेस्ट मूल्यांकनकर्ता गेम को चलाता है और कोड से इवेंट फायर करने के बजाय, वास्तविक खिलाड़ी की तरह इनपुट के साथ एक टेस्ट प्लान को निष्पादित करता है, जिसमें टैप, क्लिक, कीस्ट्रोक्स और नेविगेशन शामिल हैं। एक प्रति-मामला परीक्षण योजना यह जांचती है कि गेम शुरू होता है, प्रतिक्रिया देता है, आगे बढ़ता है, विफलता से उबरता है, और रनटाइम त्रुटियों से मुक्त रहता है। प्रत्येक आइटम एक बाइनरी पास/फेल होता है, जिसे एक साधारण प्लेएबल/नॉन-प्लेएबल निर्णय के साथ-साथ एक टियर-वेटेड पास दर के रूप में रिपोर्ट किया जाता है। हम निरंतरता को मापने के लिए रन को दोहराते हैं।

4. दृश्य और अनुभव की गुणवत्ता (0 - 100 अंक): एक गेम के लुक और फील के लिए जो बातें सबसे ज़्यादा मायने रखती हैं, उनमें से कुछ को कोड से नहीं पढ़ा जा सकता, इसलिए दृश्य मूल्यांकनकर्ता विभिन्न उपकरणों का प्रतिनिधित्व करने वाले व्यूपोर्ट पर कैप्चर किए गए गेमप्ले का उपयोग करके प्रस्तुति को अपने आप स्कोर करता है। यह मानदंड केवल इस बात पर ध्यान देता है कि एक गेम एसेट क्राफ्ट, यूआई फिनिश, मोशन, लाइटिंग और ऑडियो के आधार पर कैसा दिखता और लगता है। मुख्य सवाल यह है: क्या गेम एक शिप करने योग्य उत्पाद की तरह दिखता है, या एक प्रोटोटाइप की तरह? मैकेनिक्स से विज़ुअल्स को अलग रखने का मतलब है कि "कोड काम करता है" और "गेम पूरा दिखता है" एक भ्रामक स्कोर में औसत नहीं होते हैं।

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

संकेत उन विफलताओं से मेल खाते हैं जिन्हें वे पकड़ते हैं:

एक प्रॉम्प्ट किए गए 3D ओबीबी कोर्स में चलना

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

योजना और विनिर्देश

बिल्ड ने स्काईफोर्ज एसेन्ट नामक एक नए गेम के लिए एक स्पेक डॉक (spec doc) तैयार किया, जिसमें चेकपॉइंट और तीन प्रकार के खतरों के साथ एक पांच-खंडों वाले कोर्स का विवरण था। इसमें मुख्य लूप, कठिनाई वक्र, कला निर्देशन, स्क्रीन, ओवरले और नियंत्रणों को परिभाषित किया गया था। स्पेक मूल्यांकन (Spec eval) ने इसे 100 में से 91 अंक दिए, जिसमें पूर्णता, समय पर पालन, व्यवहार्यता और आंतरिक संगति पर पूरे अंक मिले। अंकों में कटौती दो विशिष्ट आयामों से की गई थी: कार्यान्वयन विवरण और स्वीकृति-मानदंड कवरेज। 

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

स्टैटिक चेक्स: कोड गुणवत्ता और सामग्री गुणवत्ता

वर्चुअल जज ने स्काईफोर्ज एसेन्ट की प्लेसफाइल को बिना खेले निरीक्षण किया, और दोनों मूल्यांकन दृष्टिकोणों ने अलग-अलग निष्कर्ष निकाले।

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

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

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

प्लेटेस्ट

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

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

दृश्य गुणवत्ता

अंत में, मूल्यांकन प्रणाली ने दृश्य प्रस्तुति के लिए फोन-आकार के व्यूपोर्ट पर रिकॉर्ड किए गए सत्र को स्कोर किया। स्काईफोर्ज एसेन्ट ने 86/100 अंक प्राप्त किए: साफ, सुसंगत, और एक सामान्य ओबीबी (obby) के दृश्यों के अनुरूप; पठनीय प्लेटफॉर्मिंग ज्यामिति; स्पष्ट खतरे; और एक आधुनिक, गैर-दखल देने वाला HUD। मामूली दृश्य सीमाएं इसे पूर्णता से रोकती हैं, लेकिन कुछ भी टूटा हुआ नहीं है, और न ही ऐसा कुछ है जो खिलाड़ी को स्क्रॉल करना बंद करने पर मजबूर करे।

ट्रेस मेट्रिक्स

उसी रन ने रिकॉर्डिंग प्रक्रिया के मेट्रिक्स भी दर्ज किए। गेम को बनाने में लगभग आठ मिनट लगे, कोई टूल त्रुटि नहीं थी, और बिल्ड ने 3D, UI, स्क्रिप्ट संपादन, एसेट सम्मिलन, और गेम ऑडियो कौशल का उपयोग किया। ये मेट्रिक्स सीधे मूल्यांकन स्कोर को प्रभावित नहीं करते हैं, लेकिन वे हमें बताते हैं कि गेम कैसे बनाया गया था और भविष्य के किसी बिल्ड को, जो बिना किसी लाभ के धीमा या महंगा हो जाता है, चिह्नित करेंगे।

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

प्रारंभिक मूल्यांकन ने बिल्ड को कैसे बेहतर बनाया 

मूल्यांकन के परिणाम केवल स्कोर उत्पन्न करने से कहीं बढ़कर हैं, वे उत्पाद में सुधार के लिए व्यावहारिक दिशा भी प्रदान करते हैं। व्यक्तिगत घटक डिबगिंग को समग्र सिस्टम-स्तरीय परीक्षण के साथ मिलाकर, मानकीकृत प्रॉम्प्ट सूट पर ऑफ़लाइन बैच मूल्यांकन ने सीधे तौर पर बिल्ड के विकास को आकार दिया है। 

1. अल्फा क्रिएटर की समस्याओं को तेजी से हल करना: हमारे न्यूजीलैंड अल्फा लॉन्च में, उपयोगकर्ताओं ने हमें फीडबैक दिया कि बिल्ड कभी-कभी 2D गेम बना देता था जबकि वे 3D गेम चाहते थे। मूल्यांकन फ्रेमवर्क ने हमारी टीम को बिल्ड की 3D क्षमताओं में तेजी से सुधार करने में मदद की। दो सप्ताह के भीतर, हमने बिल्ड की उस क्षमता में सुधार किया कि वह उपयोगकर्ता के 3D गेम बनाने के इरादे को समझ सके—भले ही उन्होंने इसे स्पष्ट रूप से न कहा हो। हमने ऑब्जेक्ट की स्थिति, लाइटिंग आदि से जुड़ी आम समस्याओं को ठीक करके 3D प्लेएबिलिटी और पॉलिश में भी सुधार किया। तब से, सभी शिकायतों में से "मेरी इच्छानुसार नहीं" वाली शिकायतें 18% से घटकर 3% हो गई हैं; प्लेटेस्ट के बाद कुल मिलाकर असंतुष्ट प्रतिक्रिया में 10% अंकों की कमी आई है। हमने खुद फ्रेमवर्क पर पुनरावृत्ति करते समय भी सीख हासिल की। 
2. मॉडलों और आर्किटेक्चर के बीच तुलनात्मक बेंचमार्किंग: हम अपने मूल्यांकन फ्रेमवर्क का उपयोग बिल्ड सिस्टम कॉन्फ़िगरेशन को मानकीकृत प्रॉम्प्ट सूट के खिलाफ कड़ाई से बेंचमार्क करने के लिए करते हैं। प्रोडक्शन में बदलाव भेजने से पहले, ऑफ़लाइन A/B मूल्यांकन रिपोर्टें उम्मीदवार रिलीज़ की तुलना हमारे प्रोडक्शन बेसलाइन से चारों आयामों में करती हैं: 

उदाहरण के लिए, ये ऑफ़लाइन डिफ़्स हमें यह अलग करने की अनुमति देते हैं कि विभिन्न मॉडल अपग्रेड और एजेंट राउटिंग निर्णय व्यक्तिगत गुणवत्ता संकेतों को कैसे प्रभावित करते हैं:

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

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

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

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

अब आगे क्या

हम वर्तमान में अपने बिल्ड निर्माण मूल्यांकन प्रणाली को पाँच दिशाओं में विस्तारित करने पर ध्यान केंद्रित कर रहे हैं:

1. शैलियों, 2D/2.5D/3D अनुभवों, मल्टीप्लेयर परिदृश्यों और जटिलता के स्तरों में व्यापक कवरेज
2. मल्टी-टर्न संपादनों के लिए मजबूत समर्थन
3. अधिक विश्वसनीय प्लेटेस्ट, स्क्रीनशॉट, वीडियो और ऑडियो साक्ष्य
4. मानव रेटिंग्स के पैमाने पर कैलिब्रेशन और निर्माता-नेतृत्व वाले बेंचमार्क मामलों
5. ऑफ़लाइन मूल्यांकन, ऑनलाइन उत्पाद संकेतों और रिग्रेशन परीक्षण के बीच बेहतर एकीकरण

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

Roblox Assistant के लिए एजेंटिक सिस्टम का मूल्यांकन करने पर संबंधित दृष्टिकोण के लिए, Using OpenGameEval to Benchmark Agentic AI Assistants for Roblox Studio देखें।