Game thuần trình duyệt ngày càng nghiêm túc: Những gì các dự án chiến đấu mã nguồn mở hé lộ

Tôi bắt đầu nghiên cứu này với kỳ vọng chỉ tìm thấy một vài thử nghiệm chiến đấu trên trình duyệt đáng chú ý. Thay vào đó, tôi phát hiện một hệ sinh thái rộng hơn nhiều: các nguyên mẫu hành động góc nhìn thứ ba thực sự với khóa mục tiêu, cây combo phân nhánh, perfect parry, bất tử khi né, hệ thống posture, đòn đánh trên không, tín hiệu báo trước đòn của boss, motion warping, hit-stop, va chạm vũ khí theo vật lý, hỗ trợ gamepad, điều khiển cảm ứng và mô phỏng tất định.

Đó mới là kết quả quan trọng. Đây không còn chỉ là những game nhỏ tình cờ được render bên trong một trang web. Một số dự án đang giải quyết chính những bài toán kỹ thuật mà game hành động truyền thống phải xử lý, nhưng chúng được phân phối dưới dạng một URL và có thể chơi ngay lập tức.

Với tôi, một lập trình viên web, đây là phần hấp dẫn nhất. Cách hình dung cũ về game bị chi phối bởi bộ cài, các bản tải xuống lớn, trình vá lỗi, launcher và khoảng chờ từ lúc biết đến một game cho đến khi thật sự chạm tay vào nó. Trình duyệt rút ngắn con đường đó rất mạnh: mở liên kết, tải asset rồi bắt đầu chơi.

Nghiên cứu này tập trung vào các dự án có bản build chạy được trên trình duyệt và mã nguồn công khai. Tôi chủ ý loại các bản xuất Unity WebGL vì muốn nghiên cứu game được xây dựng xoay quanh công nghệ web, thay vì game chỉ đơn thuần được xuất sang web.

Những dự án mạnh nhất tôi tìm thấy

Những phát hiện hữu ích nhất không phải dự án nào cũng mạnh vì cùng một lý do. Có dự án sở hữu hệ thống combo sâu nhất. Dự án khác có kiến trúc góc nhìn thứ ba tốt hơn, mô phỏng chiến đấu sạch hơn hoặc những cú va chạm vật lý thuyết phục hơn.

Vì sao kết quả khiến tôi bất ngờ

Điều bất ngờ không chỉ đơn giản là đồ họa đẹp. Render một cảnh trau chuốt chỉ là một phần của phát triển game. Những dự án nổi bật đang triển khai các hệ thống rất khó làm giả một cách thuyết phục: input buffering, chuyển trạng thái chiến đấu, chọn mục tiêu, chuyển động khi tấn công, timing animation, phát hiện đòn đánh, phản ứng của kẻ địch, cửa sổ phòng thủ, hành vi camera và phản hồi va chạm.

Từ đó xuất hiện một số phân biệt hữu ích:

• timing của animation không phải timing của chiến đấu;
• frame rate render không phải tốc độ mô phỏng;
• va chạm không tự động đồng nghĩa với một đòn đánh hợp lệ;
• animation không nhất thiết là nguồn quyết định chuyển động;
• tiếp xúc nhìn thấy bằng mắt không đồng nghĩa với cảm giác va chạm.

Những khác biệt này lặp đi lặp lại ở các dự án mạnh nhất và quan trọng hơn logo renderer trong README.

Voxel Musou: chiến đấu trên trình duyệt có thể có một ngữ pháp chiêu thức thực sự

Voxel Musou là một trong những ví dụ rõ ràng nhất cho thấy chiến đấu trên trình duyệt không còn phải là một animation tấn công gắn với một nút bấm. Mã nguồn có tại mike007jd/voxel-musou.

Dự án sử dụng các chuỗi đòn đánh thường dài và những nhánh charge thay vì một combo hoàn toàn tuyến tính. Điều này quan trọng về mặt kiến trúc vì hệ thống có thể được mô hình hóa như sau:

current move + buffered input + combat state -> next move

Đây là nền tảng tốt hơn nhiều cho một game character-action so với một tập hợp các điều kiện đặc biệt ngày càng phình to. Dự án cũng thể hiện các đòn đánh trên không, chuỗi đặc biệt, nhiều bộ kỹ năng nhân vật, hành vi boss, hit-stop và chiến đấu với những nhóm kẻ địch đông.

