Cách Roblox đánh giá việc tạo trò chơi Build

Build, công cụ sáng tạo ưu tiên thiết bị di động mới của chúng tôi, cho phép người dùng Roblox tạo trò chơi bằng các lời nhắc văn bản và phát hành trò chơi đó cho người chơi trên toàn thế giới. Để tạo ra một trò chơi toàn diện, cần có một hệ thống tạo trò chơi toàn diện từ đầu đến cuối: một hệ thống phối hợp mã, tài sản hình ảnh, hệ thống lối chơi, giao diện người dùng và các điều khiển thành một sản phẩm tổng hợp duy nhất. Hệ thống này phải xử lý một cách mạnh mẽ các tình huống khác nhau phát sinh từ đầu vào của người chơi và các tương tác nhiều người chơi. Kể từ khi ra mắt phiên bản alpha tại New Zealand, đã có hơn 100.000 người chơi sử dụng Build để thử tạo trò chơi, và khoảng 9.000 trò chơi được tạo bằng Build đã được phát hành.¹ Trong số hàng nghìn người đã dùng Build để tạo trò chơi, 71% chưa từng sử dụng Roblox Studio trước đây,¹ điều này cho thấy họ đang thử nghiệm điều mới mẻ với Build.

Tuy nhiên, các nhà sáng tạo chỉ sử dụng công cụ mới này nếu nó dễ sử dụng và chất lượng các trò chơi do nó tạo ra đủ cao để phát triển tiếp. Để hiểu rõ chất lượng các trò chơi được tạo ra bằng Build, chúng tôi đánh giá toàn bộ hành trình sáng tạo và sử dụng các đánh giá này cùng với phản hồi từ nhà sáng tạo để cải thiện sản phẩm. Khung đánh giá (eval) của chúng tôi đã giúp chúng tôi ưu tiên và cải thiện việc hiểu ý định, khả năng chơi 3D và độ hoàn thiện. Kể từ khi ra mắt phiên bản alpha của Build tại New Zealand, mức độ hài lòng của các nhà sáng tạo đã tăng 10%, các kết quả không mong muốn đã giảm từ 18% xuống 3%, và khoảng 14% các phiên được gợi ý cùng 19% các phiên thử nghiệm đã được xuất bản.² Đây là các chỉ số mô tả tiến bộ, chứ không phải là ước tính nhân quả về tác động của việc đánh giá.

Tại sao việc đánh giá sáng tạo trò chơi lại khác biệt

Trò chơi cũng gặp phải một số thách thức đánh giá tương tự như các hệ thống khác tạo ra các sản phẩm phức hợp, chẳng hạn như ứng dụng, video và mô hình thế giới. Ví dụ, chất lượng phụ thuộc vào cách các thành phần khác nhau tương tác với nhau, và không có điểm số của bất kỳ thành phần nào có thể mô tả đầy đủ kết quả. 

Điều làm nên sự khác biệt của trò chơi là sản phẩm này là một hệ thống có thể thực thi, hoạt động theo thời gian thực và được điều khiển bởi người chơi. Các đặc tính như độ phản hồi, khả năng tự chủ, tiến trình và cảm giác khi chơi xuất hiện thông qua tương tác và không thể được đánh giá đầy đủ chỉ bằng cách kiểm tra mã nguồn hoặc tài nguyên. Do đó, một trò chơi phải vượt qua một tiêu chuẩn đặc biệt cao về tính chính xác ở cấp độ thấp (không có lỗi và có thể chơi được), cũng như trải nghiệm người chơi ở cấp độ cao (một trò chơi mang lại cảm giác hoàn thiện, không phải là bản thử nghiệm). 

Câu hỏi mà chúng tôi tìm cách trả lời thông qua đánh giá không phải là liệu một phần nào đó có chính xác hay không, mà là liệu sản phẩm tổng thể có phù hợp với ý định của người sáng tạo hay không, và liệu người chơi có thể trải nghiệm trọn vẹn trò chơi hay không. Để trả lời câu hỏi đó, cần nhiều hơn một chỉ số.

Bốn tín hiệu, một khung đánh giá

Khung đánh giá sáng tạo Build của chúng tôi kết hợp bốn tín hiệu. Mỗi tín hiệu trả lời một câu hỏi khác nhau, phát hiện một loại lỗi khác nhau và đưa ra một điểm số định lượng cụ thể:

