"Harness" AI cho phát triển game: Cách biến game thành công cụ hỗ trợ lập trình viên

Trong một bài trình bày gần đây, lập trình viên game kỳ cựu Kyle Kukshtel đã chia sẻ những kỹ thuật thực tiễn để đưa AI vào quy trình phát triển game một cách nghiêm túc, chứ không chỉ dừng lại ở những bản demo hào nhoáng trên mạng xã hội. Ông cho rằng vấn đề cốt lõi không phải là AI dở với game, mà là game chưa được "làm cho dễ đọc" đối với AI. Bài viết dưới đây tóm lược những ý tưởng chính và bổ sung góc nhìn phù hợp với cộng đồng lập trình viên Việt Nam.

Vì sao AI thường "thất bại" với game?

Khi các mô hình ngôn ngữ lớn (LLM) đã làm rất tốt với các dự án web, nhiều người kỳ vọng chúng cũng sẽ tỏa sáng với game. Nhưng thực tế lại khác.

Tác giả chỉ ra rằng sự khác biệt nằm ở chỗ: với web, hầu như mọi thứ đều là code. Với game, code chỉ là một phần — còn có model, âm thanh, animation, scene, dữ liệu cấu hình và vô số thứ không thể biểu diễn trực tiếp bằng mã nguồn.

"Về mặt cấu trúc, LLM vốn dĩ rất kém trong việc đọc hiểu game. Ít nhất là ở trạng thái mặc định."

Điều này dẫn đến một kết luận quan trọng: việc giúp LLM làm việc tốt với game thực chất là một bài toán về ngữ cảnh (context), chứ không phải vấn đề cố hữu của game hay của LLM.

Hiểu về "context pollution" — ô nhiễm ngữ cảnh

Mỗi lần bạn gửi một tin nhắn cho mô hình, toàn bộ lịch sử hội thoại trước đó lại được gửi kèm. Điều này giống như trò chơi "tam sao thất bản" thời đi học: mỗi lượt, bạn phải nhắc lại toàn bộ nội dung cũ rồi mới thêm phần mới.

Minh họa quy trình phát triển với AI harness

Hệ quả là nếu ngữ cảnh chứa những "thông tin rác" từ các bước trước, mô hình sẽ liên tục bị ảnh hưởng bởi chúng. Đây là lý do "context engineering" ra đời — một thực hành mới nhằm đưa thông tin tốt nhất vào ngữ cảnh với mức độ ô nhiễm thấp nhất.

Harness là gì và tại sao game cần nó?

Harness là một tập hợp các mẫu hành động mà một AI agent được kỳ vọng thực hiện để phản hồi một loại đầu vào nhất định. Bạn có thể đã dùng một harness như Claude Code, nhưng harness có thể được mở rộng, tinh chỉnh để hỗ trợ công việc cụ thể.

Vấn đề là hầu hết các harness hiện nay đều không "nói chuyện" được với game của bạn. Game vẫn là một hộp đen, và thứ duy nhất AI thấy được là code đã viết — vốn không đủ.

Giải pháp: crack mở hộp đen và biến nhiều phần của game thành thứ AI có thể xử lý trực tiếp.

Những kỹ thuật cụ thể để game "dễ đọc" với AI

1. Tính ngẫu nhiên có seed cố định

Ngay từ đầu dự án, hãy tạo một nguồn ngẫu nhiên duy nhất có seed. Mọi lời gọi bất định trong game đều phải đi qua nguồn này. Nhờ đó, game có thể tái tạo chính xác gần như mọi trạng thái — điều kiện tiên quyết để AI có thể lặp lại quá trình kiểm thử.

2. Chụp ảnh màn hình và so sánh khác biệt

Chụp ảnh màn hình trước/sau thay đổi là cách tốt để AI hiểu điều gì đã thay đổi. Nhưng nếu chỉ đưa ảnh thô cho mô hình, nó sẽ bị "nhiễu ngữ cảnh" bởi mọi thứ khác trong ảnh.

So sánh ảnh trước và sau thay đổi

Giải pháp là dùng công cụ image diff như odiff — miễn phí, chạy trên dòng lệnh. Nó không chỉ tạo ảnh diff trực quan mà còn trả về giá trị định lượng như "giống 85%", cho phép AI dùng làm điểm mốc đánh giá ổn định qua từng lượt lặp.

3. Trạng thái tất định và lưu/tải

Câu hỏi quan trọng: bạn có thể lưu và tải một trạng thái chính xác của game dễ dàng đến mức nào?

Lập trình viên nghiệp dư thường trì hoãn việc lưu/tải đến cuối dự án — đó là sai lầm nghiêm trọng. Nếu tích hợp từ đầu, lưu/tải trở thành "siêu năng lực" phát triển với vô số lợi ích.

