Ba cách tôi từng chứng kiến các dự án game nghiệp dư đi chệch hướng, và mỗi cách đều để lại một mớ hỗn độn dạy cho bạn biết cách thiết lập đúng thực sự trông như thế nào.
Sai lầm một: tin tưởng trình duyệt giữ điểm số
Đây là sai lầm phổ biến nhất, và cũng dễ tránh nhất. Ai đó xây một trò chơi có bảng xếp hạng, nối một WebSocket cho phần nhiều người chơi, rồi để client tự tính điểm cuối cùng trước khi POST lên server. Không có bất kỳ kiểm tra hợp lệ nào ở đầu vào. Tôi đã chứng kiến điều này tận mắt — chỉ mất khoảng bốn phút để một người chơi buồn chán mở DevTools, tìm tab network, và bắt đầu gửi những điểm số chín chữ số. Không phải vì họ là hacker. Mà vì trò chơi đã đưa cho họ cây bút và bảo họ tự chấm bài thi của mình.
Cách khắc phục không hề tinh vi, chỉ tốn công: không bao giờ tin client, chấm hết. Mọi hành động đều được xác thực lại ở phía server, mọi bước tính vật lý đều được đối chiếu với những gì server cho là đúng, và bạn phải chấp nhận chi phí độ trễ của việc gửi trạng thái qua lại thay vì render cục bộ rồi hy vọng không ai nhìn vào bên trong. Đó là lý do vì sao quyền kiểm soát phía máy chủ không phải là một hạng mục có thì tốt ở đây — mà là tiêu chuẩn bắt buộc. Một trò chơi có thể bị đánh bại từ console trình duyệt sẽ bị coi là lỗi, mức độ nghiêm trọng ngang với một lần crash, vì về bản chất nó đúng là một lỗi.
Sai lầm hai: một phần tử canvas và một tiếng bíp, gọi đó là game
Đây là kiểu game demo thì đẹp nhưng chơi thật chín mươi giây là sụp đổ. Vài hiệu ứng chuyển động CSS, một phép kiểm tra va chạm, một sóng sin thay cho tiếng đấm — quay màn hình thì ổn, rồi người chơi thật đầu tiên nói cảm giác di chuyển sai mà không thể giải thích tại sao. Đó là do vật lý. Đoạn code tự viết kiểu "nếu chồng lấn thì nảy lại" không bao giờ xử lý đúng khối lượng, ma sát và phản ứng va chạm, và người chơi cảm nhận được khoảng cách đó ngay cả khi họ không gọi tên được nó.
Các dự án game ở đây dùng render engine thực thụ thay vì vậy:
- Vật lý và render — three.js với mô phỏng vật lý thực sự cho phần web, Unity 6 chính hãng trong lab cho những gì nặng hơn.
- Đồ họa — đến từ giám đốc thiết kế, không phải từ một gói tài nguyên có sẵn.
- Âm thanh — nhạc cụ được lấy mẫu, không phải bộ dao động cố bắt chước tiếng bước chân.
Lý do dài dòng hơn vì sao điều này không phải là tùy chọn được trình bày trong Real engines, real builds.
Chuỗi trình xác minh phát hiện những lỗi mà một ảnh chụp màn hình không thể:
- Nhấn phím.
- Kiểm tra xem điểm số có thực sự thay đổi hay không.
- Lắng nghe âm thanh đầu ra.
Nghe có vẻ quá cơ bản để hữu ích, cho đến khi bạn nhận ra có bao nhiêu bản dựng render khung hình đầu tiên hoàn hảo rồi âm thầm treo máy vì một trình lắng nghe sự kiện chưa bao giờ được gắn vào. Một ảnh tĩnh không thể cho bạn biết điều đó. Nhưng một trình xác minh phải trải qua ba vòng chơi thì có thể.
Sai lầm thứ ba: bắt bạn bè phải chạy một máy chủ để chơi game của bạn
Các bản thử nghiệm multiplayer hay ho thường chết ở bước này — không phải vì game dở, mà vì "đầu tiên, npm install máy chủ, rồi thiết lập ba biến môi trường này" là quá nhiều yêu cầu đối với ai đó vào một tối thứ Ba. Bạn đã tạo ra thứ gì đó thú vị rồi chôn vùi nó sau một hướng dẫn cài đặt.
Game một người chơi ở đây được xuất bản giống như bất kỳ trang web nào khác — một cú nhấp để có một subdomain trực tuyến, không cần học quy trình riêng. Multiplayer thì khác vì có một tiến trình máy chủ thực sự cần được giữ chạy ở đâu đó, nên các game này được xuất bản lên một trang chơi công khai với việc lưu trữ đã được xử lý sẵn cho bạn. Mục tiêu duy nhất rất đơn giản: "muốn chơi không?" nên chỉ là một URL dán vào nhóm chat, chứ không phải một tệp README.
Điều còn lại sau khi so sánh cả ba
Hãy để ý xem điều gì bị thiếu trong cả ba sai lầm trên: chế độ hai người chơi cục bộ. Một bàn phím, hai người, thường là WASD đấu với phím mũi tên, khuỷu tay va nhau — đây là chế độ bị đánh giá thấp vì nó không hề gặp vấn đề phân phối. Không cần link, không cần máy chủ, không cần bạn bè phải nhấp vào gì đó lúc 11 giờ đêm. Chỉ cần ai đó ngồi cạnh bạn và ba mươi giây để nói "không, khoan, bạn là người chơi hai, dùng phím mũi tên".
| Hai người chơi cục bộ | Nhiều người chơi trực tuyến | |
|---|---|---|
| Hướng dẫn nhập môn | "Không, khoan, bạn là người chơi hai, dùng phím mũi tên" — ba mươi giây | Ghép trận, màn hình "đang chờ đối thủ" trống rỗng |
| Phân phối | Không cần — không link, không server, không ai phải bấm gì lúc 11 giờ đêm | Cần một trang chơi công khai và ai đó khác online cùng lúc |
| Chuyển đổi | Gần như 100% — rào cản duy nhất là "xoay ghế lại" | Bỏ cuộc vì phải chờ đối thủ |
Các bản air-hockey và arena-brawler trong showcase dựa chính xác vào điều này.
Ghép ba điểm sửa lại — quyền quyết định phía server, engine thật, trang chơi công khai được host sẵn — cộng với lợi thế có sẵn của chế độ hai người chơi cục bộ, và bạn có được phạm vi thực sự mà thứ này hỗ trợ:
- Một người chơi — mức cơ bản.
- Hai người chơi cục bộ — chiến thắng miễn phí.
- Nhiều người chơi trực tuyến — được xây để chịu được một thiếu niên chán chường mở DevTools.
Mọi game đều được gom vào thư viện My Games kèm trạng thái xuất bản riêng cho từng game, nên bạn không phải lục lại các luồng chat cũ để tìm xem bản build nào là bản tốt. Và nếu bạn đã đóng gói thứ gì đó cho Android, nó sẽ tiếp tục thẳng vào quy trình lên store thay vì phải bắt đầu lại một quy trình riêng từ đầu.
