Quank: Shooter WebGL 600 KB Vibe-Coded Bằng Claude Code, Nhưng Điểm Hay Nằm Ở Engine Tự Viết

Một devlog mới trên r/aigamedev đáng chú ý vì đi ngược làn sóng “Astra làm game trong vài chục phút”: tác giả dành khoảng một tháng dùng gói Claude Code 20 USD để xây Quank, một shooter 3D chạy hoàn toàn trên trình duyệt bằng JavaScript + WebGL và có bản minify khoảng 600 KB. Bài đăng đạt khoảng 79 upvote trong ngày 17/09/2026 tại thời điểm kiểm tra, nhưng tín hiệu đáng quan tâm hơn là lượng thông tin kỹ thuật tác giả công khai: engine sector kiểu Doom/Duke Nukem 3D, editor riêng, model/rig/animation do AI hỗ trợ, cùng những chỗ AI thất bại ở floating-point geometry và công cụ vẽ level.

Điểm thú vị nhất: không dùng engine game có sẵn

Quank không phải một game Three.js hay Unity WebGL. Theo tác giả, toàn bộ game được viết bằng JavaScript + WebGL và chạy front-end. Điều này làm case study có giá trị hơn một demo “AI gọi API engine rồi ráp scene”, vì coding agent phải làm việc trực tiếp với những vấn đề thấp tầng hơn: quản lý geometry, camera, visibility, collision, editor tooling và tối ưu bundle.

Tác giả mô tả hệ thống sector lấy cảm hứng từ Doom và Duke Nukem 3D. Thay vì coi toàn bộ map là một khối 3D tùy ý, thế giới được chia thành những khu vực có quan hệ rõ ràng. Kiểu cấu trúc này giúp giảm lượng geometry phải xử lý, đồng thời mở ra các hiệu ứng như mirror hoặc không gian phi Euclid. Đây là một ví dụ tốt cho việc vibe coding không nhất thiết đồng nghĩa “bỏ qua kiến trúc”: khi constraints đủ rõ, agent có thể triển khai một kiến trúc rất cổ điển nhưng phù hợp mục tiêu.

600 KB không phải phép màu, mà là kết quả của phạm vi được kiểm soát

Con số khoảng 600 KB áp dụng cho bản minify; source không minify khoảng 2 MB. Tác giả cũng nói project có thể tăng kích thước khi thêm audio, enemy và level. Vì vậy không nên đọc con số 600 KB như benchmark tuyệt đối để so với game khác.

Điều đáng học là tư duy giữ dependency thấp. Khi game chạy bằng vanilla JavaScript + WebGL, mỗi hệ thống mới đều buộc người làm cân nhắc chi phí thật: parser, renderer, editor, animation, data format và asset loading. Với một solo dev dùng coding agent, constraint kiểu này giúp hạn chế tình trạng agent tự thêm thư viện cho từng vấn đề nhỏ rồi biến project thành một hệ thống khó audit.

Sector renderer: chỗ AI làm được nhiều, nhưng geometry vẫn là vùng nguy hiểm

Tác giả cho biết phần khó nhất đối với AI là sector geometry, đặc biệt các lỗi số thực và các hàm drawing trong level editor. Đây là điều rất hợp lý về mặt kỹ thuật. Một renderer dựa vào polygon, portal, clipping hay phép chiếu chỉ cần sai một epsilon nhỏ là có thể sinh khe hở, polygon đảo hướng, z-fighting hoặc lỗi collision rất khó tái hiện.

Đây cũng là chỗ không nên giao cho agent một prompt kiểu “fix mọi lỗi render”. Cách an toàn hơn là xây test scene nhỏ cho từng pathology: hai mặt gần đồng phẳng, polygon lõm, sector có portal lồng nhau, camera sát tường, góc rất hẹp, object vượt qua ranh giới sector. Mỗi bug được khóa bằng một repro scene thì agent mới có cơ hội sửa mà không phá case khác.

Workflow của tác giả: task file Markdown + plan mode + rollback

Quank không dùng một “skill thần kỳ”. Tác giả tạo một thư mục nội bộ không commit Git, chứa các file .md mô tả từng task. Với feature khó như sector system, file task ghi cụ thể thuật toán mong muốn; Claude Code được trỏ vào task, chạy plan mode, sau đó người làm đàm phán lại kết quả nếu cần. Nếu hướng triển khai không ổn, họ rollback và thử cách khác.

