วิธีที่ Roblox ประเมินการสร้างเกม Build

Build, เครื่องมือสร้างเกมแบบ mobile-first ใหม่ของเรา, ช่วยให้ผู้ใช้ Roblox สามารถสร้างเกมโดยใช้คำสั่งข้อความและเผยแพร่ให้ผู้เล่นทั่วโลกได้ การสร้างเกมแบบครบวงจรจำเป็นต้องมีระบบเอเจนต์แบบ end-to-end สำหรับการสร้างเกม: ระบบที่ประสานงานระหว่างโค้ด ทรัพยากรภาพ ระบบเกม UI และระบบควบคุมให้เป็นผลิตภัณฑ์เดียวที่สมบูรณ์ ระบบนี้ต้องสามารถจัดการสถานการณ์ต่าง ๆ ที่เกิดขึ้นจากการป้อนข้อมูลของผู้เล่นและการโต้ตอบแบบหลายผู้เล่นได้อย่างมั่นคง ตั้งแต่การเปิดตัวเวอร์ชันอัลฟาในนิวซีแลนด์ มีผู้เล่นมากกว่า 100,000 คนใช้ Build เพื่อลองสร้างเกม และมีเกม Build ที่ถูกเผยแพร่ประมาณ 9,000 เกม1 จากผู้สร้างเกมหลายพันคนที่ใช้ Build เพื่อสร้างเกม 71% ไม่เคยใช้ Roblox Studio มาก่อน1 ซึ่งแสดงให้เห็นว่าพวกเขากำลังลองทำสิ่งใหม่ด้วย Build

แต่ผู้สร้างจะใช้เครื่องมือใหม่นี้ก็ต่อเมื่อมันใช้งานง่าย และคุณภาพของเกมที่ถูกสร้างขึ้นมีระดับสูงพอที่จะพัฒนาต่อได้ เพื่อเข้าใจคุณภาพของเกมที่ถูกสร้างด้วย Build เราจึงประเมินกระบวนการสร้างเกมตั้งแต่ต้นจนจบ และใช้ผลการประเมินเหล่านั้นร่วมกับข้อเสนอแนะจากผู้สร้างเพื่อปรับปรุงผลิตภัณฑ์ กรอบการประเมิน (eval) ของเราได้ช่วยเราจัดลำดับความสำคัญและปรับปรุงการเข้าใจเจตนา, ความเล่นได้ของ 3D และความสมบูรณ์ของเกม ตั้งแต่การเปิดตัว Build ในเวอร์ชันอัลฟาที่นิวซีแลนด์ ความพึงพอใจของผู้สร้างได้เพิ่มขึ้น 10% ผลลัพธ์ที่ไม่ตามเจตนาลดลงจาก 18% เป็น 3% และประมาณ 14% ของเซสชันที่ได้รับการกระตุ้นและ 19% ของการทดสอบการเล่นได้ถูกเผยแพร่2 ตัวชี้วัดเหล่านี้เป็นตัวชี้วัดเชิงพรรณนาของความก้าวหน้า ไม่ใช่การประมาณการเชิงสาเหตุของผลกระทบจากการประเมินเพียงอย่างเดียว

ทำไมการประเมินการสร้างเกมจึงแตกต่าง

เกมมีความท้าทายในการประเมินบางประการที่คล้ายคลึงกับระบบอื่น ๆ ที่สร้างผลงานเชิงประกอบ เช่น แอป วิดีโอ และโมเดลโลก ตัวอย่างเช่น คุณภาพขึ้นอยู่กับวิธีที่องค์ประกอบต่าง ๆ ทำงานร่วมกัน และคะแนนขององค์ประกอบใดองค์ประกอบหนึ่งเพียงอย่างเดียวไม่สามารถอธิบายผลลัพธ์ได้อย่างครบถ้วน 

