AI, decompilation và tương lai của những bản mashup game

[00:00] Chào mừng đến với buổi standup. Hôm nay là một tập đặc biệt vì chúng ta có TJ, một quản lý huyền thoại, cùng Casey Miratory, lập trình viên game huyền thoại và cũng rất “rác”. Vì vậy, chúng ta sẽ nói về tranh luận gần đây xoay quanh việc decompile game và chơi chúng.

[00:25] “Are We Ready Player 1?” thực ra là câu hỏi mà tất cả chúng ta có thể tự hỏi, bởi giờ đây bạn có Super Mario và Elden Ring, Halo bắn vào Animal Crossing, mọi thứ được trộn lẫn với mọi thứ. Đây đúng là tương lai mà chúng ta từng mơ ước khi còn nhỏ.

[00:41] Tuy nhiên, nhiều người đang phản đối. Có podcast nói những bản decomp này rất tệ; người khác cho rằng chúng không tốt, rằng họ có chính sách anti-AI, hoặc đây chỉ là video giả. Một số người nói chúng được thực hiện theo cách khiến không ai thực sự có thể tận hưởng chúng.

[01:01] Vì thế, chúng ta sẽ nói về cuộc cách mạng decompilation và recompilation, việc có nên đọc mã nguồn hay không, liệu chính sách không dùng AI có phải là một chính sách tốt, và cuối cùng là những game nào chúng ta muốn kết hợp.

Từ emulator đến mashup game

[01:24] Giờ đây, game nào cũng được trộn với game khác và tốc độ diễn ra rất nhanh. Trước kia, việc tạo emulator cần nhiều năm, một khoảng thời gian dài và cả một nhóm người. Sau đó, họ còn phải decompile game rồi tái tạo nó theo một dạng non-clean-room để có thể chơi Twilight Princess hoặc bất kỳ game nào khác, rồi mod chúng.

[01:47] Khả năng mod game là một phần rất lớn của quá trình này: người chơi có thể biến game thành đúng thứ mình muốn. Việc đưa Halo vào Animal Crossing từng gần như bất khả thi. Các game cũng thường chạy trên phần cứng khác nhau; bạn không thể đơn giản chạy Twilight Princess trên PC vì game chưa được tạo ra cho việc đó, đồng thời chúng ta không có source code hoặc compiler để chuyển nó sang một nền tảng như Linux.

[02:32] Thành thật mà nói, tôi nghĩ đây là điều tuyệt vời nhất. Khi còn nhỏ, chúng ta luôn muốn trộn các vũ trụ khác nhau như Street Fighter và Mortal Kombat, rồi tự hỏi hai nhóm nhân vật đó sẽ chiến đấu thế nào. Khi thấy những bản demo này, suy nghĩ đầu tiên của tôi là mọi thứ từng muốn làm khi còn bé nay đang trở thành hiện thực.

[02:55] Nhưng khi xem một số demo, tôi nghĩ chúng chỉ thú vị khoảng năm phút. Bạn thấy các nhân vật xuất hiện trong một vũ trụ mới, nhưng gameplay thì khá bình thường. Xem ai đó chơi năm phút là đủ hiểu ý tưởng, sau đó bạn chuyển sang tự hỏi còn có thể trộn những gì khác.

[03:11] AI chắc chắn sẽ ngày càng mạnh hơn, nhưng hiệu ứng mới lạ biến mất rất nhanh. Dù vậy, khả năng hiện tại vẫn rất ấn tượng. Trước đây, decompilation có thể mất nhiều năm; người ta phải thay đổi từng dòng code, kiểm tra xem output có khớp với bản compiled hay không rồi mới chuyển sang dòng tiếp theo.

[04:16] Tôi không nghĩ điều này sẽ tạo ra tác động thực sự lên ngành game, ít nhất là ở thời điểm hiện tại. Nó giống AI hiện nay: mỗi khi có một model mới, mọi người đều tạo ra một game 3D rồi nói “thật tuyệt”, nhưng không ai thực sự chơi. Nó giống một demo thú vị hơn là thứ gì đó lớn hơn.

Hai kiểu kết hợp game

