Astra + Blender + Godot: Dựng Ship 3D Không MCP Và Biến Failure Log Thành “Skill”

Một post rất mới trên r/aigamedev đáng chú ý không phải vì tuyên bố “AI làm game thay con người”, mà vì nó cho thấy một cách làm thực tế hơn: để coding agent thử, thất bại, ghi lại thất bại, rồi dùng chính lịch sử đó làm bộ nhớ quy trình cho lần tiếp theo.

Creator LostRequirement4828 đang làm một prototype space-survivor trong Godot. Người chơi ở bên trong tàu, quan sát không gian chủ yếu qua camera và cửa sổ, điều khiển tàu bằng hệ thống nút bấm. Bài đăng hiện mới ở giai đoạn rất sớm, nhưng đi kèm một gallery cho thấy nội thất tàu và nhiều object 3D đã được dựng thành một scene khá hoàn chỉnh.

Nguồn gốc: Reddit – “Astra doing magic for a space game I'm working on it”.

Điểm đáng chú ý: asset được làm trong Blender bởi Astra rồi nhập sang Godot

Khi được hỏi trực tiếp về asset pipeline, tác giả nói toàn bộ phần asset đang thấy được làm trong Blender bởi Astra, sau đó con tàu được import sang Godot. Ở một bình luận khác, tác giả bổ sung rằng workflow này không dùng Blender MCP và không bắt đầu từ ảnh tham chiếu; họ cũng ước tính đã dùng khoảng 80% quota của một gói theo tuần cho quá trình làm việc đó.

Đây là chi tiết quan trọng vì nó tách case này khỏi kiểu “image-to-3D” quen thuộc. Tác giả không mô tả một pipeline tạo concept 2D rồi đưa vào model sinh mesh. Thay vào đó, agent được dùng trực tiếp trong quá trình dựng asset và scene, còn Godot là nơi chạy gameplay.

Cần nhấn mạnh rằng post chưa công khai topology, polycount, UV quality, collision setup, import settings hay số vòng sửa cụ thể của từng asset. Vì vậy, chưa có cơ sở để kết luận chất lượng production-ready chỉ từ hình showcase. Điều có thể xác nhận là creator đã đưa asset qua Blender → Godot và hiện đang chạy thành một prototype tương tác.

150 FPS ở 4K là dữ kiện của máy tác giả, không phải benchmark chung

Tác giả báo prototype hiện chạy trung bình khoảng 150 FPS ở 4K, không upscaling, trên Radeon RX 7900 XT. Đây là một tín hiệu performance thú vị, nhưng nên đọc đúng ngữ cảnh: project còn rất sớm, object sẽ tiếp tục được nâng cấp hình ảnh và bài đăng chưa cung cấp CPU, frame-time breakdown, số draw call, triangle count, VRAM usage hay scene complexity.

Vì thế, con số 150 FPS chỉ nên coi là kết quả tác giả quan sát trên cấu hình và scene hiện tại. Nó chưa chứng minh rằng cùng pipeline sẽ giữ mức hiệu năng đó khi thêm AI, physics, lighting phức tạp, animation, VFX, inventory hoặc một world lớn hơn.

Phần giá trị nhất lại nằm trong comment: bắt agent ghi lại mọi lần làm sai

Khi một người hỏi workflow cụ thể, creator trả lời rằng họ buộc Astra phải ghi lại từng task thất bại để agent không lặp lại cùng một hướng sai. Theo mô tả của tác giả, nếu không làm vậy agent dễ “đi vòng tròn”; các ghi chú sau đó có thể được tổ chức thành một dạng skill để workflow cải thiện dần qua mỗi lần thử.

Tác giả nói hiện tại phần này vẫn chủ yếu là notes trong folder, nhưng có ý định chuyển nó thành skill. Đây là một chi tiết nhỏ nhưng rất sát với vấn đề thật của AI-assisted game development: phần khó không chỉ là tạo ra output đầu tiên, mà là ngăn agent quên những quyết định và lỗi đã được xác nhận trước đó.

Trong game art pipeline, một lỗi bị lặp lại có thể rất tốn kém. Agent có thể liên tục tạo sai scale, đổi naming convention, export sai orientation, phá material assignment hoặc sửa một asset theo cách làm mất tính nhất quán với phần còn lại. Nếu mỗi session lại bắt đầu gần như từ đầu, số lần retry tăng nhanh dù model có mạnh hơn.

Failure log có thể trở thành “production memory” như thế nào?

Đây là phần phân tích của NextGZ, không phải cấu trúc mà creator đã công bố. Từ cách tác giả mô tả, có thể rút ra một mô hình khá hữu ích cho artist hoặc indie dev đang dùng agent với Blender và Godot.