Bài học kỹ thuật rộng hơn là chiêu thức nên trở thành dữ liệu và các chuyển trạng thái nên được biểu diễn rõ ràng. Khi đã làm được vậy, thêm một nhân vật mới không còn đòi hỏi phải viết lại toàn bộ bộ điều khiển chiến đấu.

Long Wind: gần nhất với một game hành động trình duyệt hiện đại

Long Wind là một trong những tài liệu tham chiếu toàn diện mạnh nhất vì nó kết hợp di chuyển góc nhìn thứ ba với đòn nhẹ và nặng, khóa mục tiêu, đỡ, perfect parry, bất tử khi né, áp lực posture, kết liễu, phản ứng hất tung và đánh ngã, đạn, boss và nhiều kiểu kẻ địch. Mã nguồn có tại jbang2004/long-wind.

Giá trị của nó không nằm ở việc từng tính năng riêng lẻ đều chưa từng xuất hiện, mà ở chỗ tất cả cùng tồn tại trong một nguyên mẫu hành động thuần trình duyệt. Vì thế, đây là tài liệu tham chiếu hữu ích để lần theo toàn bộ luồng từ input đến chọn mục tiêu, trạng thái tấn công, animation, tiếp xúc, phản ứng, hit-stop và phản hồi camera.

Motion warping giải quyết một vấn đề mà các demo web thường bỏ qua

Samurai Third-Person Template ThreeJS đặc biệt thú vị vì xử lý một vấn đề kinh điển của cận chiến góc nhìn thứ ba. Mã nguồn có tại achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Một animation tấn công được tác giả tạo sẵn giả định rằng mục tiêu sẽ ở một khoảng cách nhất định khi cú đánh đến frame tiếp xúc. Trong game thực tế, mục tiêu gần như không bao giờ đứng đúng vị trí hoàn hảo. Nếu nhân vật chỉ phát animation tại chỗ, thanh kiếm có thể trông như bị hụt dù game vẫn áp dụng damage. Nếu nhân vật được dịch chuyển tức thời vào vị trí, đòn đánh lại trông giả tạo.

Motion warping đưa ra câu trả lời tốt hơn: điều chỉnh rotation và translation trong lúc tấn công để nhân vật đạt đến vị trí tiếp xúc mong muốn đúng thời điểm.

Điểm phân biệt quan trọng là:

animation intent != movement authority

Nhân vật có thể giữ nguyên ý đồ hình ảnh của animation được tạo sẵn trong khi bộ điều khiển gameplay vẫn có quyền quyết định nhân vật thực sự di chuyển đến đâu.

Phát hiện collision và xác thực đòn đánh là hai bài toán khác nhau

Stick & Steel khám phá một mô hình chiến đấu rất khác. Mã nguồn có tại Rabneba/stick-steel.

Thay vì chủ yếu coi thanh kiếm là một animation đi kèm vùng gây damage, dự án cho vũ khí sự hiện diện vật lý. Vận tốc tiếp xúc, hướng vũ khí, vùng cơ thể, guard, va chạm vũ khí, đánh ngã và tước vũ khí đều có ý nghĩa.

Bài học dễ áp dụng nhất không phải là mọi game hành động đều nên dùng vũ khí hoàn toàn dựa trên vật lý. Mà là điều này:

Va chạm cho bạn biết hai vật đã chạm nhau. Nó không cho bạn biết liệu một đòn đánh có ý nghĩa thực sự đã xảy ra hay chưa.

Một hệ thống chiến đấu thuyết phục thường cần thêm một lớp thứ hai để quyết định tiếp xúc có đủ vận tốc hay không, đúng hướng hay không, đúng phần của vũ khí hay không, đúng timing hay không và trạng thái mục tiêu có hợp lệ để được tính là damage hay không.

Xử lý chiến đấu tập trung giúp phòng thủ phức tạp dễ suy luận hơn

Hollowmere, với source code tại euuuuuuan/hollowmere-public, nổi bật ít hơn về trình diễn hình ảnh và nhiều hơn về kiến trúc phần mềm.

Mô phỏng chiến đấu của nó được tách khỏi rendering, còn việc xử lý phòng thủ được tập trung hóa. Cách này tránh một lỗi thiết kế phổ biến trong game hành động, nơi hệ thống né, hệ thống parry, hệ thống phản ứng khi trúng đòn và lớp animation có thể độc lập đưa ra kết luận khác nhau về việc cùng một đòn đánh có trúng hay không.