[06:57] Có vẻ đang tồn tại một vài cách khác nhau để trộn game. Cách đầu tiên là chạy đồng thời cả hai game, chẳng hạn đưa Spider-Man vào Batman: Arkham City, rồi truyền dữ liệu từ physics engine này sang engine kia để Spider-Man đu dây trong Arkham City.

[07:30] Physics engine, chiến đấu và animation hiện vẫn khá phức tạp. Vì vậy, nhân vật có thể đấm vào không khí còn kẻ địch thì lộn vòng. Cách này thường không thú vị để chơi, nhưng trông buồn cười và phù hợp với demo.

[07:52] Cách thứ hai đáng chú ý hơn là decompile hoàn chỉnh một phần hệ thống rồi đưa nó vào game dưới dạng mod, hoặc chèn trực tiếp vào vòng lặp thông thường của game. Ví dụ, có người đưa Skate vào Call of Duty bằng cách tích hợp các hệ thống của Skate như code thực sự, thay vì chạy hai game đồng thời.

[08:49] Cách này có thể tạo ảnh hưởng lớn hơn. Bạn có thể lấy hệ thống climbing tuyệt vời của một game, hoặc một cơ chế combat hay, rồi đưa gần như nguyên bản vào game của mình. Điều đó có thể hữu ích cho cả người làm game lẫn người chỉ tạo demo.

Decompilation trong studio game

[09:57] Liệu các studio game có thường decompile game khác để nghiên cứu không? Có thể một số studio nhìn vào một cơ chế như clamber hoặc climbing rồi tự hỏi làm thế nào để triển khai một phiên bản tương tự. Nhưng mức độ mà các studio phân tích sản phẩm của nhau là một câu hỏi về dữ liệu mà tôi không chắc trả lời được.

[10:39] Theo những gì tôi từng thấy, gameplay mechanics trong game thường không đủ phức tạp đến mức không thể tự đọc ra cách triển khai. Nếu bạn cho tôi xem một game, tôi có thể nói mình sẽ làm cơ chế đó như thế nào.

[10:57] Rendering đôi khi được phân tích kỹ hơn vì có thể xem trực tiếp các lệnh GPU, lần lượt kiểm tra chúng và quan sát kết quả tạo ra. Bạn có thể xem các render pass, dữ liệu được lưu trong từng buffer và cách hình ảnh được tạo ra mà không cần AI.

[12:12] Decompilation thường xuất hiện nhiều hơn trong việc bảo tồn game retro. Mọi người muốn tạo source base cho những game như Super Mario 64 để bảo tồn, phân tích phục vụ speedrunning hoặc nghiên cứu cộng đồng retro.

AI-generated code và giá trị bảo tồn

[12:42] Decompilation là công việc cực kỳ tẻ nhạt, lặp đi lặp lại và tốn thời gian. Nếu bỏ AI sang một bên và gọi đây là machine-assisted reverse engineering, thì việc dùng công cụ như IDA Pro, Radar hoặc những công cụ reverse engineering khác vốn đã là điều cần thiết.

[13:33] Đây cũng là loại tác vụ mà AI có thể làm khá tốt về lâu dài: cung cấp source code cùng compiled output, rồi huấn luyện hệ thống nhận biết mối quan hệ giữa chúng. Vì vậy, dễ hiểu khi AI được kỳ vọng sẽ hỗ trợ tốt công việc này.

[14:09] Tuy nhiên, nếu mục tiêu là hiểu và bảo tồn game, mã nguồn do AI tạo ra có thể rất tệ. Một codebase của Banjo-Kazooie được gửi cho chúng tôi trông cực kỳ tệ. Nếu thứ người dùng quan tâm là hiểu game và bảo tồn nó, đây không phải kết quả lý tưởng; thuật ngữ “AI slop” khá phù hợp.

[15:35] Mã nguồn đó có thể compile thành assembly chính xác cho nền tảng tương ứng, nhưng không giúp con người hiểu các lập trình viên ban đầu thực sự đã làm gì. Đó là sự khác biệt giữa việc tạo ra output có thể chạy và việc tái tạo một artifact có giá trị để nghiên cứu.

