Phát triển game bằng AI

Bắt đầu bằng một vòng lặp game nhỏ nhưng hoàn chỉnh

Mục tiêu đầu tiên hữu ích là một hoạt động đơn lẻ có điểm bắt đầu và kết thúc quan sát được: bắt đầu một vòng, di chuyển hoặc lựa chọn, gặp thử thách, đạt thắng hoặc thua rồi khởi động lại. Xác định người chơi nhìn thấy gì ở mỗi chuyển tiếp trước khi yêu cầu agent viết tệp. Màn hình tiêu đề trau chuốt không thể chứng minh vòng lặp hoạt động.

Chọn một nền tảng đích và một tập nhỏ thiết bị đầu vào. Xem các màn chơi bổ sung, mạng và nội dung thủ tục là phạm vi về sau. Điều này giữ cho nguyên mẫu thất bại có thể chẩn đoán: bạn có thể phân biệt luật va chạm hỏng với tính năng chưa hoàn thành thay vì liên tục mở rộng prompt.

Chọn quy trình, sau đó chọn engine

Với dự án 2D nguyên bản nhỏ, hãy bắt đầu bằng việc đánh giá CLI đã được Godot ghi nhận cho vòng kiểm tra-sửa-chạy. Unity là điểm bắt đầu hữu ích khi dự án hiện có hoặc đội ngũ đã phụ thuộc vào quy trình editor của nó. Khả năng bạn duy trì kết quả nên quan trọng ngang với nguyên mẫu đầu tiên.

So sánh công việc cần để tái tạo lỗi trên máy của bạn. Điểm bắt đầu tốt nhất là nơi bạn có thể giải thích cấu trúc dự án, điều kiện build và lỗi. Agent không loại bỏ trách nhiệm nâng cấp engine hay gói bên thứ ba.

Giữ quyền truy cập mô hình tách khỏi công cụ engine

Agent có hai kết nối khác nhau: dịch vụ mô hình tạo suy luận và chỉnh sửa, cùng các công cụ cục bộ kiểm tra hoặc vận hành dự án. Godot MCP và Unity MCP thuộc phía công cụ. Cài đặt chúng không chọn nhà cung cấp mô hình hay chứng minh tích hợp gateway.

Chọn kết nối mô hình trong client agent và kết nối engine trong cài đặt công cụ. Xác minh từng kết nối độc lập bằng một thao tác nhỏ. Khi đường dẫn dự án cục bộ sai, hãy sửa đường dẫn đó; đổi endpoint mô hình sẽ không làm cảnh dự kiến xuất hiện.

Làm cho brief đầu tiên có thể kiểm thử

Nêu tên các cảnh bắt buộc, hành động người chơi, chuyển tiếp trạng thái và hành vi lưu trữ. Yêu cầu triển khai nhỏ nhất đáp ứng các yêu cầu đó cùng danh sách rõ ràng các quyết định chưa giải quyết. Dùng brief minh họa bên dưới làm điểm bắt đầu và thay phạm vi bằng game bạn thực sự muốn.

Ghi brief ban đầu không đổi. Khi thêm yêu cầu, gắn nhãn đó là thay đổi phạm vi. Khi giải thích lỗi hoặc tự sửa tệp, gắn nhãn đó là can thiệp. Điều này giữ khác biệt giữa một prompt ban đầu và nhiều vòng lặp mô hình cùng công cụ có thể theo sau.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Làm việc bằng các thay đổi có thể rà soát

Sau khung ban đầu, hãy yêu cầu từng hành vi một: di chuyển, rồi va chạm, rồi chuyển tiếp cuối vòng. Rà soát tệp đã đổi và chạy cùng đường chấp nhận sau mỗi thay đổi. Giữ trạng thái dự án đang hoạt động đã biết trước khi thêm gói ngoài hoặc sửa cài đặt nhập.

Agent nên nhận lỗi liên quan, ngữ cảnh cảnh và hành vi quan sát được, không chỉ yêu cầu cố gắng hơn. Khi cùng triệu chứng tồn tại sau nhiều chỉnh sửa, dừng lại và cô lập ranh giới. Tài nguyên nhập bị thiếu và tham chiếu node sai cần cách sửa khác nhau dù cả hai đều tạo cảnh trống.

Coi tài nguyên và bản địa hóa là đầu vào sản xuất

