Vòng phản hồi: Bộ khung chung của camera, điều khiển, cân bằng và tiến trình

Bốn báo cáo lỗi trong cùng một tuần của một dự án.

Camera bám nhân vật bị trễ, cảm giác nặng nề. Nhân vật điều khiển trơn tuột, khó dừng đúng chỗ. Trong chế độ nhiều người chơi, ai dẫn trước ở phút thứ ba gần như chắc chắn thắng. Và telemetry cho thấy ba mươi phần trăm người chơi bỏ game ở màn bảy.

Bốn vấn đề này thuộc bốn hệ thống khác nhau, do bốn người khác nhau phụ trách, và trong hầu hết studio chúng được xử lý bằng bốn cách nghĩ khác nhau. Nhưng cả bốn đều là cùng một loại bài toán, và có một bộ khái niệm duy nhất mô tả được cả bốn. Bộ khái niệm đó đến từ lý thuyết điều khiển.

Đây là kiểu kiến thức đáng học kỹ một lần, vì sau khi nhận ra nó thì nó xuất hiện ở khắp nơi trong suốt phần còn lại của sự nghiệp.

Khái niệm gốc: vòng phản hồi

Một vòng phản hồi gồm năm thành phần.

Giá trị mục tiêu, tức trạng thái mà ta muốn hệ thống đạt tới. Giá trị hiện tại, tức trạng thái hệ thống đang ở. Sai số, tức hiệu giữa hai giá trị trên. Bộ điều khiển, tức quy tắc biến sai số thành hành động. Và tác động, tức thay đổi mà hành động đó gây ra lên hệ thống, sau đó vòng lặp quay lại đo tiếp.

Có hai loại phản hồi, và cách gọi tên chúng gây hiểu lầm nhiều đến mức cần nói rõ ngay.

Phản hồi âm là loại làm giảm sai số. Nó chống lại thay đổi, kéo hệ thống về trạng thái cân bằng, và tạo ra một chu trình tự điều tiết.

Phản hồi dương là loại khuếch đại thay đổi. Điểm quan trọng cần nhớ là chữ dương ở đây chỉ có nghĩa là khuếch đại, hoàn toàn không có nghĩa là tốt. Rất nhiều người, trong đó có không ít người làm game, hiểu sai chỗ này. Ví dụ rõ nhất là ván cờ vua: mất một quân làm ta yếu đi, yếu đi làm tăng khả năng mất quân tiếp, và cứ thế. Đó là một vòng phản hồi dương với kết quả xấu.

Ba tham số điều chỉnh mọi vòng phản hồi là độ lợi, tức phản ứng mạnh bao nhiêu với mỗi đơn vị sai số; độ trễ, tức khoảng cách thời gian giữa lúc sai số xuất hiện và lúc tác động có hiệu lực; và độ giảm chấn, tức mức độ hệ thống dập tắt chuyển động thừa của chính nó.

Và ba bệnh mà mọi vòng phản hồi đều có thể mắc là trễ, tức hệ thống luôn chạy sau mục tiêu; vọt lố, tức hệ thống đi quá mục tiêu rồi phải quay lại; và dao động, tức hệ thống lắc qua lắc lại quanh mục tiêu mà không ổn định được.

Chú thích: Năm thành phần của một vòng phản hồi. Phần lớn lỗi trong các hệ thống dưới đây không nằm ở bộ điều khiển mà nằm ở đoạn đo lại, tức ở độ trễ.

Hệ thống thứ nhất: camera

Đây là ví dụ sạch nhất, và cũng là chỗ tốt nhất để học vì mọi bệnh đều nhìn thấy được bằng mắt.

Mục tiêu là vị trí lý tưởng của camera, thường là vị trí nhân vật cộng một khoảng lệch. Giá trị hiện tại là vị trí camera. Sai số là hiệu giữa hai vị trí. Bộ điều khiển là hàm quyết định camera di chuyển bao nhiêu trong khung hình này.