Thay vì chỉ lưu prompt thành công, nên lưu cả ràng buộc đã kiểm chứng: scale nào được chấp nhận, trục forward/up nào dùng khi export, naming nào Godot đang đọc, material nào không được đổi, object nào cần origin ở đâu, collision nào phải tách riêng, và đặc biệt là những thao tác đã thử nhưng gây lỗi.

Mỗi failure entry nên gắn với một dấu hiệu kiểm tra được. Ví dụ, thay vì ghi “đừng export sai”, hãy ghi điều kiện: asset nhập vào phải đúng tỷ lệ so với player reference, transform phải sạch theo convention của project, material slot count không đổi, scene tree không phát sinh node thừa. Khi agent có tiêu chí pass/fail cụ thể, ghi chú mới trở thành công cụ kiểm soát sản xuất thay vì một cuốn nhật ký dài.

Một skill tốt cũng không nên chỉ chứa hướng dẫn “làm thế nào”. Nó cần chứa những điều cấm làm lại. Đây chính là giá trị của failure log mà case này gợi ra.

Blender → Godot: nơi nên đặt quality gate

Nếu áp dụng workflow tương tự, điểm kiểm tra tốt nhất không phải chỉ ở cuối pipeline. Có ít nhất ba lớp cần được xác nhận riêng.

Ở Blender, cần kiểm tra silhouette, scale, origin, hierarchy, mesh cleanliness, UV/material và naming. Sau export, cần xác nhận file trung gian giữ đúng transform và material mapping. Khi vào Godot, tiếp tục kiểm tra import result, collision, pivot, lighting response, camera readability và runtime cost.

Điểm quan trọng là không để agent tự đánh giá bằng câu “trông ổn”. Một visual workflow đáng tin cậy cần ảnh chụp viewport, thông số asset hoặc test scene cố định để so trước/sau. Creator của post cũng thừa nhận đã gặp nhiều visual bug trước khi đi đến kết quả hiện tại. Điều đó cho thấy output đẹp trong gallery là kết quả của iteration, không phải một lần prompt duy nhất.

Không dùng MCP không có nghĩa là pipeline tự động hơn

Một chi tiết dễ bị đọc quá đà là câu “no MCP”. Nó chỉ cho biết creator không dùng Blender MCP trong workflow được mô tả. Bài đăng chưa công khai Astra điều khiển Blender chính xác qua cơ chế nào, mức độ tự động hóa UI ra sao, hay những bước nào vẫn cần người dùng can thiệp.

Do đó, không nên biến case này thành kết luận rằng MCP “không cần thiết” hoặc agent có thể tự vận hành toàn bộ DCC app. Giá trị thực tế hơn là: creator đã tìm ra một loop làm việc đủ dùng cho dự án của mình, rồi chủ động bổ sung memory về thất bại để giảm retry.

Bài học đáng lấy cho indie dev dùng AI làm 3D

Case này cho thấy một hướng triển khai đáng thử: cho agent tham gia sâu vào asset production, nhưng buộc mọi lần thử phải để lại dấu vết. Prompt không còn là đơn vị kiến thức chính; history của quyết định, lỗi và tiêu chí kiểm tra mới là thứ giúp pipeline ổn định dần.

Với dự án nhỏ, cách này có thể đơn giản chỉ là một folder gồm conventions, failed attempts và checklist import. Khi dự án lớn hơn, nó có thể phát triển thành skill hoặc harness chuyên cho Blender/Godot. Điều quan trọng là mỗi rule phải gắn với một lỗi từng xảy ra hoặc một yêu cầu production có thể kiểm tra, thay vì tích lũy hàng trăm dòng “best practice” chung chung.

Prototype trong bài vẫn còn rất sớm: gameplay hiện mới quanh việc lái tàu, tương tác với cửa và một số object, trong khi tác giả còn nhiều ý tưởng cho exploration, story và ship upgrades. Vì vậy, đây chưa phải bằng chứng về một game hoàn chỉnh. Nhưng nó là một ví dụ tốt về việc AI-assisted game art bắt đầu chuyển từ “tạo asset cho nhanh” sang câu hỏi khó hơn: làm thế nào để agent nhớ được những gì production pipeline đã học.

Nguồn và phạm vi xác minh

Các thông tin về Godot, Blender, việc không dùng MCP/ảnh đầu vào, mức sử dụng quota, visual bugs và con số 150 FPS ở 4K đều là dữ kiện creator tự công bố trong post và phần bình luận. NextGZ chưa có source độc lập để benchmark lại hiệu năng hay kiểm tra chất lượng file 3D gốc, vì vậy các chi tiết này được giữ nguyên dưới dạng claim của tác giả, không nâng thành kết luận phổ quát.