Dùng LLM chuyển game cũ sang Godot: nhanh ở đâu, cần kiểm tra gì?

Cùng một khung cửa cung điện: bên trái là bản Amiga 1993 tỉ lệ 4:3, bên phải là bản Godot 2026 màn hình rộng. Ảnh: Rabah Shihab / babyloniantwins.com.

Đọc hiểu mã nguồn cũ có thể chiếm một phần đáng kể công sức khi chuyển game sang nền tảng mới. Người tiếp nhận phải xác định dữ liệu được lưu thế nào, các đoạn mã phụ thuộc vào nhau ra sao và những hành vi nào cần giữ nguyên. Việc mã chạy được chưa chắc đã trả lời hết những câu hỏi đó.

Thử nghiệm của Rabah Shihab với Babylonian Twins là một ví dụ đáng xem xét. Để đánh giá vai trò của mô hình ngôn ngữ lớn (LLM), cụ thể ở đây là Claude Fable 5, cần tách thời gian tạo bản chạy được khỏi công việc kiểm tra và hoàn thiện bản chuyển đổi.

Câu chuyện thực tế

Theo Rabah Shihab, tác giả Babylonian Twins, dự án gồm ba bước: chuyển bản C++ năm 2010 sang Godot, dựng lại bản Amiga năm 1993 từ hợp ngữ 68000 trong Godot, rồi tích hợp hai bản. Bước chuyển C++ có bản chạy được trong một buổi tối. Bước tích hợp cũng được thực hiện trong một buổi tối riêng. Những mốc này không đại diện cho toàn bộ thời gian kiểm tra và hoàn thiện dự án.

AI được dùng cùng công cụ biên dịch, chạy thử và đối chiếu kết quả. Khi dựng lại chương trình Amiga, khoảng 108 byte vẫn còn lệch. Theo giải thích của mô hình, đó có thể là trạng thái biến được lưu sau khi game đã chạy. Tuy nhiên, cuối bài, Shihab thừa nhận chưa tự kiểm chứng giải thích này. Bản chuyển đổi cũng có lỗi: một điều kiện khoảng cách bị bỏ sót khiến lính đánh trúng nhân vật ở tầng khác.

Chính lỗi nói trên, nhìn trên bản đồ màn 2: đòn đánh của lính canh với xuống xuyên qua đá đặc, trúng nhân vật ở tầng bên dưới. Ảnh: Rabah Shihab / babyloniantwins.com.

Nguồn: Bài viết của Rabah Shihab, ngày 1/9/2026.

Có mã nguồn vẫn phải khôi phục cách game vận hành

Dự án kết hợp đọc hiểu, chuyển đổi mã nguồn và suy ngược các định dạng dữ liệu. Có mã hợp ngữ giúp lần theo cách chương trình hoạt động, nhưng không có nghĩa là ý nghĩa của dữ liệu và các quy ước thiết kế đã được ghi lại đầy đủ.

Ví dụ, một con số trong dữ liệu màn chơi có thể chỉ hình ảnh, loại địa hình hoặc trạng thái của một vật thể. Muốn biết nó có nghĩa gì, phải tìm đoạn mã đọc và xử lý con số đó. LLM có thể hỗ trợ lần theo các chỗ sử dụng, đề xuất cách diễn giải và viết công cụ trích xuất dữ liệu. Mỗi diễn giải vẫn cần được kiểm tra bằng đầu ra cụ thể.

Tập lệnh cố định không khiến hợp ngữ trở thành bài toán dễ hay bảo đảm mô hình đọc đúng. Hiểu một lệnh riêng lẻ khác với hiểu tác động của nó trong toàn bộ chương trình. Địa chỉ bộ nhớ, trạng thái phần cứng và thứ tự thực thi đều có thể làm thay đổi kết quả.

Kiểm tra đúng thứ cần giữ lại

Một bản chuyển đổi có thể tải được màn chơi và cho nhân vật di chuyển nhưng vẫn thực hiện sai luật chơi. Vì vậy, có thể chia việc kiểm tra theo từng loại kết quả:

• Dữ liệu: Màn chơi, vị trí vật thể và thuộc tính địa hình có được chuyển đổi đủ và đúng không?
• Hành vi: Cùng một chuỗi hành động, nhân vật có nhảy, va chạm, nhận sát thương và đi qua các điểm kiểm tra đúng theo bản gốc không?
• Trải nghiệm: Độ trễ điều khiển, nhịp chuyển động và phản hồi có thay đổi khi chơi thực tế không?

Các nhóm kiểm tra này bổ sung cho nhau; kết quả đúng ở một nhóm chưa bảo đảm các nhóm còn lại đúng. Hình ảnh khớp không có nghĩa là va chạm được xử lý đúng, và điều kiện thắng thua vẫn có thể bị tính sai.

Trong thử nghiệm của Shihab, đối chiếu mã nhị phân được dùng ở bước dựng lại chương trình Amiga từ mã nguồn cũ. Phép đối chiếu này giúp kiểm tra bước khôi phục đó; bản viết lại trong Godot vẫn cần được kiểm tra riêng về dữ liệu và hành vi.

Khi phát hiện sai lệch trong bản chuyển đổi, cần ghi lại thành tình huống kiểm thử có thể tái hiện: nhân vật ở đâu, người chơi bấm gì, kết quả thực tế và kết quả mong đợi là gì. Những mô tả như “chơi chưa giống” hữu ích để phát hiện vấn đề, nhưng chưa đủ để xác định đoạn mã cần sửa.

Studio có thể thử nghiệm ở phạm vi nhỏ

Từ trường hợp này, có thể đề xuất một cách thử cho studio, nhưng một dự án cá nhân chưa đủ dữ liệu để suy ra mọi nhóm đều có thể giảm chi phí chuyển đổi theo cùng tỷ lệ. Khối lượng công việc còn phụ thuộc vào chất lượng mã nguồn và thiết kế game gốc.

Một cách thử hợp lý là chọn một màn chơi có đủ di chuyển, va chạm và tương tác. Sau đó cho LLM hỗ trợ chuyển phần đó, rồi ghi riêng thời gian đọc mã, chuyển đổi, kiểm tra và sửa lỗi. Đồng thời lập danh sách những hành vi chưa xác nhận được và tiêu chí để đánh giá phần chơi đã đạt yêu cầu.

Kết quả thử nghiệm sẽ giúp trả lời câu hỏi: với bộ mã nguồn này, nhóm mất bao lâu để tạo ra một phần chơi đạt các tiêu chí đã đặt ra? Nếu thời gian viết mã giảm nhưng công sửa lỗi tăng, cần so sánh tổng công sức ở cùng mức chất lượng trước khi kết luận quy trình hiệu quả hơn. Nếu phần chơi đạt yêu cầu với ít công sức hơn và các lỗi còn lại đã được khoanh vùng, nhóm có cơ sở để mở rộng sang những màn tiếp theo.