สิ่งที่ทำให้เกมแตกต่างคือ ผลิตภัณฑ์เป็นระบบที่สามารถทำงานได้แบบเรียลไทม์และถูกขับเคลื่อนโดยผู้เล่น คุณสมบัติต่าง ๆ เช่น ความตอบสนอง ความมีอิสระในการตัดสินใจ ความก้าวหน้า และความรู้สึกขณะเล่นเกม เกิดขึ้นผ่านการโต้ตอบ และไม่สามารถประเมินได้อย่างครบถ้วนเพียงจากการตรวจสอบโค้ดหรือสินทรัพย์เพียงอย่างเดียว ดังนั้น เกมจึงต้องผ่านเกณฑ์มาตรฐานที่สูงเป็นพิเศษ ทั้งในด้านความถูกต้องระดับต่ำ (ไม่มีข้อบกพร่องและสามารถเล่นได้) รวมถึงประสบการณ์ผู้เล่นระดับสูง (เกมที่ให้ความรู้สึกเสร็จสมบูรณ์ ไม่ใช่เพียงต้นแบบ) 

คำถามที่เราต้องการตอบผ่านการประเมินไม่ใช่ว่าส่วนใดส่วนหนึ่งถูกต้องหรือไม่ แต่เป็นว่าผลิตภัณฑ์โดยรวมสอดคล้องกับเจตนาของผู้สร้างหรือไม่ และผู้เล่นสามารถเล่นผ่านประสบการณ์ทั้งหมดได้หรือไม่ การตอบคำถามนี้ต้องการมากกว่าหนึ่งตัวชี้วัด

สี่สัญญาณ หนึ่งกรอบงาน

กรอบงานประเมินการสร้าง Build ของเรารวมสี่สัญญาณเข้าด้วยกัน แต่ละสัญญาณตอบคำถามที่แตกต่างกัน ตรวจจับประเภทความล้มเหลวที่แตกต่างกัน และให้คะแนนเชิงปริมาณที่ชัดเจน:

1. คุณภาพของข้อกำหนดเกม (คะแนน 0 - 100): Build เป็นเครื่องมือสร้างเกมแบบครบวงจร: มันแปลคำสั่งของผู้สร้างเป็นข้อกำหนด แล้วใช้ข้อกำหนดนั้นเพื่อสร้างเกม ผู้ประเมินจะตรวจสอบว่าข้อกำหนดดังกล่าวตัดสินใจเรื่องสำคัญอย่างชัดเจน รักษาเจตนาของผู้สร้าง พิจารณาความเป็นไปได้ภายในสภาพแวดล้อมการทำงานของ Roblox และหลีกเลี่ยงการสร้างข้อกำหนดที่ไม่เคยถูกระบุไว้

2. คุณภาพเกมแบบสถิต (คะแนน 0 - 100): ผู้ประเมินแบบสถิตจะตรวจสอบเกมที่สร้างขึ้นในโหมดแก้ไขของ Roblox Studio ซึ่งรวมถึงโครงสร้างเกม สคริปต์ ทรัพยากร คุณสมบัติ การเชื่อมต่อ และขอบเขตระหว่างไคลเอนต์/เซิร์ฟเวอร์ เราพยายามตอบคำถามสองข้อในขั้นตอนนี้ ข้อแรกคือเกมถูกสร้างขึ้นอย่างถูกต้องหรือไม่: การนำระบบที่จำเป็นมาใช้ การเลือก API ของเอนจินและระบบเครือข่าย การมีอยู่ของระบบควบคุมและองค์ประกอบ UI ที่คาดหวัง ความมั่นคงและความสอดคล้องของสถาปัตยกรรมเกม 

คำถามที่สองคือว่าเกมถูกออกแบบมาเพื่อสร้างความสนุกหรือไม่: ความลึกของวงจรหลัก (core loop), ความหลากหลายและระดับความท้าทายของเนื้อหา, การก้าวหน้าในเกม, ความสามารถในการเล่นซ้ำได้, และนวัตกรรมที่เกินกว่ามาตรฐานของประเภทเกมนั้น เกมอาจมีสถาปัตยกรรมที่สะอาดแต่ขาดความลึกของเนื้อหา หรือเต็มไปด้วยไอเดียแต่การเชื่อมต่อไม่ดี 

การแยกมุมมองทั้งสองด้านและวัดผลตามแนวทางปฏิบัติที่ดีที่สุด จะช่วยให้เราเข้าใจอย่างละเอียดมากขึ้นว่าเกมมีจุดอ่อนอยู่ที่ใด

