रॉब्लॉक्स बिल्ड गेम निर्मितीचे मूल्यांकन कसे करते

Build, आमचे नवीन मोबाइल-प्रथम निर्मिती साधन, Roblox वापरकर्त्याला मजकूर सूचना वापरून गेम तयार करण्यास आणि तो जगभरातील खेळाडूंना प्रकाशित करण्यास परवानगी देते. एक संपूर्ण गेम तयार करण्यासाठी गेम निर्मितीसाठी एक संपूर्ण एजंटिक प्रणाली आवश्यक आहे: जी कोड, दृश्य साधने, गेमप्ले प्रणाली, UI आणि नियंत्रण यांना एकाच संयुक्त घटकात समन्वयित करते. ही प्रणाली खेळाडूंच्या इनपुटमुळे आणि मल्टीप्लेअर परस्परसंवादामुळे उद्भवणाऱ्या विविध परिस्थितींना ठामपणे हाताळू शकली पाहिजे. न्यूझीलंडमधील अल्फा लाँच झाल्यापासून, 100,000 पेक्षा जास्त खेळाडूंनी गेम तयार करण्यासाठी Build वापरले आहे, आणि सुमारे 9,000 Build गेम्स प्रकाशित झाल्या आहेत.¹ गेम तयार करण्यासाठी Build वापरलेल्या हजारो लोकांपैकी, 71% लोकांनी यापूर्वी कधीही Roblox Studio वापरलेले नव्हते,¹ जे दाखवते की ते Build वापरून काहीतरी नवीन करण्याचा प्रयत्न करत आहेत.

परंतु निर्माते हे नवीन साधन तेव्हाच वापरतील जेव्हा ते वापरण्यास सोपे असेल आणि त्याद्वारे तयार होणाऱ्या खेळांची गुणवत्ता पुढील विकास करण्यासाठी पुरेशी उच्च असेल. Build वापरून तयार केलेल्या खेळांच्या गुणवत्तेचे आकलन करण्यासाठी, आम्ही संपूर्ण निर्मिती प्रवासाचे मूल्यांकन करतो आणि त्या मूल्यांकनांसह निर्मात्यांच्या अभिप्रायाचा वापर करून उत्पादन सुधारतो. आमच्या मूल्यांकन (eval) फ्रेमवर्कमुळे आम्हाला हेतू समजून घेणे, 3D प्लेएबिलिटी आणि परिष्करण या बाबींना प्राधान्य देऊन सुधारण्यात मदत झाली आहे. न्यूझीलंडमध्ये Build च्या अल्फा लाँचनंतर, निर्मात्यांचे समाधान 10% ने वाढले आहे, अनपेक्षित आउटपुट 18% वरून 3% वर घसरले आहेत, आणि सुमारे 14% प्रॉम्प्ट केलेल्या सत्रांची आणि 19% प्लेटेस्ट्सची प्रकाशना केली जाते.² हे प्रगतीचे वर्णनात्मक निर्देशक आहेत, मूल्यांकनाच्या प्रभावाचे एकमेव कारणीभूत अंदाज नाहीत.

गेम निर्मितीचे मूल्यांकन का वेगळे आहे

गेम्सना अॅप्स, व्हिडिओ आणि वर्ल्ड मॉडेल्ससारख्या मिश्रित कलाकृती तयार करणाऱ्या इतर प्रणालींमध्ये आढळणाऱ्या काही समान मूल्यांकन आव्हानांना सामोरे जावे लागते. उदाहरणार्थ, गुणवत्ता ही अनेक घटक एकत्र कसे कार्य करतात यावर अवलंबून असते, आणि कोणताही एक घटक गुण निकाल पूर्णपणे वर्णन करू शकत नाही. 

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

मूल्यांकनाद्वारे आम्ही जे प्रश्न उत्तर शोधत आहोत तो एखाद्या एका घटकाची बरोबरी आहे का, हा नाही, तर संपूर्ण कलाकृती निर्मात्याच्या हेतूशी जुळते का आणि खेळाडू संपूर्ण अनुभव पार करू शकतात का, हा आहे. त्याचे उत्तर देण्यासाठी एकापेक्षा जास्त मापदंडांची गरज असते.

चार संकेत, एकच चौकट

आमचे बिल्ड निर्मिती मूल्यांकन फ्रेमवर्क चार संकेतांचे संयोजन करते. प्रत्येक संकेत वेगळे प्रश्न उत्तरतो, अपयशाच्या वेगवेगळ्या प्रकारांना पकडतो, आणि एक ठोस मात्रात्मक गुण देतो:

1. गेम विनिर्देश गुणवत्ता (0 - 100 गुण): Build हा संपूर्ण निर्मिती प्रक्रियेचा एजंट आहे: तो निर्मात्याच्या प्रॉम्प्टला विनिर्देशनात रूपांतरित करतो, आणि त्याचा वापर करून गेम तयार करतो. मूल्यांकनकर्ता हे तपासतो की विनिर्देशनात महत्त्वाचे निर्णय स्पष्टपणे घेतले आहेत का, निर्मात्याचा हेतू जपला आहे का, Roblox च्या रनटाइममधील व्यवहार्यता विचारात घेतली आहे का, आणि ज्या आवश्यकता कधीही व्यक्त झाल्या नव्हत्या त्या निर्माण केल्या नाहीत का.

२. स्थिर गेम गुणवत्ता (० - १०० गुण): स्थिर स्थान मूल्यांकनकर्ता Roblox Studio संपादन मोडमध्ये तयार झालेल्या गेमची तपासणी करतो. यामध्ये गेमची रचना, स्क्रिप्ट्स, अॅसेट्स, गुणधर्म, कनेक्शन्स आणि क्लायंट/सर्व्हर सीमा यांचा समावेश होतो. या टप्प्यावर आम्ही दोन प्रश्नांची उत्तरे शोधण्याचा प्रयत्न करतो. पहिला प्रश्न म्हणजे गेम योग्यरित्या तयार केला गेला आहे का: आवश्यक प्रणालींची अंमलबजावणी, इंजिन-API आणि नेटवर्किंग निवडी, अपेक्षित नियंत्रण आणि UI घटकांची उपस्थिती, गेम आर्किटेक्चरची मजबुती आणि सुसंगतता. 

दुसरे म्हणजे ते खेळण्यास मजेदार आहे का: मुख्य लूपची खोली, सामग्रीची विविधता आणि वाढ, प्रगती, पुन्हा खेळण्याची क्षमता, आणि शैलीच्या पूर्वनिर्धारित मर्यादेपलीकडील नवकल्पना. एक खेळ रचनात्मकदृष्ट्या स्वच्छ असू शकतो पण त्यात सामग्रीची खोली नसते, किंवा कल्पनांनी परिपूर्ण असू शकतो पण त्याची रचना नीट केलेली नसते. 

या दोन दृष्टीकोनांना वेगळे करून सर्वोत्तम पद्धतींनुसार मोजमाप केल्यास खेळ कुठे अपयशी ठरतो याची अधिक सखोल कल्पना मिळते.

३. प्लेटेस्ट (० - १००% पास रेट): प्लेटेस्ट मूल्यांकनकर्ता गेम चालवतो आणि कोडमधून इव्हेंट्स फायर करण्याऐवजी टॅप्स, क्लिक, कीस्ट्रोक आणि नेव्हिगेशनसह वास्तविक खेळाडूप्रमाणे इनपुटसह चाचणी योजना अंमलात आणतो. प्रत्येक प्रकरणासाठीची चाचणी योजना तपासते की गेम सुरू होतो, प्रतिसाद देतो, प्रगती करतो, अपयशानंतर पुनर्प्राप्ती करतो आणि रनटाइम त्रुटींपासून मुक्त राहतो. प्रत्येक आयटमसाठी पास/फेलचा द्वि-स्थिती निर्णय घेतला जातो, जो थेट प्ले करण्यायोग्य/अयोग्य निकालासह टियर-वजनित पास रेटमध्ये अहवालित केला जातो. सातत्य मोजण्यासाठी आम्ही चाचण्या पुन्हा चालवतो.

४. दृश्य आणि अनुभवाची गुणवत्ता (० - १०० गुण): गेमच्या दिसण्यावर आणि अनुभव घेण्यावर जे काही सर्वात जास्त महत्त्वाचे असते, त्यातील काही गोष्टी कोडमधून वाचता येत नाहीत, त्यामुळे दृश्य मूल्यांकनकर्ता विविध उपकरणांचे प्रतिनिधित्व करणाऱ्या व्ह्यूपोर्टवर कॅप्चर केलेल्या गेमप्लेचा वापर करून सादरीकरणाचे गुण स्वतंत्रपणे देतो. ही मार्गदर्शिका फक्त गेमच्या दिसण्यावर आणि ऐकण्यावर लक्ष केंद्रित करते, ज्यामध्ये कलाकुसरीची गुणवत्ता, यूआय फिनिश, हालचाल, प्रकाशयोजना आणि ऑडिओ यांचा समावेश होतो. मुख्य प्रश्न असा आहे: हा गेम विक्रीयोग्य उत्पादनासारखा वाटतो की प्रोटोटाइपसारखा? दृश्य घटक यांत्रिकीपासून वेगळे ठेवण्याचा अर्थ असा की "कोड कार्य करतो" आणि "गेम पूर्ण दिसतो" हे दोन मुद्दे एकत्र होऊन एक दिशाभ्रष्ट करणारा गुणांक निर्माण करत नाहीत.