Đây là một pattern rất nên áp dụng cho game lớn: spec nhỏ, test được, rollback được. Nó khác hẳn việc để agent tự đọc backlog lớn rồi sửa hàng chục hệ thống cùng lúc. Với project game, mỗi task tốt nên trả lời ít nhất bốn câu hỏi: thay đổi hệ thống nào, hành vi đầu ra nào phải đúng, scene/test nào chứng minh nó đúng, và file hoặc subsystem nào không được phép đụng tới.

AI lại làm khá tốt model, rigging và animation

Tác giả nói phần model enemy, rigging và animation chủ yếu được vibe-code, chỉ chỉnh tay nhẹ. Đây là điểm thú vị bởi cùng một agent lại gặp khó với geometry thuật toán nhưng làm tốt hơn ở pipeline asset có cấu trúc rõ.

Điều này không có nghĩa AI đã thay được animator. Trong case Quank, art direction và scope tương đối phù hợp kiểu shooter retro. Một rig/game animation đơn giản có tolerance khác hoàn toàn character AAA nhiều layer, IK, root motion và combat montage. Bài học đúng hơn là: hãy chọn task có output dễ kiểm tra bằng mắt và có constraint rõ; agent thường hiệu quả hơn ở đó.

Editor tự viết mới là phần quyết định tốc độ content

Một game engine nhỏ có thể chạy tốt nhưng nếu editor tệ, việc thêm level sẽ trở thành nút thắt. Quank có level editor và model visualizer do AI xây phần lớn. Tác giả cũng chỉ ra rằng các drawing function trong editor là nơi Claude gặp khó.

Với solo dev, đây là điểm thường bị đánh giá thấp. Sau khi core gameplay chạy được, agent nên được chuyển sang xây tooling giúp con người làm content nhanh hơn: snap, duplicate, multi-select, property inspector, undo/redo, validation, spawn preview, collision overlay và export. Một editor tốt giúp giảm prompt volume về lâu dài vì bạn không cần bảo agent sửa từng level bằng code.

Tại sao case này đáng chú ý hơn một demo “one-shot”

Quank có ba đặc điểm làm nó khác nhiều clip AI game ngắn: project tồn tại đủ lâu để xuất hiện vấn đề kỹ thuật thật; tác giả nói rõ phần nào AI làm và phần nào con người chỉnh; và họ dự định open-source cả game lẫn editor. Khi code được công khai, những claim về renderer, size và workflow sẽ có cơ hội được cộng đồng kiểm chứng sâu hơn.

Đồng thời, tác giả không tô hồng quá trình. Claude Code phải làm việc theo từng chunk giữa các giới hạn sử dụng, kết quả có lúc phải rollback, và model mới hơn vẫn có thói quen tạo quá nhiều comment. Những chi tiết này khiến devlog có giá trị hơn một clip chỉ khoe thành phẩm.

Nếu áp dụng workflow này cho game của bạn

Không cần tự viết WebGL engine để học từ Quank. Với Godot, Unity, Three.js hay Phaser, có thể giữ cùng cấu trúc làm việc: tạo task file riêng cho một feature, buộc agent plan trước, xác định acceptance test, triển khai trong phạm vi nhỏ, chạy build/playtest, rồi commit hoặc rollback. Những phần có nhiều toán học hoặc geometry nên có repro scene cực nhỏ thay vì test trong map thật.

Với pixel art 2D, “sector geometry” có thể được thay bằng state machine animation, tile collision hoặc hitbox. Với game 3D, nó có thể là locomotion, camera, navmesh hoặc networking. Điểm chung là AI hiệu quả nhất khi bug được biến thành một bài toán nhỏ có bằng chứng.

Kết luận

Quank không gây chú ý vì AI tạo một shooter trong vài phút. Nó thú vị vì cho thấy coding agent có thể đi khá sâu vào một project render 3D tự viết, nhưng vẫn cần kiến trúc, constraint, test scene, rollback và quyết định thủ công. Nếu vibe coding đang tiến từ prototype sang production, những case kiểu này hữu ích hơn rất nhiều so với việc chỉ hỏi “model nào tạo game nhanh nhất”.

Nguồn gốc: bài đăng của tác giả trên r/aigamedev — “600 KB WebGL shooter made with the $20 Claude Code plan in a month (Opus 4.6)”, đăng ngày 17/09/2026. Số upvote là snapshot tại thời điểm biên tập và có thể tiếp tục thay đổi.