Đội quân 6 AI tại Vibe Gaming: Tự lập trình, chơi thử và sửa lỗi game

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

18/08/2026 15:33:00 Nguồn: QbitAI

Code chạy được chưa chắc đã là game chơi được

Yun Zhong đưa tin từ trụ sở QbitAI

QbitAI | Tài khoản chính thức QbitAI

Chỉ cần ra lệnh cho AI: "Hãy tạo một trò chơi xe tăng", mã nguồn sẽ nhanh chóng được thực thi.

Xe tăng địch xuất hiện trên màn hình, nòng pháo khóa mục tiêu vào người chơi, trận chiến tưởng chừng như đã bắt đầu. Thế nhưng, khi áp sát kẻ địch, thay vì bắn đạn, chiếc xe tăng lại vung nòng pháo lên để tấn công cận chiến.

Thoạt nhìn, đây giống như một lỗi "ngáo" điển hình của AI. Tuy nhiên, nếu tiếp tục chơi, bạn sẽ thấy các thao tác di chuyển, va chạm, tấn công và tính toán sát thương đều hoạt động bình thường.

Nó đi chệch khỏi thiết kế thông thường, nhưng lại vô tình tạo ra một lối chơi mới đầy thú vị.

△ Xe tăng vung nòng pháo để tấn công cận chiến

Đây cũng là vấn đề dễ bị bỏ qua nhất khi AI tạo game: code chạy được chỉ là bước đầu tiên. Khó khăn thực sự nằm ở việc biến trò chơi thành một hệ thống có khả năng tương tác liên tục.

Code chạy được, tại sao game vẫn không thể chơi?

Trong năm qua, các mô hình ngôn ngữ lớn (LLM) đã tạo ra vô số trò chơi như Rắn săn mồi, đi cảnh (platformer) và bắn súng.

Trang web có thể mở, nhân vật có thể di chuyển, nhưng không có nghĩa là người chơi có thể hoàn thành một ván game.

Nền tảng có thể cao hơn giới hạn nhảy, kẻ địch có hoạt ảnh nhưng không có vùng va chạm tấn công, hoặc tần suất xuất hiện của chướng ngại vật có thể chồng chất tạo thành một "con đường tử thần" không thể vượt qua.

Việc chỉnh sửa cũng có thể gây ra phản ứng dây chuyền.

Người dùng chỉ muốn tăng độ cao nhảy của nhân vật, nhưng hệ thống lại vô tình thay đổi trọng lực và quỹ đạo chuyển động của các vật thể khác; sau khi code được hoàn thiện một cách miễn cưỡng, tài nguyên hình ảnh lại có thể bị thiếu hoặc không đồng nhất về phong cách.

Mỗi phần nhỏ nhìn thì có vẻ đúng, nhưng khi kết hợp lại thì không thể chơi được, đây chính là "hố đen khả năng chơi" (playability black hole) trong quá trình tạo game bằng AI.

Nó khó xử lý hơn nhiều so với lỗi biên dịch. Lỗi code thường có thể xác định được tệp và dòng cụ thể, nhưng việc game "không hay" có thể liên quan đồng thời đến thông số, bản đồ, phản hồi và thao tác của người chơi.

Chỉ khi đưa tất cả các yếu tố này trở lại cùng một quy trình vận hành để kiểm tra, hệ thống mới biết chính xác vấn đề nằm ở đâu.

△ Từ kết quả tạo code cơ bản đến phiên bản có thể chơi được theo chủ đề

△ Quy trình khép kín sáng tạo và xác thực với 6 Agent của Spellcaster

Spellcaster không tạo ra một đoạn mã đơn lẻ

Cách tiếp cận của Spellcaster là trước tiên sắp xếp mô tả của người dùng thành các quy tắc trò chơi, năng lực nhân vật, mục tiêu màn chơi, điều kiện thắng thua, hành vi kẻ địch và các thông số quan trọng, sau đó giao cho nhiều Agent chuyên biệt phối hợp xử lý.

Quy trình này không theo đuổi việc tạo xong là kết thúc, mà hình thành một vòng lặp "Tạo - Vận hành - Kiểm tra - Sửa lỗi".

Sau khi nhận kết quả, người dùng vẫn có thể tiếp tục đối thoại: điều chỉnh tốc độ nhân vật, thêm kẻ địch, sửa đổi màn chơi hoặc thay đổi phong cách hình ảnh.

Hệ thống sẽ xử lý phần tương ứng dựa trên ý định sửa đổi, không cần phải tạo lại từ đầu mỗi lần.

Từ một câu lệnh đến bản mẫu có thể chơi được

Toàn bộ quá trình sáng tạo có thể tóm gọn trong bốn bước: biến ý tưởng thành trò chơi có thể chạy được, lặp lại lối chơi và thông số thông qua đối thoại, kết hợp kết quả vận hành để sửa lỗi, và cuối cùng là khớp tài nguyên và hoàn thiện phần nhìn.

Nhập lệnh "Tạo một game bắn súng đạn mạc (bullet hell) với bối cảnh bầu trời đầy sao", khoảng 15 phút sau bạn sẽ nhận được một bản mẫu có thể chơi thử.

Hiện tại, các thể loại phổ biến như đi cảnh, thủ thành (tower defense), chạy vô tận (parkour), roguelike hầm ngục và bắn súng đạn mạc đều có thể được tạo và chỉnh sửa thông qua quy trình này.

△ Mười hai bản mẫu trò chơi được hiển thị trên cùng một màn hình

Quy trình này cũng thay đổi cách sử dụng các bản mẫu (prototype).

Các nhà phát triển độc lập có thể xác thực xem một lối chơi có đáng để đầu tư tiếp hay không, người sáng tạo nội dung có thể biến các câu chuyện tương tác hoặc meme mạng thành phiên bản có thể chơi được, còn người dùng phổ thông không cần phải nắm vững lập trình hay công cụ làm game.

Khi phiên bản đầu tiên không đúng như kỳ vọng, bạn có thể tiếp tục yêu cầu hệ thống điều chỉnh quy tắc, độ khó và hình ảnh, thay vì phải bắt đầu lại từ một đoạn code xa lạ.

Quay lại ví dụ ở đầu bài viết, trong một quy trình chỉ tập trung vào code, nó rất dễ bị coi là lỗi và bị xóa bỏ; nhưng sau khi xác thực khả năng chơi, nó có thể được nhận diện là một lộ trình chơi logic và tự nhất quán.