Cách làm ngây thơ nhất là mỗi khung hình dịch camera một tỷ lệ cố định của sai số. Đây là bộ điều khiển tỉ lệ thuần túy, và nó có một khuyết điểm cố hữu: khi mục tiêu di chuyển liên tục, camera luôn tụt lại phía sau một khoảng và không bao giờ bắt kịp, vì tốc độ của nó tỉ lệ với sai số còn lại.

Giải pháp chuẩn của ngành là lò xo giảm chấn tới hạn. Trong Unity, hàm này có tên SmoothDamp, và mô tả của nó nói rất chính xác điều đang xảy ra: giá trị được làm mượt bởi một hàm giống lò xo giảm chấn, tốc độ chậm dần khi tiến gần đích, và chuyển động không vọt lố quá mục tiêu.

Lý do gọi là tới hạn nằm ở tính tối ưu của nó: lò xo giảm chấn tới hạn hội tụ nhanh nhất có thể mà không vọt lố. Nhanh hơn nữa thì sẽ dao động, chậm hơn thì trễ không cần thiết. Nó cũng theo dõi vận tốc, nên thay vì chỉ chạy theo sau, nó dự đoán được hướng đi của mục tiêu.

Tham số quan trọng nhất là thời gian làm mượt, tức khoảng thời gian xấp xỉ để camera tới được đích, và giá trị nhỏ hơn cho camera bám sát hơn.

Ba bệnh của vòng phản hồi hiện ra rất rõ ở đây. Độ lợi thấp hoặc thời gian làm mượt lớn cho camera lờ đờ, luôn tụt sau nhân vật. Độ lợi cao cho camera dính chặt tới mức từng cú va chạm nhỏ đều truyền thẳng lên màn hình và gây khó chịu. Thiếu giảm chấn cho camera lắc quanh vị trí đích sau mỗi lần nhân vật đổi hướng.

Điều đáng nói là ba bệnh này không có bệnh nào là lỗi lập trình. Chúng đều là hệ quả của việc chỉnh sai ba tham số điều khiển, và biết tên chúng là biết chỉnh chỗ nào.

Chú thích: Ba dạng phản ứng. Cùng một hình dạng này xuất hiện ở camera, ở cảm giác điều khiển, ở cân bằng nhiều người chơi và ở đường cong độ khó, chỉ khác đơn vị của trục thời gian.

Hệ thống thứ hai: điều khiển nhân vật

Ở hệ thống này có một cú lật vai trò đáng chú ý: bộ điều khiển không nằm trong game, nó là chính người chơi.

Người chơi nhìn màn hình, so sánh vị trí nhân vật với vị trí họ muốn, rồi bấm nút để giảm sai số. Game là đối tượng bị điều khiển, không phải bộ điều khiển.

Steve Swink định nghĩa phản hồi thời gian thực trong game feel bằng đúng ngôn ngữ này: một chu trình hiệu chỉnh, trong đó người chơi đọc phản hồi, ra quyết định, hành động, rồi game nhận hành động đó và trả về phản hồi mới, và chu trình này phải nằm dưới khoảng 100 mili giây để độ trễ không bị nhận ra.

Nhìn từ lý thuyết điều khiển, độ trễ đầu vào không phải là một sự bất tiện. Nó là độ trễ trong vòng phản hồi của con người, và mọi vòng phản hồi có độ trễ lớn đều mất khả năng ổn định. Đó là lý do vì sao game có độ trễ cao không chỉ khó chịu mà thực sự khó chơi: người chơi buộc phải điều khiển mù, tức đoán trước thay vì phản ứng.

Quán tính nhân vật chính là độ giảm chấn của hệ thống. Một nhân vật dừng ngay khi thả nút là hệ giảm chấn mạnh, dễ điều khiển chính xác nhưng thiếu sức nặng. Một nhân vật trượt dài khi thả nút là hệ giảm chấn yếu, có cảm giác vật lý nhưng khó dừng đúng chỗ. Toàn bộ công việc tinh chỉnh cảm giác di chuyển thực chất là việc chọn điểm trên trục này.