Giữ manifest tài nguyên gồm nguồn, quyền, danh tính tác giả hoặc công cụ, sửa đổi và mục đích sử dụng. Rà soát sprite ở tỷ lệ gameplay, gồm độ trong suốt, căn khung, độ tương phản và độ khớp va chạm. Hình ảnh có vẻ hợp lý không tự động là sprite sheet dùng được.

Giữ các chuỗi hướng tới người chơi có thể định vị bằng mã định danh ổn định. Cung cấp ngữ cảnh dịch và bảo vệ các đối số định dạng. Hình ảnh, âm thanh, font và văn bản đã dịch đều cần rà soát trước khi phân phối. Ghi chi phí tạo hình ảnh độc lập với công việc lập trình bằng mô hình văn bản; cả giấy phép tài nguyên lẫn giấy phép engine đều không xác lập quyền cho mọi tệp trong dự án.

Chứng minh từng trạng thái bàn giao độc lập

Demo có thể chơi cần một người hoàn tất vòng lặp dự kiến. Bản xuất cần artifact được tạo. Bản xuất đã kiểm thử còn cần khởi chạy artifact trên nền tảng đích. Gửi Steam và phát hành là các trạng thái nền tảng về sau. Dùng các nhãn đó chính xác khi chia sẻ tiến độ.

Bảo toàn danh tính build, đầu vào kiểm thử, ảnh chụp từ gameplay thực và các lỗi còn lại. Ảnh chụp trình duyệt phải cho thấy gameplay thay đổi sau đầu vào, không chỉ màn hình tải. Tệp thực thi Windows xuất trên hệ điều hành khác vẫn cần xác minh Windows. Xem hướng dẫn Steam về yêu cầu tài khoản và lịch trình riêng.

Ví dụ Playco cho thấy gì về quy trình

Câu chuyện khách hàng ngày 3 tháng 9 năm 2026 của OpenAI mô tả Playco dùng Astra trong Playbot, một IDE kết nối với các engine game. Đội ngũ lặp trên nền tảng grey-box trước khi tạo nguyên mẫu có chủ đề. Đây là tài khoản khách hàng do nhà cung cấp công bố, không phải benchmark APIsRouter.

Bài học thực tế là hình dạng quy trình: thiết lập cơ chế gameplay, sau đó thay đổi trình bày trong khi giữ đường cơ sở chung. Tách sở thích sáng tạo khỏi sửa lỗi để bạn thấy mỗi lần lặp đạt được gì. Đọc tài khoản gốc về kết quả được báo cáo thay vì coi đó là dự báo cho game của bạn.

Kiểm tra một nguyên mẫu Godot cục bộ

Switchyard là một puzzle mạch điện ba phòng nhỏ được tạo trong một lần phát triển Codex cục bộ. Dự án nguồn gồm di chuyển nhân vật, công tắc, cửa, ô sưu tầm, hoàn tất phòng, thua và khởi động lại, cài đặt cùng tiến độ đã lưu. Kiểm tra engine tự động đã thực thi vòng gameplay và một tiến trình riêng đã mở lại file lưu. Ảnh chụp bên dưới là ảnh chụp viewport Godot thực, không phải nghệ thuật ý tưởng.

Lần chạy được ghi nhận dùng Godot 4.5.1. Danh tính mô hình và thanh toán API không quan sát được, vì vậy đây không phải benchmark hiệu năng hoặc chi phí Astra. Mã nguồn và PCK tải xuống minh họa dự án cục bộ; PCK yêu cầu Godot. Build Windows độc lập, bản xuất trình duyệt, playtest con người và phát hành Steam vẫn là công việc riêng. Ví dụ này cho thấy các artifact cụ thể cần yêu cầu agent trước khi đưa ra khẳng định bàn giao.

Chọn hướng dẫn tiếp theo theo nút thắt

Bắt đầu bằng chọn engine nếu môi trường chưa quyết định, các trang thiết lập MCP nếu không phát hiện được công cụ, hoặc hướng dẫn gỡ lỗi nếu dự án mở nhưng hoạt động sai. Dùng hướng dẫn chi phí khi sửa lặp chi phối chi tiêu; thu hẹp phạm vi có thể quan trọng hơn đổi mô hình.

Các hướng dẫn này cung cấp quy trình có nguồn và ví dụ minh họa, không phải xếp hạng engine đã đo. Thử nghiệm Astra được liên kết giải thích bằng chứng cần cho ca cụ thể đó. Với dự án của bạn, hãy chọn bước tiếp theo giải quyết một blocker cụ thể và giữ kết quả trước khi mở rộng game.

Câu hỏi thường gặp