3. การทดสอบเล่น (อัตราผ่าน 0 - 100%): ผู้ประเมินการทดสอบเล่นจะเปิดเกมและดำเนินการตามแผนการทดสอบด้วยข้อมูลนำเข้าที่เหมือนผู้เล่นจริง รวมถึงการแตะ คลิก การกดปุ่ม และการนำทาง แทนที่จะเรียกเหตุการณ์จากโค้ด แผนการทดสอบแบบกรณีต่อกรณีจะตรวจสอบว่าเกมสามารถเริ่มต้น ตอบสนอง ดำเนินไป ฟื้นตัวจากความผิดพลาด และไม่เกิดข้อผิดพลาดขณะทำงานได้หรือไม่ แต่ละรายการจะได้รับการประเมินแบบผ่าน/ไม่ผ่าน และรายงานเป็นอัตราการผ่านที่ปรับตามระดับความสำคัญ พร้อมด้วยคำตัดสินแบบเรียบง่ายว่า “เล่นได้” หรือ “เล่นไม่ได้” เราทำการทดสอบซ้ำเพื่อวัดความสม่ำเสมอ

4. คุณภาพทางภาพและประสบการณ์ (คะแนน 0 - 100): บางสิ่งที่สำคัญที่สุดต่อรูปลักษณ์และบรรยากาศของเกมไม่สามารถอ่านได้จากโค้ด ดังนั้นผู้ประเมินด้านภาพจะให้คะแนนการนำเสนอด้วยตนเอง โดยใช้คลิปเกมเพลย์ที่บันทึกไว้บนวิวพอร์ตที่แสดงอุปกรณ์ต่าง ๆ เกณฑ์การประเมินนี้พิจารณาเฉพาะรูปลักษณ์และเสียงของเกม โดยอิงจากคุณภาพของแอสเซท การเสร็จสิ้นของ UI การเคลื่อนไหว แสง และเสียง คำถามหลักคือ: เกมนี้ดูเหมือนผลิตภัณฑ์ที่พร้อมออกสู่ตลาด หรือเหมือนต้นแบบ? การแยกส่วนภาพออกจากกลไกเกมหมายความว่า “โค้ดทำงานได้” และ “เกมดูเสร็จสมบูรณ์” จะไม่ถูกรวมเป็นคะแนนเดียวที่อาจทำให้เข้าใจผิด

นอกเหนือจากสัญญาณที่ได้รับการให้คะแนนแล้ว ทุกครั้งที่รันยังบันทึกเมตริกที่ให้ข้อมูลเพิ่มเติม เช่น การใช้โทเคน การเรียกใช้เครื่องมือ ทักษะที่ถูกทริกเกอร์ และความล่าช้า เมตริกเหล่านี้ไม่ส่งผลต่อคะแนนการประเมิน แต่อาจช่วยอธิบายว่าผลลัพธ์นั้นเกิดขึ้นได้อย่างไร และตรวจจับการถดถอยที่เกณฑ์การประเมินอาจมองข้าม เช่น การสร้างเกมที่ใช้ทรัพยากรเพิ่มขึ้นเป็นสองเท่าสำหรับเกมเดียวกัน

สัญญาณเหล่านี้สอดคล้องกับข้อผิดพลาดที่ตรวจพบ:

การเดินผ่านเส้นทาง 3D Obby ที่ถูกกำหนด

สัญญาณเหล่านี้สังเกตเห็นได้ง่ายที่สุดจากคำอธิบายจริง ตัวอย่างเช่น “เกม Obby 3D ที่แท้จริง พร้อมด้วยแพลตฟอร์มเริ่มต้น อุปสรรคที่เคลื่อนที่ จุดตรวจสอบ และเส้นชัย” Obby เป็นประเภทเกมแพลตฟอร์มที่ได้รับความนิยมบน Roblox ความตั้งใจของผู้สร้างชัดเจน แม้ว่าจะไม่ได้กำหนดรายละเอียดการนำไปใช้ทุกประการก็ตาม ผู้สร้างจำเป็นต้องเติมเต็มรายละเอียดด้วยสมมติฐานที่สมเหตุสมผล