गुणांकित संकेतांसोबतच, प्रत्येक रन फक्त माहितीसाठी मेट्रिक्स कॅप्चर करते, जसे की टोकन वापर, टूल कॉल, ट्रिगर झालेली कौशल्ये आणि विलंब. हे मेट्रिक्स मूल्यांकन गुणांवर परिणाम करत नाहीत, परंतु ते निकाल कसा तयार झाला हे स्पष्ट करू शकतात आणि रूब्रिक्स चुकवलेल्या घसरणींना पकडू शकतात, जसे की एकाच गेमसाठी दुप्पट महाग झालेले बिल्ड.

सिग्नल्स त्या अयशस्वीतेशी जुळतात ज्यांना ते पकडतात:

प्रॉम्प्ट केलेल्या 3D ओबीबी कोर्समधून चालत जाणे

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

आराखडा आणि तपशील

बिल्डने Skyforge Ascent नावाच्या नवीन गेमसाठी एक स्पेक दस्तऐवज तयार केले, ज्यात चेकपॉइंटसह पाच विभागांचा कोर्स आणि तीन धोके प्रकार तपशीलवार दिले आहेत. यात मुख्य लूप, कठीणतेचा वक्र, कला दिशानिर्देश, स्क्रीन, ओव्हरले आणि नियंत्रण यांची व्याख्या केली आहे. स्पेक मूल्यांकनात त्याला 91/100 गुण मिळाले, ज्यात पूर्णता, तत्काळ पालन, व्यवहार्यता आणि अंतर्गत सुसंगतता यावर पूर्ण गुण मिळाले. वजावट दोन विशिष्ट पैलूमुळे झाली: अंमलबजावणी तपशील आणि स्वीकृती निकष कव्हरेज. 

स्पेकने कधीही त्या संख्यात्मक स्थिरांकांना (जसे की फिरण्याच्या वेगात, सरकण्याच्या अंतरावर, टाइल्सच्या वेळापत्रकावर, प्लॅटफॉर्मच्या परिमाणांवर किंवा रीसेट-प्लेनच्या उंचीवर) निश्चित केले नाही, त्यामुळे अभियंत्याला अजूनही त्यांची निर्मिती करावी लागते. याव्यतिरिक्त, काही स्वीकृती निकष ("सुमारे २४ प्लॅटफॉर्म" किंवा "सेलेस्टियल-फोर्ज पॅलेट" यांसारखे) काटेकोरपणे खंडन करता येण्याजोगे नाहीत. उच्च स्पेक गुण फक्त हे सिद्ध करतात की दस्तऐवज तयार करण्यासाठी तयार आहे. प्रत्यक्ष गेम विकासाच्या संपर्कात आल्यावर त्या वचनबद्धता टिकतात की नाहीत, हे पुढील तीन टप्पे मोजतात.

स्थिर तपासण्या: कोड गुणवत्ता आणि सामग्री गुणवत्ता

व्हर्चुअल न्यायाधीशाने Skyforge Ascent चा प्लेसफाइल न खेळता तपासला, आणि दोन मूल्यांकन दृष्टिकोनांनी वेगवेगळे निष्कर्ष काढले.

इंजिनिअरिंग लेन्सने त्याच प्लेसफाइलचे वाचन करून त्याला 98/100 गुण दिले. त्यात पाच विभाग आणि तीन हलणाऱ्या धोके असलेली एक आदर्श रचना आढळली, जी सर्वर-प्राधिकृत क्रमात्मक चेकपॉइंट्स, फॉल-रिसेट प्रणाली आणि StyleSheet फ्रेमवर्कवर आधारित UI वापरून निर्मात्याच्या हेतूला पूर्णपणे समाधानी करते. स्पेसिफिकेशनमध्ये नमूद केलेले सर्व काही पूर्ण झाले होते. एकमेव समस्या म्हणजे दोन वापरलेली नसलेली हेल्पर फंक्शन एक्सपोर्ट्स.