1. Chất lượng đặc tả trò chơi (điểm từ 0 đến 100): Build là tác nhân sáng tạo từ đầu đến cuối: Nó chuyển đổi lời nhắc của người sáng tạo thành một đặc tả, sau đó sử dụng đặc tả đó để tạo ra trò chơi. Người đánh giá sẽ xem xét liệu đặc tả có đưa ra các quyết định quan trọng một cách rõ ràng, giữ nguyên ý định của người sáng tạo, xem xét tính khả thi trong thời gian chạy của Roblox và tránh đưa ra các yêu cầu chưa từng được nêu ra hay không.

2. Chất lượng trò chơi tĩnh (điểm từ 0 đến 100): Người đánh giá phần tĩnh kiểm tra trò chơi được tạo ra trong chế độ chỉnh sửa của Roblox Studio. Điều này bao gồm cấu trúc trò chơi, tập lệnh, tài sản, thuộc tính, kết nối và ranh giới giữa máy khách và máy chủ. Ở giai đoạn này, chúng tôi tìm cách trả lời hai câu hỏi. Câu hỏi đầu tiên là liệu trò chơi có được xây dựng đúng cách hay không: việc triển khai các hệ thống bắt buộc, lựa chọn API của engine và mạng, sự hiện diện của các điều khiển và thành phần giao diện người dùng (UI) như mong đợi, cũng như tính vững chắc và nhất quán của kiến trúc trò chơi. 

Câu hỏi thứ hai là liệu trò chơi có được thiết kế để mang lại sự thú vị hay không: độ sâu của vòng lặp cốt lõi, sự đa dạng và sự leo thang của nội dung, tiến trình, khả năng chơi lại và sự đổi mới vượt ra ngoài khuôn mẫu của thể loại. Một trò chơi có thể có kiến trúc gọn gàng nhưng không có chiều sâu về nội dung, hoặc đầy ắp ý tưởng nhưng kết nối kém. 

Việc tách biệt hai khía cạnh này và so sánh với các tiêu chuẩn tốt nhất sẽ giúp chúng ta có cái nhìn chi tiết hơn về những điểm yếu của trò chơi.

3. Thử nghiệm chơi (tỷ lệ đạt từ 0 - 100%): Người đánh giá thử nghiệm sẽ chạy trò chơi và thực hiện kế hoạch thử nghiệm với các thao tác đầu vào giống như người chơi thực, bao gồm chạm, nhấp chuột, gõ phím và điều hướng, thay vì kích hoạt các sự kiện từ mã nguồn. Một kế hoạch kiểm thử theo từng trường hợp sẽ kiểm tra xem trò chơi có khởi động, phản hồi, tiến triển, phục hồi sau lỗi và không gặp lỗi thời gian chạy hay không. Mỗi mục là một kết quả đỗ/trượt nhị phân, được báo cáo dưới dạng tỷ lệ đỗ được tính theo trọng số cấp độ cùng với kết luận đơn giản là có thể chơi được/không thể chơi được. Chúng tôi lặp lại các lần chạy để đo lường tính nhất quán.

4. Chất lượng hình ảnh và trải nghiệm (điểm từ 0 đến 100): Một số yếu tố quan trọng nhất đối với hình ảnh và cảm giác của trò chơi không thể đánh giá qua mã nguồn, do đó chuyên gia đánh giá hình ảnh sẽ chấm điểm phần trình bày độc lập dựa trên các đoạn gameplay được ghi lại trên các khung nhìn mô phỏng các thiết bị khác nhau. Tiêu chí này chỉ tập trung vào cách trò chơi trông và nghe như thế nào dựa trên chất lượng tài nguyên, độ hoàn thiện giao diện người dùng, chuyển động, ánh sáng và âm thanh. Câu hỏi cốt lõi là: Trò chơi có trông giống một sản phẩm sẵn sàng phát hành hay chỉ là một bản thử nghiệm? Việc tách biệt yếu tố hình ảnh khỏi cơ chế gameplay đảm bảo rằng “mã nguồn hoạt động” và “trò chơi trông hoàn thiện” không bị gộp chung thành một điểm số gây hiểu lầm.