Và đây là chỗ hai kỹ thuật đã nhắc ở bài về phần cứng hiện ra dưới ánh sáng mới. Coyote time và input buffering không phải là những mẹo vặt rời rạc. Chúng đều là cơ chế bù độ trễ trong vòng phản hồi của con người: một cái nới rộng cửa sổ thời gian sau khi sai số xuất hiện, một cái nới rộng cửa sổ trước khi hành động được phép thực thi. Cả hai đều làm cùng một việc là làm cho vòng phản hồi khoan dung hơn với độ trễ mà con người không tránh được.

Chú thích: Bộ điều nhiệt là vòng phản hồi âm mà ai cũng đã dùng. Nó đo nhiệt độ, so với mục tiêu, rồi bật hoặc tắt. Camera bám nhân vật và hệ thống cân bằng độ khó chạy trên đúng cấu trúc đó.

Hệ thống thứ ba: cân bằng

Đây là chỗ vòng phản hồi dương xuất hiện, và cũng là chỗ hiểu sai gây thiệt hại nhất.

Một vòng phản hồi dương trong cân bằng nghĩa là làm tốt thì được thưởng thứ giúp làm tốt hơn nữa. Chuỗi hạ gục liên tiếp cho thưởng, tiền trong game cho phép nâng cấp trang bị, chiếm được lãnh thổ cho thêm tài nguyên để chiếm thêm lãnh thổ.

Khi vòng dương quá mạnh, xuất hiện hiện tượng gọi là bài toán người dẫn đầu bỏ xa: một lợi thế sớm tự khuếch đại cho tới khi kết cục của ván chơi trở nên định trước, bất kể người chơi quyết định gì tiếp theo. Jesse Schell gọi đây là một trong những vấn đề cân bằng nghiêm trọng nhất trong thiết kế game. Nó chính là bug thứ ba trong danh sách mở đầu bài viết.

Vòng phản hồi âm là công cụ chữa. Ví dụ nổi tiếng nhất là cơ chế co giãn khoảng cách trong dòng game đua xe của Nintendo, nơi người chơi càng dẫn trước thì càng nhận vật phẩm yếu, còn người tụt lại càng nhận vật phẩm mạnh, và độ thông minh của đối thủ máy cũng thay đổi theo thời gian thực. Trong dòng game chiến lược Civilization, bành trướng quá nhanh bị phạt bằng chi phí duy trì tăng lên.

Nhưng vòng âm quá mạnh cũng có bệnh riêng, và nó nguy hiểm theo cách tinh vi hơn. Quá nhiều phản hồi âm dẫn tới ức chế và cảm giác mất quyền tự quyết. Nếu người chơi nhận ra rằng chơi giỏi không thay đổi được kết quả vì hệ thống luôn kéo họ về giữa, thì họ mất động lực chơi giỏi, và toàn bộ ý nghĩa của kỹ năng sụp đổ.

Cách xử lý được khuyến nghị là lập lịch cho hai loại vòng theo giai đoạn ván chơi. Giai đoạn đầu dùng vòng dương yếu, đủ để tạo cảm giác tiến bộ và thiết lập những mô thức chiếm ưu thế. Giai đoạn giữa dùng vòng âm để giữ cho ván chơi còn mở. Giai đoạn cuối tăng vòng dương trở lại để đẩy nhanh tới kết thúc, vì một ván chơi không kết thúc được cũng tệ như một ván chơi định trước.

Còn một tham số nữa ít được nói tới nhưng có sức mạnh lớn: độ trễ. Chỉ cần thêm một độ trễ vào một vòng phản hồi, dù dương hay âm, là hành vi của cả hệ thống có thể đổi khác hẳn so với khi không có độ trễ. Đây là công cụ tinh chỉnh mà nhiều nhà thiết kế bỏ quên. Cùng một phần thưởng, trả ngay lập tức và trả sau ba mươi giây, tạo ra hai hệ thống hoàn toàn khác nhau.

Hệ thống thứ tư: tiến trình

Hệ thống thứ tư chạy chậm nhất, và cũng vì thế mà khó điều khiển nhất.