डिझाइन दृष्टीकोनातून त्याला 31/100 गुण मिळाले. सर्वकाही कार्यरत होते, परंतु प्रगती, पुन्हा खेळण्याची क्षमता, खेळाडूचे स्वातंत्र्य आणि मूळ आकर्षण या बाबींवर गेमला शून्य गुण मिळाले. मुख्य लूप सोपा आणि सरळ होता—प्रत्येक चेकपॉइंट गाठा, शेवट ओलांडून पुढे जा—पुन्हा खेळताना फारसा बदल नव्हता आणि दुसऱ्यांदा परत येण्याचे काहीच कारण नव्हते. हा obby शैलीतील एक मूलभूत नमुना आहे, स्वतःचे खास आकर्षण असलेला गेम नाही.

हीच तफावत म्हणजे निष्कर्ष. कोडची गुणवत्ता आणि सामग्रीची गुणवत्ता मूलत: वेगवेगळे पैलू आहेत, आणि एखादी बिल्ड एका बाबतीत जवळजवळ परिपूर्ण असू शकते, तर दुसऱ्या बाबतीत अपयशी ठरू शकते. एकच मिश्रित गुणवत्ता गुण या दोन्ही गोष्टी सरासरी करून निरर्थक बनवला असता.

प्लेटेस्ट

प्लेटेस्ट एजंटने वास्तविक खेळाडूप्रमाणे इनपुट वापरून धावण्याचा गेम खेळला आणि चाचणी योजनेतील सर्व नऊ बाबी पार पाडल्या: सुरुवातीच्या प्लॅटफॉर्मवर पात्र निर्माण करणे, अंतर भरून 3D भूमितीमधून मार्गक्रमण करणे, धोके पत्करणे, चेकपॉइंट्स ट्रिगर करणे आणि स्वयंचलित पतन पुनर्प्राप्ती, धाव पूर्ण करणे, आणि पुन्हा सुरू करणे, हे सर्व शून्य रनटाइम त्रुटींसह. या विशिष्ट धावण्यात, Skyforge Ascent ने प्लेटेस्टमध्ये 100/100 गुण मिळवले.

परिपूर्ण प्लेटेस्ट गुण फक्त हे सिद्ध करतो की यंत्रणा कार्यरत आहेत आणि गेम तांत्रिकदृष्ट्या सुरुवातीपासून शेवटपर्यंत खेळण्यायोग्य आहे. हे गेम प्रत्यक्षात आकर्षक आहे की खेळायला मजा येते याबद्दल काहीच सांगत नाही—हीच वेगळी बाब असल्यामुळे डिझाईन दृष्टीकोनातून त्याला 31 गुण मिळाले.

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

शेवटी, मूल्यांकन प्रणालीने दृश्य सादरीकरणासाठी फोन-आकाराच्या दृश्यफळीवर रेकॉर्ड केलेले सत्र गुणांकित केले. Skyforge Ascent ने 86/100 गुण मिळवले: स्वच्छ, सुसंगत आणि सामान्य obby च्या दृश्यांशी सुसंगत; वाचनीय प्लॅटफॉर्मिंग भूमिती; स्पष्ट धोके; आणि एक आधुनिक, अडथळा आणणार नाही असा HUD. दृश्यात्मक काही मर्यादा असल्यामुळे ते परिपूर्णतेपासून दूर आहे, परंतु काहीही तुटलेले नाही, आणि असेही काहीही नाही जे खेळाडूला स्क्रोल करणे थांबवायला भाग पाडेल.

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

त्याच रनमध्ये नोंदणी प्रक्रियेचे मेट्रिक्सही मोजले गेले. गेम तयार होण्यासाठी सुमारे आठ मिनिटे लागली, कोणतीही टूल त्रुटी नव्हती, आणि Build ने 3D, UI, स्क्रिप्ट संपादन, अॅसेट समावेश, आणि गेम ऑडिओ कौशल्यांचा वापर केला. हे मेट्रिक्स थेट मूल्यांकन गुणांवर परिणाम करत नाहीत, परंतु ते आम्हाला गेम कसा बनवला गेला हे सांगतात आणि भविष्यातील अशा बिल्डवर ध्वनी देतील ज्यात कोणताही फायदा न होता वेळ किंवा खर्च वाढला असेल.

पाच टप्प्यांमध्ये, Skyforge Ascent ने गेम स्पेक्स, कोड गुणवत्ता, सामग्री गुणवत्ता, प्लेटेस्ट आणि दृश्य गुणवत्ता यावर वेगवेगळे गुण मिळवले. त्या पैकी चार पैलूंनुसार Build एकाच प्रॉम्प्टमधून एक पूर्ण, बरोबर, खेळण्यायोग्य आणि सादर करण्यायोग्य Roblox अनुभव तयार करू शकते. एक पैलू सांगतो की हा असा गेम नाही जो कोणीही दुसऱ्यांदा खेळायला पसंत करेल. त्या फरकाचे मोजमाप करणे, त्याला सरासरीत लपवण्याऐवजी, हेच Build मूल्यांकनाचे मुख्य उद्दिष्ट आहे.