Bên cạnh các tín hiệu được chấm điểm, mỗi lần chạy đều ghi lại các chỉ số chỉ mang tính thông tin, như việc sử dụng mã thông báo, các lệnh gọi công cụ, các kỹ năng được kích hoạt và độ trễ. Các chỉ số này không ảnh hưởng đến điểm đánh giá, nhưng chúng có thể giải thích cách một kết quả được tạo ra và phát hiện các sự suy giảm mà bảng đánh giá bỏ sót, như một bản dựng tốn gấp đôi chi phí cho cùng một trò chơi.

Các tín hiệu tương ứng với các lỗi mà chúng phát hiện:

Khám phá một màn chơi 3D Obby có hướng dẫn

Các tín hiệu dễ nhận biết nhất trên một lời nhắc thực tế. Ví dụ: “Một trò chơi Obby 3D thực sự, với bục xuất phát, chướng ngại vật di chuyển, điểm kiểm tra và vạch đích.” Obby là một thể loại trò chơi nền tảng phổ biến trên Roblox. Ý định của người sáng tạo rất rõ ràng, ngay cả khi nó không quy định từng chi tiết thực hiện. Người xây dựng cần điền vào các chi tiết bằng những giả định hợp lý.

Kế hoạch và Thông số kỹ thuật

Nhóm phát triển đã tạo ra một tài liệu thông số kỹ thuật cho một trò chơi mới có tên Skyforge Ascent, trong đó mô tả chi tiết một lộ trình gồm năm phần với các điểm kiểm tra và ba loại mối nguy hiểm. Tài liệu này xác định vòng lặp cốt lõi, đường cong độ khó, hướng nghệ thuật, màn hình, lớp phủ và các điều khiển. Đánh giá thông số kỹ thuật cho điểm 91/100, đạt điểm tối đa về tính đầy đủ, tuân thủ kịp thời, tính khả thi và tính nhất quán nội bộ. Điểm trừ đến từ hai khía cạnh cụ thể: chi tiết triển khai và phạm vi tiêu chí chấp nhận. 

Bản đặc tả kỹ thuật không bao giờ xác định các hằng số số học, chẳng hạn như tốc độ quay, khoảng cách trượt, thời gian gạch, kích thước nền tảng hoặc chiều cao mặt phẳng thiết lập lại, do đó kỹ sư vẫn phải tự xác định chúng. Ngoài ra, một số tiêu chí chấp nhận (như “khoảng 24 nền tảng” hoặc “bảng màu Celestial-Forge”) không thể kiểm chứng một cách nghiêm ngặt. Điểm số cao của bản đặc tả chỉ chứng minh rằng tài liệu đã sẵn sàng để triển khai. Việc liệu những cam kết đó có tồn tại được khi tiếp xúc với quá trình phát triển trò chơi thực tế hay không chính là điều mà ba giai đoạn tiếp theo sẽ đánh giá.

Kiểm tra tĩnh: Chất lượng mã và chất lượng nội dung

Thẩm phán ảo đã kiểm tra tệp placefile của Skyforge Ascent mà không cần chơi thử, và hai góc nhìn đánh giá đã đưa ra kết luận khác nhau.

Tiêu chí kỹ thuật, khi đọc cùng một tệp placefile, đã chấm điểm 98/100. Tiêu chí này nhận thấy một bản dựng mẫu mực với năm phần và ba mối nguy hiểm di chuyển, hoàn toàn đáp ứng ý định của người sáng tạo bằng cách sử dụng các điểm kiểm tra tuần tự có thẩm quyền từ máy chủ, hệ thống thiết lập lại khi rơi và giao diện người dùng được xây dựng trên khung StyleSheet. Mọi thứ được nêu trong thông số kỹ thuật đều đã được thực hiện. Vấn đề duy nhất là hai hàm trợ giúp xuất khẩu không được sử dụng.

Góc nhìn thiết kế chấm 31/100. Mọi thứ đều hoạt động, nhưng trò chơi nhận điểm 0 về tiến trình, khả năng chơi lại, sự chủ động của người chơi và điểm nhấn độc đáo. Vòng lặp cốt lõi đơn giản và tuyến tính — đạt đến từng điểm kiểm tra, vượt qua vạch đích — với ít sự đa dạng giữa các lần chơi và không có lý do để quay lại chơi lần thứ hai. Đây là một yếu tố tiêu biểu của thể loại obby, chứ không phải một trò chơi có điểm nhấn riêng.