Một mô hình tư duy sạch hơn là:

incoming attack -> evade | parry | hit

Renderer nên hiển thị kết quả, chứ không tự tạo ra một phiên bản thứ hai của sự thật chiến đấu.

Sự phân biệt này ngày càng quan trọng khi hệ thống chiến đấu lớn lên. Mô phỏng tất định và chuyển trạng thái rõ ràng không phải những tính năng hào nhoáng, nhưng chúng giúp chiến đấu phức tạp dễ kiểm thử, debug và mở rộng hơn.

Game feel là một hệ thống kỹ thuật, không phải đồ trang trí

Fabled Revolutions, với source code tại ericrius1/FabledRevolutions, hữu ích chính vì nó cô lập những hiệu ứng khiến đòn đánh có cảm giác nặng và rõ lực.

Một hệ thống chiến đấu đúng về logic vẫn có thể cho cảm giác yếu. Va chạm có thể chính xác, damage có thể được áp dụng ở đúng frame, nhưng kết quả vẫn có thể giống như hai model xuyên qua nhau.

Cảm giác lực tác động thường đến từ một chồng hiệu ứng ngắn:

• hit-stop;
• rung hoặc giật camera;
• vệt vũ khí;
• hạt hiệu ứng va chạm;
• hurt flash;
• knockback;
• phản ứng animation;
• âm thanh đúng thời điểm.

Điều này gợi ra một phân biệt hữu ích khác: tính đúng đắn của chiến đấu không phải game feel của chiến đấu. Game trên trình duyệt cần cả hai.

Renderer không phải yếu tố dự đoán chính cho chất lượng chiến đấu

Một trong những mẫu hình thú vị hơn từ nghiên cứu là chất lượng chiến đấu tốt nhất không phụ thuộc vào việc dự án có dùng API render mới nhất hay không.

Three.js xuất hiện nhiều lần. Một số dự án dùng công nghệ render liên quan đến WebGPU, số khác dùng stack truyền thống dựa trên WebGL. Engine vật lý, TypeScript, JavaScript, Vite, WebAssembly và nhiều cách render khác nhau đều xuất hiện trong nghiên cứu.

Nhưng chiến đấu tinh vi phụ thuộc nhất quán hơn vào kiến trúc: mô phỏng fixed-step, trạng thái rõ ràng, nhắm mục tiêu đáng tin cậy, quyền sở hữu animation hợp lý, chiêu thức điều khiển bằng dữ liệu, xử lý damage tập trung và phản hồi va chạm tốt.

Đó là tín hiệu đáng khích lệ với lập trình viên web. Bạn không cần chờ mọi người dùng đều có stack đồ họa mới nhất rồi mới thử nghiệm thiết kế chiến đấu nghiêm túc.

Vì sao phân phối qua trình duyệt làm thay đổi bài toán

Trình duyệt có một lợi thế hầu như không liên quan đến đồ họa: ma sát phân phối cực thấp.

Game truyền thống thường đặt nhiều bước giữa lúc người chơi biết đến game và lúc họ tương tác: tìm trang cửa hàng, tải một gói lớn, cài đặt, khởi chạy, chờ cập nhật và đôi khi còn phải tạo tài khoản trước khi chạm đến phần chơi có ý nghĩa.

Game trên trình duyệt có thể rút con đường đó xuống chỉ còn một liên kết.

Điều này thay đổi cách prototype được chia sẻ và kiểm thử. Lập trình viên có thể xuất bản một build, gửi URL, đưa người khác vào đúng phiên bản đó ngay lập tức, thu thập phản hồi rồi triển khai một vòng lặp mới mà không cần yêu cầu tester tự cài một gói mới.

Lợi thế này đặc biệt quan trọng với game thử nghiệm và phát triển độc lập. Trình duyệt không chỉ là runtime; nó còn là một hệ thống phân phối.

Những chỗ trình duyệt vẫn thua

Nghiên cứu này không khiến tôi tin rằng trình duyệt đã thay thế các nền tảng game native. Chúng chưa làm được điều đó.

Một số giới hạn vẫn rất quan trọng:

• Khối lượng asset lớn. Truy cập tức thời sẽ không còn cảm giác tức thời nếu game cần một bản tải ban đầu rất lớn.
• Áp lực bộ nhớ. Trình duyệt phải cùng tồn tại với các tab khác và hệ điều hành, còn hành vi bộ nhớ khó dự đoán hơn so với một tiến trình native chuyên biệt.
• Giới hạn nhiệt trên thiết bị di động. Một game 3D hoạt động được về mặt kỹ thuật vẫn có thể bị throttling mạnh trong phiên chơi dài.
• Khác biệt giữa các trình duyệt. Đồ họa, âm thanh, pointer lock, hành vi fullscreen, tay cầm và đặc tính hiệu năng không hoàn toàn đồng nhất.
• Chuẩn bị shader và asset. Việc biên dịch hoặc upload vẫn có thể gây khựng nhìn thấy được nếu pipeline không được thiết kế cẩn thận.
• Giới hạn offline và lưu trữ cục bộ. Ứng dụng native vẫn kiểm soát trực tiếp hơn đối với các bản cài cục bộ dung lượng lớn và file.
• Bảo mật cạnh tranh. Chống gian lận nghiêm túc và các giả định về client không đáng tin cậy trở nên khó hơn nhiều khi client là một ứng dụng web.

Những giới hạn này quan trọng vì chúng xác định nơi game trên trình duyệt mạnh nhất hiện nay: các game hưởng lợi từ truy cập tức thời, lặp nhanh, phân phối đa nền tảng và ngân sách asset/runtime có thể kiểm soát.

AI rút ngắn đáng kể vòng lặp từ prototype đến URL

AI có liên quan ở đây, nhưng không phải vì nó có thể biến một câu thành một game hoàn chỉnh chất lượng cao bằng phép màu. Lợi thế thực tế hơn là tốc độ lặp.

Phát triển game hiện đại có rất nhiều tác vụ nhỏ mà tổng chi phí cộng lại rất lớn: thiết lập state machine, xây dựng màn hình debug, viết test, thử nghiệm hành vi kẻ địch, tạo định dạng dữ liệu cho chiêu thức, tái cấu trúc mã input, prototype shader, điều tra lỗi vật lý và nối nội dung tạm thời.

AI có thể rút ngắn nhiều vòng lặp như vậy. Kết hợp với phân phối qua web, quy trình trở nên trực tiếp khác thường:

idea -> prototype -> deploy -> open URL -> test -> iterate

Trình duyệt vốn đã giúp việc triển khai nhanh. AI cũng có thể tăng tốc phần hiện thực hóa của chính vòng lặp đó.

Lưu ý quan trọng là tạo nhanh không thay thế gu thẩm mỹ hay việc xác thực. Một bộ điều khiển chiến đấu được sinh tự động có thể sai về cấu trúc. Timing animation vẫn cần phán đoán của con người. Vật lý vẫn cần debug. Hiệu năng vẫn cần đo đạc. AI giảm chi phí thử ý tưởng; nó không loại bỏ nhu cầu quyết định ý tưởng nào là tốt.

Điều này có ý nghĩa gì với lập trình viên web

Ranh giới giữa phát triển web và phát triển game đang bớt cứng nhắc hơn.

Một game trình duyệt nghiêm túc giờ có thể dùng công cụ web quen thuộc nhưng đồng thời cần các khái niệm kỹ thuật game kinh điển:

• bước mô phỏng cố định;
• state machine;
• input buffering;
• đồ thị animation;
• truy vấn không gian;
• vật lý;
• ngân sách frame;
• quản lý tài nguyên GPU;
• timing âm thanh;
• hệ thống tất định.

Đồng thời, các nhà phát triển game nhắm tới trình duyệt nhận được những thứ mà web vốn làm cực tốt: URL, triển khai tức thời, phân phối qua CDN, cập nhật nhanh, telemetry, hệ thống tài khoản, giao diện thích ứng và chia sẻ gần như không có ma sát.

Nghiên cứu này đã thay đổi cách tôi nhìn vấn đề. Tôi không còn chủ yếu xem game trình duyệt là phiên bản giản lược của game native. Tôi xem trình duyệt như một nền tảng game ngày càng đủ năng lực, với một tập thế mạnh khác: phân phối tức thời, lặp nhanh, năng lực 3D ngày càng nghiêm túc và một hệ sinh thái phát triển hiện có khổng lồ.

Web không chỉ ngày càng giỏi hơn trong việc hiển thị các game được xây dựng ở nơi khác. Nó ngày càng trở thành nơi mà các hệ thống game nghiêm túc có thể được thiết kế, hiện thực hóa, kiểm thử, phân phối và chơi trực tiếp.