Mục tiêu là giữ người chơi trong vùng mà thử thách tương xứng với kỹ năng của họ. Giá trị hiện tại được đo gián tiếp qua tỷ lệ chết, thời gian hoàn thành màn, tỷ lệ bỏ cuộc, tỷ lệ quay lại ngày hôm sau. Bộ điều khiển là nhà thiết kế hoặc một thuật toán điều chỉnh độ khó động. Tác động là thay đổi độ khó, nhịp phần thưởng, hoặc tốc độ mở nội dung mới.

Vấn đề nằm ở độ trễ. Trong camera, độ trễ tính bằng mili giây. Trong tiến trình, nó tính bằng ngày hoặc tuần: người chơi rời game hôm nay, dữ liệu về đến bảng phân tích vài ngày sau, bản vá phát hành vài tuần sau, và hiệu quả của bản vá chỉ đo được sau vài tuần nữa. Một vòng phản hồi với độ trễ lớn như vậy rất dễ rơi vào dao động, tức đội ngũ liên tục điều chỉnh quá tay theo cả hai hướng.

Đây chính là lý do vì sao vận hành game trực tiếp lại là một kỹ năng riêng biệt chứ không phải là phần mở rộng của phát triển game. Nó là công việc điều khiển một hệ thống có độ trễ lớn, và mọi nguyên tắc của lý thuyết điều khiển đều áp dụng: giảm độ lợi khi độ trễ tăng, thay đổi từng bước nhỏ thay vì từng bước lớn, và luôn đo lại trước khi điều chỉnh tiếp.

Điều chỉnh độ khó động là nỗ lực đưa bộ điều khiển vào trong chính game để cắt độ trễ xuống gần bằng không. Nó hiệu quả về mặt kỹ thuật nhưng mang một rủi ro đặc thù: nếu người chơi phát hiện ra hệ thống đang tự động nới lỏng cho họ, thì thành tựu mất hết ý nghĩa. Đây là cùng một vấn đề với vòng phản hồi âm quá mạnh, chỉ ở tầng khác.

Bốn hệ thống, một cấu trúc

Đọc bảng theo hàng thì đây là bốn công việc khác nhau, giao cho bốn vai trò khác nhau. Đọc theo cột thì đây là cùng một bài toán ở bốn thang thời gian.

Ba câu hỏi chẩn đoán dùng được cho cả bốn

Khi một trong bốn hệ thống trên hỏng, ba câu hỏi sau thu hẹp nguyên nhân rất nhanh.

Hệ thống luôn chạy sau, hay đi quá rồi phải quay lại? Chạy sau là độ lợi quá thấp hoặc độ trễ quá lớn. Đi quá là độ lợi quá cao hoặc giảm chấn quá yếu. Hai bệnh này cần hai cách chữa ngược nhau, nên phân biệt được chúng là đã giải quyết được nửa vấn đề.

Sai số đang được đo ở đâu, và đo cách đây bao lâu? Rất nhiều vấn đề tưởng là do bộ điều khiển thực ra do phép đo. Camera bám vào vị trí nhân vật ở khung hình trước, hệ thống cân bằng dùng chỉ số của tuần trước, đội vận hành đọc số liệu của tháng trước. Trong mọi trường hợp, giảm độ trễ đo lường thường hiệu quả hơn nhiều so với chỉnh bộ điều khiển.

Vòng này đang khuếch đại hay đang dập tắt, và đó có phải điều ta muốn không? Đây là câu hỏi hay bị bỏ qua nhất, vì nhiều vòng phản hồi trong game tồn tại mà không ai cố ý tạo ra chúng. Một cơ chế thưởng vô hại có thể vô tình tạo ra vòng dương khiến người chơi mạnh càng mạnh. Một hình phạt hợp lý có thể vô tình tạo ra vòng dương với kết quả xấu, kiểu chết một lần thì mất trang bị, mất trang bị thì dễ chết tiếp.

Vì sao nhận ra một lần là dùng được suốt nghề