แผนงานและข้อกำหนด

ทีมพัฒนาได้สร้างเอกสารข้อกำหนดสำหรับเกมใหม่ชื่อ Skyforge Ascent ซึ่งอธิบายรายละเอียดเกี่ยวกับเส้นทาง 5 ส่วนที่มีจุดตรวจสอบและ 3 ประเภทของอันตราย เอกสารนี้กำหนดวงจรหลัก (core loop), เส้นโค้งความยาก (difficulty curve), ทิศทางศิลปะ (art direction), หน้าจอต่างๆ, ชั้นทับ (overlays) และระบบควบคุม (controls) ระบบประเมินข้อกำหนด (Spec eval) ให้คะแนน 91/100 โดยได้รับคะแนนเต็มในด้านการครบถ้วน (completeness), การปฏิบัติตามข้อกำหนดอย่างทันท่วงที (prompt adherence), ความเป็นไปได้ (feasibility) และความสอดคล้องภายใน (internal consistency) ส่วนการหักคะแนนเกิดจากสองด้านเฉพาะ ได้แก่ รายละเอียดการนำไปใช้ (implementation detail) และการครอบคลุมเกณฑ์การยอมรับ (acceptance-criteria coverage) 

เอกสารข้อกำหนดนี้ไม่เคยกำหนดค่าคงที่เชิงตัวเลขไว้อย่างชัดเจน เช่น ความเร็วการหมุน ระยะทางในการลื่นไถล เวลาการเปลี่ยนไทล์ ขนาดของแพลตฟอร์ม หรือความสูงของระนาบรีเซ็ต ดังนั้นวิศวกรจึงยังต้องกำหนดค่าเหล่านี้ขึ้นเอง นอกจากนี้ เกณฑ์การยอมรับบางข้อ (เช่น “ประมาณ 24 แพลตฟอร์ม” หรือ “พาเลตสี Celestial Forge”) ไม่สามารถตรวจสอบได้แบบชัดเจน คะแนนสเปคที่สูงเพียงพิสูจน์ว่าเอกสารนั้นพร้อมสำหรับการพัฒนาเท่านั้น ส่วนว่าข้อผูกมัดเหล่านั้นจะยังคงอยู่ได้เมื่อเผชิญกับการพัฒนาเกมจริงหรือไม่ คือสิ่งที่สามขั้นตอนต่อไปจะวัดผล

การตรวจสอบแบบสถิต: คุณภาพรหัสและคุณภาพเนื้อหา

ผู้ตัดสินเสมือนได้ตรวจสอบไฟล์สถานที่ของ Skyforge Ascent โดยไม่ต้องเล่นมัน และทั้งสองมุมมองการประเมินได้ข้อสรุปที่แตกต่างกัน

มุมมองด้านวิศวกรรม ซึ่งอ่านไฟล์สถานที่เดียวกัน ให้คะแนน 98/100 มันพบการสร้างตัวอย่างที่ยอดเยี่ยมด้วย 5 ส่วนและ 3 อุปสรรคที่เคลื่อนไหว ซึ่งตอบสนองเจตนาของผู้สร้างอย่างสมบูรณ์ โดยใช้จุดตรวจสอบลำดับที่ควบคุมโดยเซิร์ฟเวอร์ ระบบรีเซ็ตเมื่อตก และ UI ที่สร้างบนเฟรมเวิร์ก StyleSheet ทุกสิ่งที่ระบุในสเปคได้รับการส่งมอบครบถ้วน ปัญหาเดียวคือการส่งออกฟังก์ชันช่วยเหลือ 2 ตัวที่ไม่ได้ใช้งาน

มุมมองด้านการออกแบบให้คะแนน 31/100 ทุกอย่างทำงานได้ แต่เกมได้คะแนนศูนย์ในด้านการพัฒนาความก้าวหน้า ความสามารถเล่นซ้ำได้ ความอิสระของผู้เล่น และจุดดึงดูดที่เป็นเอกลักษณ์ ลูปหลักของเกมนั้นเรียบง่ายและเป็นเส้นตรง — ไปถึงจุดตรวจสอบแต่ละจุด แล้วข้ามเส้นชัย — โดยมีความหลากหลายน้อยมากในแต่ละการเล่น และไม่มีเหตุผลให้กลับมาเล่นซ้ำ เป็นเกมแบบ obby ที่พบได้ทั่วไป ไม่ใช่เกมที่มีจุดดึงดูดเป็นของตัวเอง