लवकर मूल्यांकनामुळे Build कसे सुधारले 

मूल्यांकन परिणाम फक्त गुण निर्माण करत नाहीत, तर ते उत्पादन सुधारण्यासाठी कृतीयोग्य दिशा देखील देतात. वैयक्तिक घटकांच्या डिबगिंगला समग्र प्रणाली-स्तरीय चाचणीसोबत एकत्र करून, प्रमाणित प्रॉम्प्ट संचांवर ऑफलाइन बॅच मूल्यांकनांनी थेट Build च्या विकासाला आकार दिला आहे. 

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

उदाहरणार्थ, हे ऑफलाइन फरक आम्हाला विविध मॉडेल अपग्रेड्स आणि एजंट रूटिंग निर्णयांचा वैयक्तिक गुणवत्ता संकेतांवर होणारा परिणाम वेगळा करून पाहण्याची परवानगी देतात:

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

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

1. प्रकार-विशिष्ट अडथळे उलगडणे: मूल्यांकन डेटा विविध प्रकारांमधील लक्षणीय कार्यक्षमता फरकांना अधोरेखित करतो. ज्या प्रकारांमध्ये खेळ यंत्रणेचा भर असतो (उदा. आरपीजी, शूटर, रेसिंग गेम्स) त्यांना अधिक खेळण्यास अडचणी येतात. सापेक्षतः सोपी तर्कशास्त्र असलेल्या शैली (उदा. सव्हर्विवाल आणि टायकून गेम्स) प्लेटेस्टमध्ये अनेकदा चांगली कामगिरी करतात, ज्यामुळे दृश्य परिष्करण आणि UI डिझाइन हे पुढील सोडवायचे टप्पे ठरतात. शैलींमधील फरक ओळखणे आम्हाला Build गेम्समध्ये अधिक संतुलित नमुना घेऊन आमच्या मूल्यांकन संचाचा विस्तार करण्यास प्रेरित करते.
2. मूल्यांकन हार्नेस डिझाइनमधील शिकवणी: फ्रेमवर्कवरच पुनरावृत्ती केल्यामुळे आम्हाला हार्नेसच्या विश्वसनीयतेबद्दल महत्त्वाच्या धड्यांची जाणीव झाली:

• सिस्टम मेट्रिक्स विरुद्ध घटक मेट्रिक्स: स्वच्छ कोड संरचना किंवा API वापरणे खेळण्यायोग्य गेमची हमी देत नाही. आम्ही अंमलबजावणीयोग्य बग लपवण्यापासून टाळण्यासाठी अचूकता, डिझाइन आणि सादरीकरण वेगळे ठेवतो.
• हार्नेसच्या कमकुवतपणा आणि मानवी समायोजन: स्थिर तपासण्या गेम क्रॅश करणार्‍या रनटाइम अडथळ्यांना चुकवू शकतात, तर स्वयंचलित प्लेटेस्ट जटिल भौतिकशास्त्राशी झुंज देतात. आभासी न्यायाधीशांना व्यावसायिक गेम डेव्हलपर्स आणि अनुभवी समुदाय पुनरावलोककांच्या तुलनेत सातत्याने समायोजित केले जाते.
• मल्टीटर्न आणि वास्तविक ट्रॅफिकमध्ये विस्तार: कारण वास्तविक निर्माते सातत्याने पुनरावृत्ती करतात (प्रणाली जोडणे, कठीणता समायोजित करणे, बग दुरुस्त करणे), आम्ही आमच्या eval हार्नेसचा विस्तार करत आहोत जेणेकरून मल्टीटर्न संपादन आणि वास्तविक-जगातील प्रॉम्प्ट वितरणाचे मूल्यांकन करता येईल.

पुढे काय

आम्ही सध्या आमच्या Build निर्मिती मूल्यांकन प्रणालीला पाच दिशांमध्ये विस्तारित करण्यावर लक्ष केंद्रित करत आहोत:

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

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

Roblox Assistant साठी एजंटिक प्रणालींचे मूल्यांकन करण्याबाबत संबंधित माहितीसाठी, Using OpenGameEval to Benchmark Agentic AI Assistants for Roblox Studio हे पहा.