Khoảng cách đó chính là phát hiện quan trọng. Chất lượng mã nguồn và chất lượng nội dung là hai khía cạnh hoàn toàn khác biệt, và một bản dựng có thể gần như hoàn hảo ở khía cạnh này nhưng lại thất bại ở khía cạnh kia. Một điểm số chất lượng tổng hợp duy nhất sẽ tính trung bình hai yếu tố này thành một con số vô nghĩa.

Thử nghiệm chơi

Tác nhân thử nghiệm đã chơi trò chơi chạy bằng cách sử dụng các thao tác giống như người chơi thực và đã vượt qua tất cả chín mục trong kế hoạch thử nghiệm: tạo nhân vật trên nền tảng khởi đầu, điều hướng hình học 3D qua các khe hở, chịu tác động của các mối nguy hiểm, kích hoạt các điểm kiểm tra và tự động phục hồi sau khi ngã, hoàn thành cuộc chạy và khởi động lại, tất cả đều không có lỗi thời gian chạy. Trong lần chạy cụ thể này, Skyforge Ascent đạt 100/100 điểm trong thử nghiệm.

Điểm thử nghiệm hoàn hảo chỉ chứng tỏ rằng các cơ chế hoạt động tốt và trò chơi có thể chơi được về mặt kỹ thuật từ đầu đến cuối. Điều này không nói lên gì về việc trò chơi có thực sự hấp dẫn hay thú vị khi chơi hay không — chính sự khác biệt đó là lý do tại sao góc nhìn thiết kế chỉ chấm cho trò chơi 31 điểm.

Chất lượng hình ảnh

Cuối cùng, hệ thống đánh giá đã chấm điểm phiên bản ghi lại trên khung hình kích thước điện thoại về mặt trình bày hình ảnh. Skyforge Ascent đạt 86/100: giao diện gọn gàng, thống nhất và phù hợp với phong cách đồ họa của một trò chơi platformer điển hình; hình học nền tảng dễ nhận biết; các chướng ngại vật rõ ràng; và giao diện người dùng (HUD) hiện đại, không gây phiền nhiễu. Một số hạn chế nhỏ về mặt hình ảnh khiến trò chơi chưa đạt đến mức hoàn hảo, nhưng không có gì bị hỏng và cũng không có gì khiến người chơi phải dừng cuộn màn hình.

Chỉ số theo dõi

Cùng một phiên bản ghi lại cũng thu thập các chỉ số quá trình. Trò chơi mất khoảng tám phút để biên dịch, không có lỗi công cụ nào, và quá trình biên dịch đã sử dụng các kỹ năng 3D, giao diện người dùng, chỉnh sửa kịch bản, chèn tài nguyên và âm thanh trò chơi. Các chỉ số này không ảnh hưởng trực tiếp đến điểm đánh giá, nhưng chúng cho biết cách trò chơi được phát triển và sẽ cảnh báo về một phiên bản tương lai nếu nó trở nên chậm hơn hoặc tốn kém hơn mà không mang lại lợi ích nào.

Qua năm giai đoạn, Skyforge Ascent đạt điểm khác nhau về thông số kỹ thuật trò chơi, chất lượng mã nguồn, chất lượng nội dung, thử nghiệm chơi và chất lượng hình ảnh. Bốn trong số các khía cạnh này cho thấy Build có thể biến một lời nhắc duy nhất thành một trải nghiệm Roblox hoàn chỉnh, chính xác, có thể chơi được và trình bày được. Một khía cạnh cho thấy đây không phải là trò chơi mà ai cũng muốn chơi lại lần thứ hai. Đo lường khoảng cách đó, thay vì loại bỏ nó bằng cách tính trung bình, chính là mục đích chính của đánh giá Build.

Cách đánh giá sớm đã cải thiện Build 

Kết quả đánh giá không chỉ tạo ra điểm số, mà còn cung cấp hướng dẫn cụ thể để cải tiến sản phẩm. Bằng cách kết hợp việc gỡ lỗi từng thành phần riêng lẻ với thử nghiệm toàn diện ở cấp độ hệ thống, các đợt đánh giá hàng loạt ngoại tuyến trên các bộ lời nhắc tiêu chuẩn đã trực tiếp định hình quá trình phát triển của Build. 