ช่องว่างนี้คือข้อค้นพบหลัก คุณภาพโค้ดและคุณภาพเนื้อหาเป็นมิติที่แตกต่างกันโดยพื้นฐาน และเวอร์ชันหนึ่งอาจเกือบสมบูรณ์แบบในด้านหนึ่ง แต่ล้มเหลวในอีกด้านหนึ่ง คะแนนคุณภาพแบบผสมเดียวจะเฉลี่ยทั้งสองด้านจนกลายเป็นค่าที่ไร้ความหมาย

การทดสอบเกม

ตัวแทนทดสอบได้เล่นเกมวิ่งนี้โดยใช้การป้อนข้อมูลที่เหมือนผู้เล่นจริง และผ่านทั้ง 9 ข้อในแผนการทดสอบ: การสร้างตัวละครบนแพลตฟอร์มเริ่มต้น, การเคลื่อนที่ผ่านรูปทรง 3 มิติข้ามช่องว่าง, การรับผลกระทบจากอันตราย, การทริกเกอร์จุดตรวจสอบและระบบฟื้นตัวอัตโนมัติเมื่อตก, การวิ่งจนจบ, และการเริ่มต้นใหม่ — ทั้งหมดนี้โดยไม่เกิดข้อผิดพลาดขณะรันโปรแกรมเลย ในการทดสอบครั้งนี้ Skyforge Ascent ได้คะแนน 100/100 ในการทดสอบการเล่น

คะแนนการทดสอบการเล่นที่สมบูรณ์แบบเพียงพิสูจน์ว่ากลไกเกมทำงานได้และเกมสามารถเล่นได้ทางเทคนิคตั้งแต่ต้นจนจบ แต่ไม่ได้บ่งชี้ว่าเกมนั้นน่าสนใจหรือสนุกในการเล่นจริงหรือไม่ — ความแตกต่างนี้เองคือเหตุผลที่มุมมองการออกแบบให้คะแนนเกมนี้เพียง 31

คุณภาพทางภาพ

สุดท้าย ระบบประเมินได้ให้คะแนนเซสชันที่บันทึกไว้บนหน้าต่างขนาดโทรศัพท์มือถือสำหรับการนำเสนอภาพ Skyforge Ascent ได้คะแนน 86/100: ภาพดูสะอาดตา สอดคล้องกัน และสอดคล้องกับภาพของเกมแนว platformer แบบทั่วไปได้อย่างลงตัว; รูปทรงแพลตฟอร์มที่อ่านได้ง่าย; อุปสรรคที่มองเห็นได้ชัดเจน; และ HUD ที่ทันสมัยและไม่รบกวนสายตา ข้อจำกัดทางภาพเล็กน้อยทำให้คะแนนไม่ถึงระดับสมบูรณ์แบบ แต่ไม่มีส่วนใดที่เสียหาย และไม่มีสิ่งใดที่จะทำให้ผู้เล่นหยุดเลื่อนหน้าจอได้

Trace Metrics

การรันเดียวกันนี้ยังบันทึกตัวชี้วัดกระบวนการด้วย เกมใช้เวลาประมาณแปดนาทีในการสร้าง ไม่มีความผิดพลาดของเครื่องมือ และ Build ได้ใช้ทักษะด้าน 3D, UI, การแก้ไขสคริปต์, การแทรกสินทรัพย์ และเสียงเกม ตัวชี้วัดเหล่านี้ไม่ส่งผลต่อคะแนนการประเมินโดยตรง แต่ช่วยบอกเราว่าเกมถูกสร้างขึ้นอย่างไร และจะแจ้งเตือนหากการสร้างในอนาคตช้าลงหรือมีค่าใช้จ่ายสูงขึ้นโดยไม่มีประโยชน์เพิ่มเติม

