Xin chào. Gần đây tôi đã tự mình làm một game di động tên là “Sumbi”. Đây là một roguelike màn hình dọc lấy cảm hứng từ hoạt động lặn biển của các haenyeo ở Jeju. Người chơi lặn xuống biển chỉ với một hơi thở để thu hoạch hải sản, rồi phải quyết định nên tham thêm hay quay lên ngay.
Tôi bắt đầu thiết kế vào ngày 2/7, đưa bản build đầu tiên lên Google Play vào ngày 9/7, sau đó liên tục sửa những điểm thấy chưa ổn trong lúc chơi, và đến ngày 19/7 đã tải bản build v1.1 lên production.
Điều tôi tò mò ngay từ đầu không chỉ đơn giản là “AI viết code nhanh đến đâu”. Nếu giao các vai trò khác nhau cho nhiều mô hình AI và vận hành chúng như một đội phát triển, liệu có thể làm được một game đủ để phát hành thực tế đến mức nào? Tôi muốn thử nghiệm điều đó.
Đây là game như thế nào
“Sumbi” lấy tên từ “sumbisori”, tiếng thở như tiếng huýt sáo mà haenyeo phát ra khi kết thúc buổi lặn và nổi lên mặt nước.
Mỗi ván kéo dài khoảng 10–30 giây. Bạn điều khiển haenyeo bằng một tay để lặn sâu hơn hoặc thu hoạch hải sản xung quanh. Chỉ khi chạm mặt nước an toàn, bạn mới có thể mang toàn bộ đồ đã thu hoạch về, nên bạn liên tục phải cân nhắc giữa việc tham thêm một chút hay quay lên ngay. Khi nổi lên, bạn quyết toán số thu hoạch, nâng dung tích phổi, chân vịt, túi lưới, khả năng quan sát, rồi lại lặn tiếp.
Tôi đã đưa vào hệ thống draft roguelike chọn một trong ba năng lực ở mỗi ván, bộ sưu tập 60 loài hải sản, trang bị và cây phát triển, thăng hạng haenyeo, cùng “sumbgol” kéo dài đến độ sâu 100m. Điều khiển được giữ đơn giản, nhưng càng lặp lại các lần lặn, kỷ lục và build mà người chơi nhắm tới sẽ càng khác nhau.
Tôi không dùng AI như một lập trình viên vạn năng duy nhất
Nếu một mô hình đảm nhiệm tất cả từ thiết kế, triển khai đến tự kiểm tra, nó rất dễ coi chính các giả định của mình là đáp án đúng. Vì vậy tôi chia vai trò như sau.
- Fable 5: thiết kế cấu trúc game và đặc tả tính năng, mục tiêu cân bằng kinh tế, điều kiện hoàn thành
- Opus 4.8: triển khai Flutter·Flame, viết test, debug
- Fable 5: đối chiếu lại đặc tả ban đầu với kết quả triển khai để kiểm tra thiếu sót và hồi quy
- Codex GPT-5.5: review độc lập code và các thay đổi, chỉ ra edge case
Quy trình làm việc nhìn chung là thiết kế → triển khai → người thiết kế ban đầu xác minh lại → review code độc lập → test tự động và chơi thử thực tế.
Sau khi làm thử, tôi thấy việc xác định trước các điều kiện hoàn thành có thể kiểm chứng còn quan trọng hơn viết prompt cho hay. Thay vì “hãy làm cho cảm giác phát triển tốt hơn”, tôi định lượng bằng các con số như số lần mua trong 10 phút đầu, thời gian đến lần thăng hạng đầu tiên, liệu ở bất kỳ giai đoạn phát triển nào có xuất hiện khoảng thời gian dài không mua được gì hay không. Sau đó tôi kiểm tra bằng bộ mô phỏng kinh tế và test.
Hiện có 627 test tự động và tất cả đều pass. Phân tích tĩnh của Flutter cũng pass không lỗi trên phạm vi code ứng dụng, test và công cụ.
Những trường hợp AI sai một cách có vẻ hợp lý
Thiết kế đầu tiên không lập tức trở thành một game thú vị.
Ở phiên bản ban đầu, mỗi ván chỉ có 5–9 đối tượng có thể khai thác. Là game thu hoạch mà biển trông lại trống trải. Sau khi tự chơi thử, tôi bỏ cấu trúc này. Tôi đổi để càng phát triển, field càng phong phú, và tại những chỗ đã khai thác, hải sản sẽ mọc lại. Với một số build phát triển nhất định, có thể khai thác khoảng 40 món trong một ván.
Cây phát triển cũng tương tự. Có tới 290 node, nhưng trải nghiệm chơi thực tế gần như chỉ đi theo một đường thẳng. AI đã đáp ứng yêu cầu “290 node”, nhưng chưa tạo ra niềm vui của việc lựa chọn. Cuối cùng tôi phải chia lại thành ba tuyến chuyên biệt và cấu trúc node vĩnh viễn.
AI tạo ra nhiều code rất nhanh, nhưng không đảm bảo được cả độ vui và thứ tự ưu tiên. Việc trực tiếp chơi và nói thẳng “cái này không vui”, “nhiều tính năng nhưng không thấy mục tiêu tiếp theo” vẫn là phần việc của con người.
Tôi cũng tự xây pipeline cho hình ảnh và âm thanh
Các asset hình ảnh chính như nhân vật haenyeo, hải sản, trang bị, icon thẻ được tạo bằng GPT Image Generation API. Tôi không dùng nguyên sheet đã sinh ra, mà đưa vào pipeline chỉnh sửa gồm loại bỏ chroma key, căn chỉnh frame, thống nhất kích thước, lượng tử hóa pixel rồi mới kiểm tra. Phần lớn hậu cảnh, bong bóng khí, tia sáng được vẽ bằng code.
Về âm thanh, thay vì gom asset bên ngoài, tôi tổng hợp WAV bằng code Dart. Tiếng sumbi vang lên khi kết thúc lượt lặn được xác định là âm thanh cốt lõi, nơi tên game và phần kết của một ván gặp nhau.
Suy nghĩ thay đổi sau khi làm xong
Người ta thường nói “AI làm tốt nếu mình sai bảo tốt”. Lần này, điều tôi học được nhiều hơn là “phải có cấu trúc để bắt lỗi khi nó sai”.
Tôi tách người thiết kế, người triển khai và người kiểm duyệt, rồi để mô hình khác soi kế hoạch và code một cách quyết liệt. Phán định cuối cùng được giao cho số liệu, test và chơi thử thực tế. Cách này ổn định hơn nhiều so với việc tiếp tục một cuộc trò chuyện dài với một mô hình và giao hết mọi thứ cho nó.
Ngay cả khi AI nhanh hơn, nút thắt của phát triển một người vẫn không biến mất. Thay vào đó, vị trí nút thắt chuyển từ coding sang phán đoán. Việc quyết định giữ gì, bỏ gì, và vì sao hiện tại chưa vui là phần tốn thời gian nhất.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
Vì đây vẫn là game tôi làm một mình nên còn nhiều điểm thiếu sót. Tôi muốn nghe ý kiến xem game có không vui không, menu phát triển có quá phức tạp không. Các câu hỏi về cách phát triển hoặc phân chia vai trò giữa các mô hình cũng xin cứ thoải mái để lại.
Chưa có bình luận nào.