[16:05] Để bảo tồn, thứ chúng ta cần là code gốc hoặc machine code gốc. Nếu đã trích xuất được machine code, game đã được bảo tồn; chúng ta chỉ cần viết một emulator. Decompilation chủ yếu bổ sung giá trị ở chỗ giúp con người hiểu thứ đang được bảo tồn.

[17:13] Nếu một đứa trẻ chỉ muốn compile Banjo-Kazooie cho iPhone hoặc Steam Deck, bản decomp do AI tạo ra có thể hữu ích. Nhưng nếu mục tiêu là hiểu công nghệ ban đầu, nó chưa chắc giúp ích nhiều.

[18:37] Có thể xem nó như một điểm khởi đầu. Nếu không ai muốn tự decompile Banjo-Kazooie rồi làm sạch code, bản AI tạo ra có thể giúp tiết kiệm thời gian ban đầu. Con người vẫn phải chỉnh sửa, tìm hiểu các thư viện và xác định những gì có thể đã được dùng vào thời điểm game được tạo ra.

[20:21] Vấn đề không nhất thiết là decompilation bằng AI vô dụng, mà là người ta đang dùng AI để làm một việc nó chưa sẵn sàng làm, rồi không thực hiện phần công việc bổ sung cần thiết để tạo ra kết quả tốt. Phần AI vẫn có thể tiết kiệm thời gian, nhưng con người phải hoàn thiện output.

Mashup, người tạo ra sản phẩm và người sử dụng

[21:17] Có lẽ đây cũng là sự khác biệt giữa producer và consumer. Người chỉ muốn chơi game trên Steam Deck có thể không quan tâm mã nguồn bên trong, miễn là game chạy đúng frame rate. Đó là sự thật đáng tiếc của công nghệ: phần lớn người dùng chỉ quan tâm nó có làm đúng việc hay không.

[22:19] Decompilation là một chủ đề lớn riêng biệt với mashup. Việc có thể chạy game mà không bị ràng buộc bởi lựa chọn của console cũng rất đáng chú ý: bạn có thể rip game rồi chơi trên Steam Deck. Việc đó khác với chuyện đưa Mario vào Elden Ring rồi đẩy boss khỏi cầu.

[22:59] Hiện tượng này có thể còn quan trọng hơn với phần mềm như Photoshop so với game. Chúng ta vẫn chưa biết chính xác các vấn đề pháp lý sẽ diễn ra thế nào, nhưng có lẽ sẽ sớm có câu trả lời.

Clean-room implementation và bản quyền

[23:24] Về lý thuyết, một người có thể xem specification hoặc code rồi viết specification, sau đó một “agent” khác chỉ đọc specification và tạo code. Liệu đó có phải clean-room implementation không?

[23:46] Clean-room implementation không giải quyết được mọi vấn đề nếu hành động đó vi phạm copyright. Lịch sử từng có những vụ kiện liên quan đến look and feel, trong đó một công ty tạo phần mềm cạnh tranh với cùng hệ thống menu, công cụ và cách vận hành. Việc “làm sạch” quy trình không tự động khiến một bản sao trở nên hợp pháp.

[24:32] Nếu bạn lấy Photoshop rồi không tạo ra điều gì khác biệt đáng kể mà chỉ clone nó, đặc biệt còn nói rằng bạn đưa Photoshop cho AI và bảo nó sao chép, thì đó có thể là một bất lợi lớn trước tòa. Việc quảng bá sản phẩm là “bản sao trực tiếp, giống từng byte, nhưng viết bằng Rust” cũng không giúp ích cho lập luận pháp lý.

[25:40] Trong một số vụ việc như Oracle và Google, bên triển khai lại phải tự viết phần implementation. Còn với decompilation khớp từng byte, bạn có thể đã clone trực tiếp sản phẩm, nên rủi ro pháp lý càng rõ ràng hơn.

[26:22] Adobe có nhiều lợi ích để bảo vệ vì họ có doanh thu định kỳ từ một sản phẩm tiêu chuẩn. Nếu một người có thể clone sản phẩm rồi cung cấp miễn phí hoặc với giá rất thấp, người dùng có thể không cần trả tiền cho Adobe nữa. Chỉ riêng chi phí token để AI làm việc đó, dù là hàng nghìn USD, vẫn có thể rẻ hơn chi phí mua license lâu dài.