ในห้าขั้นตอน Skyforge Ascent ได้รับคะแนนที่แตกต่างกันในด้านสเปกเกม คุณภาพโค้ด คุณภาพเนื้อหา การทดสอบเล่น และคุณภาพภาพ สี่ในห้าด้านนี้ชี้ให้เห็นว่า Build สามารถเปลี่ยนคำสั่งเดียวให้กลายเป็นประสบการณ์ Roblox ที่สมบูรณ์ ถูกต้อง สามารถเล่นได้ และนำเสนอได้ ส่วนอีกด้านหนึ่งระบุว่านี่ไม่ใช่เกมที่ใครจะเลือกเล่นซ้ำเป็นครั้งที่สอง การวัดช่องว่างนี้ แทนที่จะเฉลี่ยให้หายไป คือจุดสำคัญของการประเมิน Build

การประเมินในระยะเริ่มต้นได้ปรับปรุง Build อย่างไร 

ผลการประเมินไม่เพียงสร้างคะแนน แต่ยังให้ทิศทางที่สามารถนำไปปฏิบัติได้เพื่อปรับปรุงผลิตภัณฑ์ โดยการผสมผสานการดีบักส่วนประกอบแต่ละส่วนกับการทดสอบระดับระบบแบบองค์รวม การประเมินแบบแบทช์ออฟไลน์ผ่านชุดคำสั่งมาตรฐานได้ช่วยกำหนดทิศทางการพัฒนา Build อย่างตรงไปตรงมา 

1. การแก้ไขจุดปัญหาของผู้สร้างในเวอร์ชันอัลฟาอย่างรวดเร็ว: ในการเปิดตัวเวอร์ชันอัลฟาที่นิวซีแลนด์ ผู้ใช้ได้ให้ข้อเสนอแนะว่า Build บางครั้งสร้างเกม 2D ทั้งที่พวกเขาต้องการเกม 3D กรอบงานการประเมินนี้ช่วยให้ทีมของเราปรับปรุงความสามารถด้าน 3D ของ Build ได้อย่างรวดเร็ว ภายในสองสัปดาห์ เราได้ปรับปรุงความสามารถของ Build ในการเข้าใจเจตนาของผู้ใช้ในการสร้างเกม 3D — แม้พวกเขาจะไม่ได้ระบุอย่างชัดเจน เรายังปรับปรุงความเล่นได้และความละเอียดของ 3D โดยการแก้ไขปัญหาทั่วไปเกี่ยวกับการจัดวางวัตถุ แสงสว่าง และอื่นๆ ตั้งแต่นั้นมา ข้อร้องเรียนประเภท “ไม่ใช่สิ่งที่ผมต้องการ” ลดลงจาก 18% เป็น 3% ของข้อร้องเรียนทั้งหมด; ปฏิกิริยาความไม่พอใจโดยรวมหลังการทดสอบเล่นลดลง 10% points เรายังได้สะสมความรู้จากการปรับปรุงกรอบงานเองด้วย 
2. การเปรียบเทียบประสิทธิภาพระหว่างโมเดลและสถาปัตยกรรม: เราใช้เฟรมเวิร์กการประเมินของเราเพื่อเปรียบเทียบประสิทธิภาพการตั้งค่าของระบบ Build อย่างเข้มงวดกับชุดคำสั่งมาตรฐาน ก่อนที่จะนำการเปลี่ยนแปลงไปใช้ในระบบผลิต รายงานการประเมิน A/B แบบออฟไลน์จะเปรียบเทียบเวอร์ชันที่เสนอให้ปล่อยกับค่าพื้นฐานของระบบผลิตในทั้งสี่มิติ: 

ตัวอย่างเช่น การเปรียบเทียบแบบออฟไลน์เหล่านี้ช่วยให้เราสามารถแยกวิเคราะห์ได้ว่า การอัปเกรดโมเดลต่าง ๆ และการตัดสินใจกำหนดเส้นทางของเอเจนต์ส่งผลต่อสัญญาณคุณภาพแต่ละตัวอย่างไร:

• ประสิทธิภาพของโมเดลพื้นฐาน: การอัปเกรดโมเดลพื้นฐานของเราให้ผลลัพธ์ที่ดีขึ้นอย่างสม่ำเสมอในทุกสัญญาณ — ซึ่งส่งผลให้มีการสร้างที่ล้มเหลวน้อยลงในการลองครั้งแรก, ความละเอียดทางภาพที่ดีขึ้น, และเนื้อหาเกมเพลย์ที่ลึกซึ้งยิ่งขึ้น
• สถาปัตยกรรมการกำหนดเส้นทางของเอเจนต์: ในทางตรงกันข้าม การมอบหมายงานย่อยเฉพาะให้กับโมเดลน้ำหนักเบาในระบบเอเจนต์คู่ ช่วยรักษาความลึกและความหลากหลายของเนื้อหา แต่กลับก่อให้เกิดการถดถอยอย่างรุนแรงในด้านความเล่นได้และคุณภาพภาพ

1. การติดตามเกณฑ์คุณภาพพื้นฐานในแบบการสร้างต่าง ๆ: เรายังใช้กรอบงานนี้เพื่อเข้าใจคุณภาพปัจจุบันของเวอร์ชันที่สร้างขึ้นในช่วงเวลาต่าง ๆ ด้วยชุดข้อมูลการประเมินที่เกี่ยวข้องที่สุด ชุดข้อมูลเหล่านี้ให้ภาพรวมของงานสร้างที่กว้างขึ้นและซับซ้อนขึ้นเรื่อย ๆ
   ชุดข้อมูลแรกสุดประกอบด้วยเกม 2D ทั้งหมดที่มีกลไกที่ค่อนข้างเรียบง่าย ตรรกะของเกมสร้างได้ง่าย ดังนั้นคะแนนการทดสอบการเล่นจึงมีแนวโน้มสูงขึ้น; ในทางกลับกัน คะแนนเนื้อหาอยู่ในระดับต่ำด้วยเหตุผลเดียวกัน
   เมื่อเราเปลี่ยนจุดเน้นไปยังเกม 3D การกระจายคะแนนจะเปลี่ยนไปอย่างเป็นธรรมชาติ: การเล่นโดยไม่มีข้อผิดพลาดกลายเป็นเรื่องที่ท้าทายมากขึ้น ทำให้คะแนนการทดสอบการเล่นลดลง คะแนนด้านภาพยังคงไม่เปลี่ยนแปลง เนื่องจากขาดการขัดเกลาสินทรัพย์ ทำให้เกมมีลักษณะเหมือนต้นแบบ คะแนนด้านเนื้อหามีค่าสูงขึ้น เนื่องจากเกม 3D มีศักยภาพที่จะมีความลึกมากขึ้น — แต่คะแนนรวมมักยังคงอยู่ในระดับต่ำ เนื่องจากคำสั่งแบบรอบเดียว (single-turn prompts) ให้พื้นที่จำกัดสำหรับการขยายเนื้อหา

1. การค้นพบจุดคอขวดเฉพาะประเภทเกม: ข้อมูลการประเมินยังชี้ให้เห็นถึงความแตกต่างด้านประสิทธิภาพที่ชัดเจนระหว่างประเภทเกมต่าง ๆ ประเภทเกมที่มีกลไกการเล่นที่ซับซ้อน (เช่น RPG, เกมยิง, เกมแข่งรถ) มักพบปัญหาด้านความเล่นได้มากขึ้น ประเภทเกมที่มีตรรกะค่อนข้างเรียบง่าย (เช่น เกมเอาตัวรอดและเกมบริหารธุรกิจ) มักแสดงผลการทำงานที่ดีกว่าในการทดสอบเล่น ทำให้การปรับปรุงภาพให้ดูดีและการออกแบบ UI เป็นจุดสำคัญถัดไปที่ต้องแก้ไข การเข้าใจความแตกต่างระหว่างประเภทเกมช่วยกระตุ้นให้เราขยายชุดข้อมูลการประเมินด้วยการสุ่มตัวอย่างที่สมดุลมากขึ้นจากเกมใน Build
2. บทเรียนที่ได้จากการออกแบบระบบประเมิน: การปรับปรุงกรอบงานเองได้สอนเราบทเรียนสำคัญเกี่ยวกับความน่าเชื่อถือของระบบประเมิน:

• ตัวชี้วัดระบบเทียบกับตัวชี้วัดส่วนประกอบ: โครงสร้างโค้ดที่สะอาดหรือการใช้ API ไม่รับประกันว่าเกมจะเล่นได้ เราจึงแยกความถูกต้อง การออกแบบ และการนำเสนอออกจากกัน เพื่อหลีกเลี่ยงการซ่อนข้อผิดพลาดที่สามารถแก้ไขได้
• จุดอ่อนของระบบประเมินผลและการปรับเทียบโดยมนุษย์: การตรวจสอบแบบสถิตอาจพลาดข้อผิดพลาดที่ทำให้เกมหยุดทำงานในระหว่างรันไทม์ ในขณะที่การทดสอบเล่นอัตโนมัติมักมีปัญหาเมื่อต้องรับมือกับฟิสิกส์ที่ซับซ้อน ผู้ตัดสินเสมือนจริงได้รับการปรับเทียบอย่างต่อเนื่องกับนักพัฒนาเกมมืออาชีพและผู้ตรวจสอบจากชุมชนที่มีประสบการณ์
• การขยายสู่การแก้ไขหลายรอบและข้อมูลจริง: เนื่องจากผู้สร้างเกมจริงปรับปรุงอย่างต่อเนื่อง (เพิ่มระบบ ปรับระดับความยาก แก้ไขข้อผิดพลาด) เราจึงกำลังขยายระบบประเมินของเราเพื่อประเมินการแก้ไขหลายรอบและการแจกจ่ายคำสั่งในโลกจริง

ขั้นตอนต่อไป

ขณะนี้เรากำลังมุ่งเน้นการขยายระบบประเมินการสร้าง Build ของเราในห้าทิศทาง:

1. การครอบคลุมที่กว้างขึ้นในทุกประเภทเกม ประสบการณ์ 2D/2.5D/3D สถานการณ์ผู้เล่นหลายคน และระดับความซับซ้อน
2. การสนับสนุนที่แข็งแกร่งยิ่งขึ้นสำหรับการแก้ไขแบบหลายรอบ
3. หลักฐานจากการทดสอบเล่น ภาพหน้าจอ วิดีโอ และเสียงที่เชื่อถือได้มากขึ้น
4. การปรับเทียบกับคะแนนประเมินของมนุษย์ในขนาดใหญ่ และกรณีอ้างอิงที่นำโดยผู้สร้าง
5. การบูรณาการที่ดีขึ้นระหว่างการประเมินแบบออฟไลน์ สัญญาณผลิตภัณฑ์ออนไลน์ และการทดสอบการถดถอย

เป้าหมายระยะยาวของเราคือระบบประเมินที่โปร่งใสและพัฒนาอย่างต่อเนื่อง ซึ่งวัด Build ในระดับที่ผู้สร้างให้ความสำคัญ: คุณภาพของประสบการณ์ที่พวกเขาสามารถสร้าง ทดสอบ แบ่งปัน และพัฒนาต่อไปได้ ปัจจุบัน สัญญาณเหล่านี้ถูกใช้เพื่อประเมินเกมที่สร้างโดย Build เมื่อเวลาผ่านไป เมื่อเราปรับปรุงและปรับเทียบสัญญาณเหล่านี้ให้สอดคล้องกับการตัดสินของมนุษย์มากขึ้น สัญญาณเหล่านี้อาจถูกนำไปประยุกต์ใช้กับกระบวนการสร้างอื่นๆ และช่วยสร้างภาษาที่ใช้ร่วมกันเพื่อเข้าใจคุณภาพเกมในระบบนิเวศ Roblox ที่กว้างขึ้น

สำหรับข้อมูลที่เกี่ยวข้องกับการประเมินระบบเอเจนติกสำหรับ Roblox Assistant โปรดดูบทความ “การใช้ OpenGameEval เพื่อเปรียบเทียบประสิทธิภาพของเอเจนติก AI Assistant สำหรับ Roblox Studio”