Bốn hệ thống trong bài này chỉ là bốn ví dụ dễ thấy nhất. Cùng cấu trúc đó còn xuất hiện ở nhiều chỗ khác trong nghề: hệ thống nhắm bắn có hỗ trợ, nội suy trạng thái mạng khi có độ trễ, tìm đường của trí tuệ nhân tạo khi mục tiêu di chuyển, hệ thống hoạt ảnh pha trộn giữa các tư thế, đường cong âm lượng và hiệu ứng âm thanh động, thậm chí cả quy trình sản xuất của chính studio với vòng lặp dựng bản mẫu, chơi thử, thu phản hồi và tinh chỉnh.

Giá trị thực tế của việc nắm khái niệm này không nằm ở chỗ nó cho lời giải sẵn. Nó nằm ở chỗ nó cho một bộ từ vựng dùng chung, và bộ từ vựng đó biến những cuộc tranh luận mơ hồ thành những cuộc tranh luận cụ thể.

Câu “camera thấy hơi kỳ kỳ” không hành động được. Câu “camera đang vọt lố khi nhân vật đổi hướng đột ngột, cần tăng giảm chấn hoặc giảm độ lợi” thì hành động được ngay. Và điều đáng nói là cùng một câu, với vài từ thay đổi, dùng được cho cả bốn hệ thống trong bài này, bởi bốn người ở bốn vai trò khác nhau, trong cùng một cuộc họp.

Tài liệu tham khảo

1. Adams, Ernest và Dormans, Joris. Game Mechanics: Advanced Game Design, New Riders, 2012. Nguồn nền tảng về vòng phản hồi dương và âm trong nền kinh tế nội tại của game.
   
2. Lazi Akademie, Feedback Loop. Nguồn của bài toán người dẫn đầu bỏ xa, dẫn nhận định của Jesse Schell, và của lịch trình ba giai đoạn cho vòng dương và vòng âm. https://www.lazi-akademie.de/wiki/game-design/grundlagen/feedback-loop/
3. GameDev Gems, Why You NEED To Understand Feedback Loops. Nguồn của lưu ý rằng chữ dương chỉ có nghĩa khuếch đại, kèm ví dụ ván cờ vua và cơ chế co giãn khoảng cách trong game đua xe. https://gamedevgems.com/why-you-need-to-understand-feedback-loops/
4. Game Design Toolkit, Feedback Loops. Nguồn của cảnh báo về việc quá nhiều phản hồi âm gây ức chế và mất quyền tự quyết. https://tkdev.dss.cloud/gamedesign/toolkit/feedback-loops/
   
5. The Video Game Diaries, Feedback Loops in Games. Nguồn của luận điểm về tác động của độ trễ lên hành vi của một vòng phản hồi. https://thevideogamediaries.wordpress.com/2017/09/16/feedback-loops-in-games/
6. Arcade Rage, How Feedback Loops Work in Game Design. Nguồn của ví dụ chi phí duy trì tăng theo tốc độ bành trướng trong Civilization. https://arcaderage.co/2018/02/11/game-design-feedback-loops/
7. Unity, tài liệu API cho Vector3.SmoothDamp. Nguồn của mô tả hàm lò xo giảm chấn và ý nghĩa tham số thời gian làm mượt. https://docs.unity3d.com/6000.2/Documentation/ScriptReference/Vector3.SmoothDamp.html
8. Nexus Stats, CriticallyDampedSpring. Nguồn của luận điểm rằng lò xo giảm chấn tới hạn hội tụ nhanh nhất có thể mà không vọt lố, và của việc theo dõi vận tốc giúp dự đoán thay vì chạy theo sau. https://docs.rs/crate/nexus-stats/latest/source/docs/algorithms/spring.md
9. Phantom Camera, Damping and Smoothing. Ví dụ về cách một hệ thống camera thực tế phơi bày tham số giảm chấn cho nhà thiết kế. https://deepwiki.com/ramokz/phantom-camera/5.6-damping-and-smoothing
10. Swink, Steve. Game Feel: A Game Designer’s Guide to Virtual Sensation, 2009. Nguồn của khái niệm chu trình hiệu chỉnh dưới 100 mili giây. Tóm lược tại https://lizengland.com/blog/review-game-feel-by-steve-swink/