4. Phát triển hướng "Thing"

Thay vì xây dựng hệ thống OOP phức tạp với hàng trăm class, tác giả đề xuất một kiểu đối tượng duy nhất (có thể đặt tên là Thing). Mỗi Thing có các giá trị thuộc tính và một cờ isAlive, còn "loại" chỉ là một giá trị enum.

Cách tiếp cận này khiến AI cực kỳ dễ làm việc, vì chỉ có một nguồn chân lý duy nhất cho mô hình đối tượng. Serialize/deserialize một kiểu thì đơn giản hơn nhiều so với cả cây kế thừa.

5. Trạng thái có thể địa chỉ hóa và Command Pattern

Command Pattern cho phép ghi lại thay đổi trạng thái dưới dạng đối tượng có thể serialize. Thay vì gọi hàm trực tiếp, mọi thay đổi đi qua một lớp xử lý.

Lợi ích khổng lồ:

• Bạn có thể tái hiện bug bằng cách phát lại (playback) chuỗi lệnh từ trạng thái khởi đầu
• AI agent cũng có thể chạy lại chúng để đánh giá tác động thay đổi
• Có thể soạn lệnh trong trình soạn thảo văn bản hoặc do AI sinh ra, rồi phát lại trên bản game đang chạy — không cần biên dịch lại

6. Quản lý dữ liệu tách khỏi code

Đừng nhúng dữ liệu tĩnh vào code. Hãy để tất cả dữ liệu như Type, attackDamage, walkSpeed ở bên ngoài game, chỉ cần deserialize và gán vào đối tượng đúng.

Với dự án Cantata, nhóm của tác giả (~7 người không chuyên lập trình) đã dùng build game kèm công cụ chỉnh sửa dữ liệu tùy chỉnh gọi là Depot. Họ thay đổi dữ liệu, game deserialize và cập nhật ngay mà không cần build lại.

Công cụ Depot cho phép chỉnh sửa dữ liệu không cần biên dịch

AI agent cũng có thể được dạy dùng chính công cụ này, giống như các thành viên khác trong nhóm.

7. Kiến trúc hộp đen — tách mô phỏng khỏi engine

Thay vì để logic game hòa lẫn với UI và engine, hãy tách lõi mô phỏng ra thành một DLL/thư viện riêng. Engine chỉ gửi lệnh vào và nhận trạng thái cập nhật về.

Engine trở nên "ngốc nghếch": nó chỉ hành động theo những gì lõi mô phỏng trả về. Lợi ích cực lớn:

• Lập trình mạng đơn giản hơn nhiều — nguồn trạng thái đến từ đâu không còn quan trọng
• Có thể kiểm thử lõi mô phỏng bằng dự án C# thuần, không cần engine chạy
• Có thể chạy simulation, kiểm thử giả thuyết trực tiếp

Cách tiếp cận này từng được áp dụng cho các tựa game như Monster Train và Solium Infernum.

Đánh giá tác động và tối ưu vòng lặp

Để AI không chỉ sửa code mà còn biết thay đổi có tác động đúng không, cần đo lường định lượng. Với hiệu năng, công cụ như samply (miễn phí) có thể xuất dữ liệu profiling ra dạng văn bản — thứ AI đọc tốt hơn nhiều so với biểu đồ trực quan.

Kết luận: Game chính là harness của chính nó

Khi kết hợp tất cả kỹ thuật trên — dữ liệu tất định, kiến trúc hướng dữ liệu, tách biệt nhị phân, không cần biên dịch — một lượt agentic có thể chạy qua toàn bộ vòng lặp chỉ trong vài giây.

Điều thú vị nhất: harness lý tưởng cho game của bạn chính là game của bạn. Bất kỳ game nào cũng có khả năng làm được điều này.

Đối với lập trình viên game Việt Nam, những ý tưởng này đặc biệt đáng cân nhắc: nhiều nhóm indie trong nước đang xây dựng game với nguồn lực hạn chế, và việc thiết lập kiến trúc đúng ngay từ đầu có thể tạo ra khác biệt khổng lồ về năng suất về sau. Ngay cả khi chưa dùng AI, các nguyên tắc về tính tất định, lưu/tải sớm, và tách biệt mô phỏng vẫn là những thực hành tốt giúp mọi dự án game dễ bảo trì hơn.

"Điều quan trọng là làm cho mỗi thay đổi trở thành mức thay đổi tối thiểu cần thiết cho kết quả mong muốn, và những thay đổi đó có thể được kiểm chứng nhanh chóng."