1. Giải quyết nhanh chóng các điểm khó khăn của người sáng tạo trong giai đoạn alpha: Trong đợt ra mắt alpha tại New Zealand, người dùng phản hồi rằng Build đôi khi tạo ra trò chơi 2D trong khi họ muốn trò chơi 3D. Khung đánh giá đã giúp đội ngũ của chúng tôi nhanh chóng cải thiện khả năng 3D của Build. Trong vòng hai tuần, chúng tôi đã nâng cao khả năng của Build trong việc hiểu ý định của người dùng khi muốn tạo trò chơi 3D — ngay cả khi họ không nêu rõ điều đó. Chúng tôi cũng tinh chỉnh khả năng chơi và độ hoàn thiện của trò chơi 3D bằng cách khắc phục các vấn đề phổ biến liên quan đến vị trí đối tượng, ánh sáng, v.v. Kể từ đó, tỷ lệ phàn nàn “không phải điều tôi muốn” đã giảm từ 18% xuống 3% trong tổng số các phàn nàn; phản ứng không hài lòng chung sau khi thử nghiệm chơi game cũng giảm 10 điểm phần trăm. Chúng tôi cũng tích lũy được nhiều kinh nghiệm khi liên tục cải tiến chính khung đánh giá này. 
2. So sánh điểm chuẩn giữa các mô hình và kiến trúc: Chúng tôi sử dụng khung đánh giá của mình để so sánh điểm chuẩn một cách nghiêm ngặt các cấu hình hệ thống Build với các bộ câu hỏi chuẩn hóa. Trước khi đưa các thay đổi vào sản xuất, các báo cáo đánh giá A/B ngoại tuyến sẽ so sánh các bản phát hành ứng cử với các tiêu chuẩn cơ sở sản xuất của chúng tôi trên cả bốn khía cạnh: 

Ví dụ, các bản so sánh ngoại tuyến này cho phép chúng tôi phân tích cách các bản nâng cấp mô hình và quyết định định tuyến của tác nhân ảnh hưởng đến từng chỉ số chất lượng:

• Hiệu suất mô hình cơ sở: Việc nâng cấp mô hình cơ sở của chúng tôi đã mang lại những cải thiện nhất quán trên mọi chỉ số — dẫn đến ít bản dựng bị lỗi hơn ngay từ lần thử đầu tiên, chất lượng hình ảnh được trau chuốt hơn và nội dung trò chơi sâu sắc hơn.
• Kiến trúc định tuyến tác nhân: Ngược lại, việc ủy thác các nhiệm vụ phụ cụ thể cho một mô hình nhẹ trong cấu hình hai tác nhân đã duy trì độ sâu và sự đa dạng của nội dung, nhưng lại gây ra sự suy giảm mạnh về khả năng chơi và độ hoàn thiện về mặt hình ảnh.

1. Theo dõi các tiêu chuẩn chất lượng trên các mô hình sáng tạo: Chúng tôi cũng sử dụng khung này để hiểu chất lượng hiện tại của bản dựng tại các thời điểm khác nhau với bộ đánh giá phù hợp nhất. Các bộ này cung cấp những bức tranh tổng quan về các nhiệm vụ sáng tạo ngày càng rộng và phức tạp.
   Bộ đầu tiên bao gồm hoàn toàn các trò chơi 2D với cơ chế tương đối đơn giản. Logic trò chơi dễ xây dựng, do đó điểm thử nghiệm chơi có xu hướng cao hơn; mặt khác, điểm nội dung vẫn thấp vì chính lý do đó.
   Khi chúng tôi chuyển trọng tâm sang các trò chơi 3D, phân phối điểm số thay đổi một cách tự nhiên: việc chơi không gặp lỗi trở nên khó khăn hơn, làm giảm điểm số thử nghiệm. Điểm số về mặt hình ảnh vẫn ổn định do thiếu sự trau chuốt về tài sản, khiến các trò chơi mang lại cảm giác như bản thử nghiệm. Điểm số về nội dung cao hơn vì các trò chơi 3D có tiềm năng sâu sắc hơn — nhưng điểm số tổng thể có xu hướng vẫn thấp vì các lời nhắc một lượt chơi chỉ cung cấp không gian hạn chế để mở rộng nội dung.