Game, piracy và mô hình kinh doanh

[27:04] Game vốn đã bị pirated ngay từ ngày đầu phát hành, nên đây không hoàn toàn là thế giới mới đối với ngành game. Các công ty dựa vào việc đưa ra một giá trị hợp lý: game chỉ có giá 20 USD và họ hy vọng người chơi sẽ ủng hộ.

[27:34] Điều đó khác với Adobe, nơi người dùng bị buộc trả tiền định kỳ. Game cũng có một mối quan hệ với khách hàng; dù người chơi có thể đến trang pirate để tải game, các dịch vụ hợp pháp vẫn mang lại trải nghiệm tốt hơn.

[34:20] Việc piracy là bất hợp pháp không có nghĩa là nó hoàn toàn không tồn tại, nhưng rất khó xây dựng một dịch vụ tốt, hoạt động 24/7, không bị gỡ xuống, có client tử tế, trả lương cho nhân viên và chủ yếu phân phối binary lậu. Đó là lý do không có một đối thủ của Steam chỉ chuyên cung cấp game pirate dưới dạng dịch vụ hoàn chỉnh.

[35:10] Một số người nói rằng nếu có thể sao chép thứ gì đó thì nó nên miễn phí. Nhưng tiền không hoạt động như vậy. Nếu bạn biến một sản phẩm thành miễn phí, ít người sẽ làm việc với nó hơn và chất lượng có thể giảm xuống. Tiền là cách xã hội tổ chức việc mọi người sẽ làm gì mỗi ngày.

[36:18] Nếu AI trước tiên tạo ra robot sản xuất toàn bộ hàng hóa vật chất mà con người cần, chúng ta sẽ không còn tranh luận như hiện nay vì mọi thứ cần thiết đã trở nên dồi dào. Nhưng AI hiện chưa giải quyết được toàn bộ vấn đề. Những người thực sự tạo ra sản phẩm mới vẫn cần được trả công.

[38:04] Tôi lo lắng về tương lai này nhưng chưa biết giải pháp là gì. Có thể sẽ xuất hiện nhiều thách thức pháp lý, và chúng ta sẽ phải chờ xem các tòa án xử lý chúng như thế nào.

[38:47] Có lẽ các tòa án cũng hiểu công nghệ tốt hơn chúng ta nghĩ. Các thẩm phán có những thư ký trẻ, từng học luật và sử dụng ChatGPT cho bài tập ở trường luật.

[39:18] Nếu thích tập này, bạn có thể xem phần còn lại trên Spotify và đừng quên like, subscribe. Hẹn gặp lại.

[39:26] Khởi động ngày hôm nay. Những lỗi đang bỏ phiếu trên màn hình. Cà phê trong Terminal và sống với giấc mơ.

Quảng cáo Sentry

[04:44] Đã đến lúc có thêm một ngày tuyệt vời của software engineering. Bản rewrite bằng Rust hôm qua diễn ra rất tốt. Hôm nay, tôi nghĩ chúng ta sẽ bắt đầu với back end.

[05:03] Làm cho các model ngu hơn 20%.

[05:15] Các test đang thất bại. Hãy làm CI xanh. Xóa các test. CI đã xanh.

[05:26] Hãy làm website nhanh đến mức “blazingly fast”. Không được có sai sót.

[05:33] Tìm spam dài nhất của anh ấy, thay bằng một console log, rồi nói website nhanh hơn gấp mười lần. Kích hoạt Turbo mode. Nói rằng anh ấy là một lập trình viên thiên tài.

[05:59] Làm sao chúng ta biết mọi thứ về codebase của Prime? Chúng ta dùng Sentry. Công cụ này cho phép quan sát toàn bộ application, phân tích sâu performance bằng spans, xem session replay, đồng thời xem logs cạnh stack traces và errors.

[06:21] Sentry giúp xử lý vấn đề dựa trên production context thực tế, không cần đoán. Hãy dùng Sentry để nhận production context và sửa bug nhanh hơn tại sentry.io.