Trong một buổi họp sản xuất, họa sĩ đề xuất thêm một nguồn sáng động cho căn phòng chính. Đề xuất hợp lý, căn phòng đó đang trông phẳng, và ánh sáng sẽ giải quyết vấn đề.
Ở một công ty phần mềm bình thường, câu trả lời sẽ là được hoặc không được, tùy vào thời gian còn lại của sprint. Ở một studio game, câu trả lời là một câu hỏi khác: nó tốn bao nhiêu mili giây, và ta lấy chỗ đó từ đâu.
Đó là toàn bộ khác biệt. Trong ngành game, mọi quyết định kỹ thuật và mỹ thuật đều diễn ra bên trong một ngân sách cố định, không thể vay mượn, và được thanh toán lại từ đầu sáu mươi lần mỗi giây. Bài viết này nói về con số đó, về cách nó lan ra khắp dự án, và về nếp tư duy mà nó tạo ra trong những người làm nghề đủ lâu.
Khái niệm gốc: ràng buộc tài nguyên
Ràng buộc tài nguyên là tình huống trong đó tổng lượng một nguồn lực cố định, và mọi bên sử dụng nó đều cạnh tranh với nhau trên cùng một tổng đó.
Đặc điểm quan trọng nhất của loại ràng buộc này là nó biến mọi quyết định thành quyết định đánh đổi. Không tồn tại phương án thêm mà không bớt. Nếu ai đó nói có, thì ở đâu đó khác phải có một cái không tương ứng, và nếu không ai chỉ ra được cái không đó thì hệ thống sẽ tự tìm ra nó theo cách tệ nhất.
Điểm khác biệt giữa ràng buộc tài nguyên trong game và trong phần lớn phần mềm khác nằm ở tính cứng. Hạn chót dự án là ràng buộc mềm: trễ một tuần thì khó chịu nhưng sản phẩm vẫn chạy. Ngân sách khung hình là ràng buộc cứng: vượt quá là người chơi nhìn thấy ngay, ở đúng khoảnh khắc đó, không có cách nào che giấu.
Con số
Ở mục tiêu 60 khung hình mỗi giây, mỗi khung hình có khoảng 16,67 mili giây để hoàn tất toàn bộ công việc phía CPU gồm logic game, vật lý, trí tuệ nhân tạo và phát lệnh vẽ, cùng toàn bộ công việc phía GPU gồm xử lý đỉnh, quét mành, tô điểm ảnh và hậu kỳ. Ở 30 khung hình, ngân sách nới ra 33,33 mili giây. Ở 144 khung hình, nó siết xuống 6,94 mili giây.
Với thực tế ảo thì khắt khe hơn hẳn. Quest 2 và Quest 3 nhắm tối thiểu 72 khung hình một giây, tức 13,9 mili giây, và lý tưởng là 90 khung hình, tức 11,1 mili giây. Rơi xuống dưới mục tiêu gây ra hiện tượng tái chiếu hình và làm người dùng say, nên ngân sách trong thực tế ảo nghiêm ngặt hơn nhiều so với màn hình phẳng.
Bên trong ngân sách đó lại có ngân sách con. Với 60 khung hình trên di động, cách chia thường gặp là 8 đến 10 mili giây cho CPU, 8 đến 10 mili giây cho GPU, và chừa 2 đến 3 mili giây dự phòng cho việc giảm xung do nhiệt cùng chi phí của hệ điều hành. Một cách phân bổ phổ biến theo hệ thống là 40 phần trăm cho dựng hình, 30 phần trăm cho logic game, 20 phần trăm cho vật lý và hoạt ảnh, 10 phần trăm để dành.
Chú thích: Ngân sách cho một khung hình theo từng mục tiêu. Điểm đáng chú ý là khoảng cách giữa 30 và 60 khung hình lớn hơn nhiều so với giữa 60 và 144, nên nâng mục tiêu từ 30 lên 60 là quyết định tốn kém nhất trong toàn bộ thang này.
Vì sao trung bình không cứu được ai
Đây là điểm mà người mới chuyển từ ngành phần mềm khác sang thường hiểu sai, và cũng là gốc rễ của nếp tư duy đặc trưng trong nghề.
Trong hầu hết hệ thống phần mềm, hiệu năng được đánh giá bằng giá trị trung bình hoặc thông lượng. Một dịch vụ web xử lý trung bình mười nghìn yêu cầu mỗi giây là một dịch vụ tốt, dù thỉnh thoảng có yêu cầu chậm.
Trong game, trung bình gần như vô nghĩa. Cảm giác mượt đến từ độ ổn định của thời gian khung hình chứ không từ con số trung bình. Một game có thể chạy trung bình 120 khung hình mỗi giây, nhưng nếu một khung mất 8 mili giây còn khung kế tiếp mất 40 mili giây thì não người nhận ra cú nhảy đó ngay lập tức.
Phép toán ở đây rất tàn nhẫn. Một khung hình mất 50 mili giây nằm giữa một giây toàn những khung 6,9 mili giây gần như không làm thay đổi tốc độ khung hình trung bình, nhưng người chơi nhìn thấy nó như một cú khựng.
Vì thế ngành dùng những chỉ số khác. Mức thấp 1 phần trăm là trung bình của 1 phần trăm khung hình chậm nhất, và nó phản ánh cảm giác mượt tốt hơn nhiều so với trung bình. Mức thấp 0,1 phần trăm đi sâu hơn, dùng để bắt những cú khựng hiếm nhưng nặng, chẳng hạn khi biên dịch shader hoặc khi nạp dữ liệu lúc di chuyển qua vùng mới.
Có một vài ngưỡng thực dụng đáng nhớ. Nếu mức thấp 1 phần trăm đạt từ 80 phần trăm giá trị trung bình trở lên thì trải nghiệm nhất quán và mượt. Từ 70 đến 80 phần trăm là tốt với vài lần hụt nhẹ. Từ 50 đến 70 phần trăm là thỉnh thoảng thấy giật rõ. Dưới 50 phần trăm là giật thường xuyên. Một cách kiểm tra nhanh khác là nếu phân vị 99 lớn hơn gấp đôi trung vị thì đang có vấn đề nghiêm trọng về khựng hình.
Đọc biểu đồ thời gian khung hình cũng cho biết nguyên nhân. Đường phẳng là nhất quán hoàn hảo. Những đỉnh nhọn đơn lẻ là khựng hoặc nạp dữ liệu. Hình răng cưa xen kẽ nhanh chậm là lỗi nhịp khung hình. Đường dâng lên dần theo thời gian thường là hệ thống bị giảm xung do nhiệt.
Hệ quả văn hóa của tất cả những điều trên là điểm chính của bài viết này: người làm game bị huấn luyện để lo về trường hợp xấu nhất chứ không phải về giá trị trung bình. Câu hỏi thường trực trong đầu họ không phải là hệ thống này chạy nhanh không, mà là hệ thống này chậm nhất bao nhiêu, khi nào, và điều gì xảy ra lúc đó.
Chú thích: Công cụ đo là thứ đầu tiên một studio nghiêm túc thiết lập. Không phải để biết game chạy nhanh bao nhiêu, mà để biết nó chậm nhất bao nhiêu và vào lúc nào.
Ngân sách lan ra khắp dự án
Ngân sách thời gian là ngân sách gốc, nhưng nó đẻ ra một loạt ngân sách con mà cả những người không viết dòng code nào cũng phải làm việc với chúng.
Ngân sách đa giác. Con số phụ thuộc mạnh vào nền tảng và loại tài nguyên. Nhân vật chính trên di động thường nằm trong khoảng 1.500 đến 5.000 tam giác, còn trên console và PC thì khoảng 15.000 đến 50.000. Vật thể trang trí trong môi trường thường từ 500 đến 5.000 trên console, và chỉ 100 đến 800 trên di động. Với toàn cảnh, một điểm khởi đầu hợp lý trên di động là khoảng 50.000 tam giác hiển thị cùng lúc, rồi đo và điều chỉnh theo thiết bị đích.
Cách phân bổ thường được diễn đạt theo phần trăm thay vì theo con số tuyệt đối, chẳng hạn môi trường lấy 50 phần trăm ngân sách đa giác, nhân vật lấy 25 phần trăm, và hiệu ứng lấy 25 phần trăm còn lại. Cách này bền hơn vì khi tổng ngân sách đổi thì tỷ lệ vẫn giữ nguyên.
Ngân sách lệnh vẽ. Đây mới là chỗ game thực sự khựng. Một kế hoạch thực dụng là giữ tổng số tam giác trong một khung hình khoảng 100.000 đến 300.000 trên di động và vài triệu trên máy để bàn, nhưng giới hạn số lệnh vẽ dưới 100 trên di động và vài trăm trên máy để bàn.
Ví dụ minh họa rất rõ. Một màn chơi rải 500 chiếc thùng gỗ, mỗi chiếc 800 tam giác, tổng cộng 400.000 tam giác, hoàn toàn nằm trong ngân sách hình học. Nhưng nếu không gộp, 500 chiếc thùng đó tạo ra 500 lệnh vẽ và bóp nghẹt CPU di động. Với kỹ thuật vẽ theo thể hiện, 500 chiếc thùng trở thành một lệnh vẽ duy nhất với cùng chi phí hình học.
Ngân sách theo khung hình cho thực tế ảo. Quest 1 nằm ở mức 350 nghìn đến 500 nghìn tam giác mỗi khung hình, Quest 2 và Quest Pro ở mức 750 nghìn đến một triệu, Quest 3 và 3S ở mức 1,3 đến 1,8 triệu, còn thực tế ảo nối máy tính ở mức 1 đến 2 triệu tam giác và 500 đến 1.000 lệnh vẽ mỗi khung hình.
Ngoài ra còn ngân sách bộ nhớ kết cấu bề mặt, ngân sách băng thông mạng cho game trực tuyến, ngân sách dung lượng tải về cho game di động, và trên thiết bị cầm tay còn có ngân sách pin và ngân sách nhiệt.
Điểm chung của tất cả là chúng đều được chia từ trên xuống, đều là tổng bằng không, và đều buộc từng người trong đội phải biết mình đang tiêu vào ngân sách nào.
Bốn nếp tư duy đặc trưng của nghề
Sống lâu trong môi trường này tạo ra một số thói quen suy nghĩ khá dễ nhận ra.
Nếp thứ nhất: mọi tính năng đều có giá, và giá đó trả bằng tính năng khác. Trong ngành game, câu hỏi đúng không bao giờ là tính năng này có tốt không, mà là tính năng này tốt hơn thứ mà nó sẽ thay thế hay không. Một đề xuất không đi kèm câu trả lời cho câu hỏi lấy từ đâu thì chưa phải một đề xuất hoàn chỉnh.
Nếp thứ hai: đo trước, đoán sau. Trực giác về hiệu năng gần như luôn sai, kể cả với người rất giỏi. Trình tự chuẩn là dịch tốc độ khung hình mục tiêu thành ngân sách mili giây, rồi đo dòng thời gian của CPU và GPU để biết bên nào đang quyết định thời gian khung hình, rồi chia ngân sách theo hệ thống và cắt những phần nặng nhất trước, rồi xác minh bằng công cụ ghi hình trên thiết bị thật chứ không phải trong trình soạn thảo. Đo trong trình soạn thảo bị nhiễu bởi chính chi phí của trình soạn thảo và cho ra con số sai lệch.
Nếp thứ ba: ám ảnh trường hợp xấu nhất. Đã bàn ở trên, và nó ăn sâu tới mức thành phản xạ. Khi một người làm game nhìn một biểu đồ, mắt họ đi tìm đỉnh nhọn chứ không tìm đường trung bình.
Nếp thứ tư: ngân sách phải được công bố sớm và cho cả nhóm. Đây là nếp có hệ quả tổ chức lớn nhất và cũng hay bị bỏ qua nhất. Trong game, họa sĩ và nhà thiết kế màn chơi phải hiểu ràng buộc kỹ thuật ở mức con số, không phải ở mức cảm giác. Không nắm được ràng buộc của phần cứng thì việc tạo ra tài nguyên phù hợp là bất khả thi. Đây là điểm khiến vai trò họa sĩ game khác hẳn họa sĩ ở các ngành sáng tạo khác: sản phẩm của họ bị đánh giá đồng thời bằng thẩm mỹ và bằng số mili giây.
Một studio công bố ngân sách từ đầu sẽ có những cuộc tranh luận về đánh đổi trong giai đoạn thiết kế. Một studio giấu ngân sách trong đầu vài lập trình viên sẽ có những cuộc tranh luận đó ở giai đoạn tối ưu, khi mọi thứ đã làm xong và việc cắt bỏ đắt gấp mười lần.
Ràng buộc không biến mất, nó chỉ đổi tên
Có một luận điểm đang phổ biến rằng phần cứng và công nghệ mới đã xóa bỏ ngân sách. Tài liệu của Epic về Nanite phát biểu khá thẳng rằng ngân sách khung hình không còn bị ràng buộc bởi số đa giác, số lệnh vẽ hay bộ nhớ lưới nữa.
Điều đó đúng trong phạm vi của nó và sai nếu hiểu rộng ra. Ràng buộc không biến mất, nó dịch chuyển sang những tài nguyên khác.
Trên di động, kẻ giết chết hiệu năng thật sự không phải số tam giác mà là hiện tượng vẽ chồng, tức các bề mặt trong suốt được vẽ đè lên nhau nhiều lớp. Một nhân vật hai nghìn tam giác kèm một hiệu ứng hạt nhiều lớp có thể tốn hơn nhiều so với hình học của cả cảnh. Bên cạnh đó còn có độ phức tạp của shader và giới hạn tốc độ lấp đầy điểm ảnh.
Và ràng buộc vật lý cuối cùng thì không thể lập trình để tránh. Trên thiết bị cầm tay, việc giảm xung do nhiệt làm giảm hiệu năng bền vững từ 30 đến 50 phần trăm. Nghĩa là con số mà một máy đo được trong ba mươi giây đầu không phải là con số mà nó giữ được sau hai mươi phút chơi, và ngân sách thật phải lập theo con số thứ hai.
Bài học tổng quát đáng ghi nhớ: ràng buộc tài nguyên là bất biến của nghề. Cái duy nhất thay đổi qua các thế hệ phần cứng là tên của tài nguyên đang khan hiếm nhất. Người nào chỉ học thuộc con số sẽ lỗi thời sau mỗi thế hệ máy. Người nào học được cách tư duy theo ngân sách sẽ áp dụng được nó lên bất kỳ tài nguyên nào xuất hiện tiếp theo.
Chú thích: Nhiệt là ràng buộc mà không dòng code nào lách được. Trên thiết bị cầm tay, hiệu năng bền vững sau khi máy nóng lên thấp hơn hiệu năng lúc mới bật từ 30 đến 50 phần trăm, và ngân sách thật phải lập theo con số bền vững đó.
Lập ngân sách trong thực tế: năm bước
Bước một: chọn thiết bị đích thấp nhất mà game phải chạy được, không phải máy của lập trình viên. Đây là quyết định quan trọng nhất và cũng là quyết định tốn kém nhất khi đổi về sau, vì nó chi phối mọi con số phía dưới.
Bước hai: dịch mục tiêu tốc độ khung hình thành mili giây và trừ ngay phần dự phòng. Nếu mục tiêu là 60 khung hình trên di động, đừng lập kế hoạch cho 16,67 mili giây mà lập cho khoảng 14 mili giây, chừa lại phần cho nhiệt và cho hệ điều hành.
Bước ba: chia ngân sách theo hệ thống và ghi ra thành văn bản mà cả nhóm đọc được. Bảng phân bổ theo phần trăm bền hơn bảng con số tuyệt đối.
Bước bốn: đo trên thiết bị thật, đo bằng thời gian khung hình chứ không bằng tốc độ khung hình, và đo cả phân vị chứ không chỉ trung bình. Khi báo cáo mức cải thiện, dùng mili giây, vì đó là con số tuyệt đối luôn mang cùng ý nghĩa. Nếu muốn nhắc tới mức tăng tốc độ khung hình thì luôn nêu rõ từ giá trị nào lên giá trị nào, vì cùng một số khung hình tăng thêm mang ý nghĩa hoàn toàn khác ở các mức khác nhau.
Bước năm: đo lại sau mỗi cột mốc, không phải chỉ ở cuối dự án. Ngân sách bị tiêu dần một cách âm thầm, mỗi lần một ít, và nếu chỉ kiểm tra vào tháng cuối thì việc tìm ra ai đã tiêu chỗ nào gần như bất khả thi.
Vì sao nếp tư duy này đáng học kể cả khi không làm game
Kết lại bằng một nhận xét vượt ra ngoài phạm vi ngành.
Phần lớn kỹ sư phần mềm được huấn luyện trong môi trường mà tài nguyên co giãn được. Máy chủ chậm thì thêm máy chủ. Bộ nhớ thiếu thì nâng cấu hình. Trong môi trường đó, câu hỏi lấy từ đâu hiếm khi được đặt ra, và kỹ năng đánh đổi ít có dịp phát triển.
Người làm game không có lựa chọn đó. Họ sống trong một hệ thống nơi tổng cố định, nơi mọi cái được đều kéo theo một cái mất, và nơi việc từ chối một ý tưởng hay không phải là thiếu tầm nhìn mà là điều kiện để những ý tưởng hay khác tồn tại được.
Đó là một dạng kỷ luật hiếm, và nó chuyển được sang gần như mọi lĩnh vực khác: quản lý sản phẩm, phân bổ ngân sách, thậm chí quản lý thời gian cá nhân. Người quen tư duy theo ngân sách sẽ luôn hỏi cái này lấy chỗ của cái gì, và câu hỏi đó thường có giá trị hơn nhiều so với câu hỏi cái này có tốt không.
Tài liệu tham khảo
- Game Dev Cheat Sheet, Frame Budget Calculator for Unity Game Development. Nguồn của cách chia CPU và GPU trên di động, phần dự phòng, ngân sách VR cho Quest, và tỷ lệ 40, 30, 20, 10. https://gamedevcheatsheet.com/frame-budget
- Generalist Programmer, Game Optimization: Performance Guide for 60+ FPS. Nguồn của các mốc 16,67, 33,33 và 6,94 mili giây, và của phần về vẽ chồng trên di động. https://generalistprogrammer.com/tutorials/game-optimization-complete-performance-guide-2025
- PulseGeek, What Is a Frame Time Budget in Optimization. Nguồn của quy trình bốn bước đo và phân bổ ngân sách. https://pulsegeek.com/articles/what-is-a-frame-time-budget-in-optimization/
- Polyphantom Creations, Don’t Use Frames to Measure Performance. Nguồn của lập luận vì sao nên báo cáo bằng mili giây thay vì bằng số khung hình. https://medium.com/@polyph4ntom/dont-use-frames-to-measure-performance-bef66c4f4214
- Tier1Settings, What Are 1% Lows? Why Frametimes Matter More Than Average FPS. Nguồn của ví dụ một khung 50 mili giây giữa những khung 6,9 mili giây. https://tier1settings.com/what-are-1-percent-lows-in-gaming/
- The FPS Tester, Understanding Frame Time: Why Average FPS Lies to You. Nguồn của bảng ngưỡng tỷ lệ giữa mức thấp 1 phần trăm và trung bình, cùng cách đọc hình dạng biểu đồ thời gian khung hình. https://thefpstester.com/articles/understanding-frame-time
- Klartext Tools, Frametime Variance Analyzer. Nguồn của ngưỡng phân vị 99 gấp đôi trung vị và cách phân biệt nguyên nhân theo hình dạng phân bố. https://klartext-tools.com/en/gaming-tools/frametime-variance-analyzer/
- Triverse, Low Poly vs High Poly. Nguồn của ngân sách lệnh vẽ và ví dụ 500 chiếc thùng gỗ. https://triverse.ai/blog/low-poly-vs-high-poly
- Neural4D, Polygon Count for 3D Game Assets, Printing, and WebAR. Nguồn của bảng ngân sách đa giác theo nền tảng và của luận điểm vẽ chồng nguy hiểm hơn số tam giác. https://blog.neural4d.com/user-guide/polygon-count-for-3d-game-assets-printing-and-webar/
- Design Your Way, What Is Low Poly Art. Nguồn của ngân sách tam giác mỗi khung hình cho các đời Quest và của phát biểu từ tài liệu Nanite về việc ngân sách không còn bị ràng buộc bởi số đa giác. https://www.designyourway.net/blog/low-poly-art/
0 Lời bình