1. Phát hiện các điểm nghẽn đặc thù theo thể loại: Dữ liệu đánh giá cũng chỉ ra sự chênh lệch đáng kể về hiệu suất giữa các thể loại. Các thể loại chú trọng vào cơ chế chơi (ví dụ: RPG, game bắn súng, game đua xe) thường gặp nhiều vấn đề về khả năng chơi hơn. Các thể loại có logic tương đối đơn giản (ví dụ: game sinh tồn và game tycoon) thường đạt hiệu suất tốt hơn trong các bài kiểm tra chơi thử, khiến việc trau chuốt hình ảnh và thiết kế giao diện người dùng trở thành cột mốc tiếp theo cần giải quyết. Việc hiểu rõ sự khác biệt giữa các thể loại thúc đẩy chúng tôi mở rộng bộ đánh giá với việc lấy mẫu cân bằng hơn trên các trò chơi của Build.
2. Bài học rút ra từ thiết kế khung đánh giá: Việc lặp lại chính khung đánh giá đã dạy cho chúng tôi những bài học quan trọng về độ tin cậy của khung:

• Chỉ số hệ thống so với chỉ số thành phần: Cấu trúc mã nguồn gọn gàng hay việc sử dụng API đúng cách không đảm bảo trò chơi có thể chơi được. Chúng tôi phân biệt rõ ràng giữa tính chính xác, thiết kế và trình bày để tránh che giấu các lỗi có thể khắc phục được.
• Điểm yếu của khung đánh giá và hiệu chỉnh bởi con người: Các kiểm tra tĩnh có thể bỏ sót các lỗi gây treo trò chơi trong thời gian chạy, trong khi các bài kiểm tra chơi tự động gặp khó khăn với vật lý phức tạp. Các "trọng tài ảo" được hiệu chỉnh liên tục dựa trên các nhà phát triển trò chơi chuyên nghiệp và các nhà đánh giá cộng đồng có kinh nghiệm.
• Mở rộng sang nhiều lượt và lưu lượng truy cập thực tế: Vì các nhà sáng tạo thực tế liên tục lặp lại (thêm hệ thống, điều chỉnh độ khó, sửa lỗi), chúng tôi đang mở rộng khung đánh giá để đánh giá các chỉnh sửa nhiều lượt và phân phối lời nhắc trong thế giới thực.

Bước tiếp theo

Hiện tại, chúng tôi đang tập trung mở rộng hệ thống đánh giá sáng tạo Build theo năm hướng:

1. Phạm vi bao quát rộng hơn trên các thể loại, trải nghiệm 2D/2.5D/3D, các kịch bản nhiều người chơi và các cấp độ phức tạp
2. Hỗ trợ mạnh mẽ hơn cho các bản chỉnh sửa nhiều lượt
3. Bằng chứng thử nghiệm, ảnh chụp màn hình, video và âm thanh đáng tin cậy hơn
4. Điều chỉnh theo đánh giá của người dùng trên quy mô lớn và các trường hợp chuẩn do người sáng tạo dẫn dắt
5. Tích hợp tốt hơn giữa đánh giá ngoại tuyến, tín hiệu sản phẩm trực tuyến và kiểm thử hồi quy

Mục tiêu dài hạn của chúng tôi là xây dựng một hệ thống đánh giá minh bạch, liên tục cải tiến, đo lường Build ở mức độ mà các nhà sáng tạo quan tâm: chất lượng trải nghiệm mà họ có thể tạo ra, thử nghiệm, chia sẻ và tiếp tục phát triển. Hiện tại, các tín hiệu này được sử dụng để đánh giá các trò chơi do Build tạo ra. Theo thời gian, khi chúng tôi tiếp tục tinh chỉnh và hiệu chỉnh chúng dựa trên đánh giá của con người, chúng có thể được áp dụng cho các quy trình sáng tạo khác và giúp cung cấp một ngôn ngữ chung để hiểu chất lượng trò chơi trên toàn hệ sinh thái Roblox.

Để tìm hiểu thêm về việc đánh giá các hệ thống tự chủ cho Roblox Assistant, hãy xem bài viết “Sử dụng OpenGameEval để so sánh hiệu suất các trợ lý AI tự chủ cho Roblox Studio”.