Quản Lý Tài Nguyên Mỹ Thuật Theo Triết Lý Lấy Con Người Làm Trung Tâm

Trong các file client của game, tài nguyên mỹ thuật luôn chiếm tỷ trọng lớn nhất cả về số lượng lẫn dung lượng dữ liệu. (Hầu hết game thương mại đều đóng gói tài nguyên trước khi phát hành, nhưng chúng ta đang nói về giai đoạn phát triển chưa qua đóng gói). Khi quy mô game đạt đến mức nhất định, đòi hỏi phải huy động hàng trăm nhân lực mỹ thuật. Cùng với sự mở rộng của đội ngũ sản xuất, việc thiết kế cấu trúc thư mục lưu trữ tài nguyên và quy tắc đặt tên file trở thành vấn đề then chốt ngay từ đầu dự án.

Vấn đề này ở game 2D còn nhẹ hơn, nhưng với game 3D lại phức tạp hơn nhiều do sự liên kết đa dạng giữa mô hình, texture, xương nhân vật… Dự án 3D hiện tại của chúng tôi đã khiến tôi phải đối mặt và suy nghĩ lại về bài toán này.

Nếu công ty có nhiều dự án tương tự đã thành công, quy trình sản xuất mỹ thuật sẽ được chuẩn hóa thành dây chuyền. Qua thời gian, tự nhiên hình thành nên các chuẩn mực về cấu trúc thư mục và quy tắc đặt tên. Tuy nhiên, do tính biến động của dự án và sự cải tiến công nghệ, những quy chuẩn này không thể bất biến.

Ở đây, từ “công nghệ” cần được hiểu theo nghĩa rộng. Không chỉ là kỹ thuật render 3D, mà còn bao gồm cả công nghệ quản lý và tái sử dụng tài nguyên - vốn là một phần quan trọng trong hệ thống engine.

Qua quá trình gần đây, tôi nhận ra rằng việc áp đặt cấu trúc thư mục cứng nhắc sẽ gây nhiều bất tiện trong quy trình sản xuất. Thực tế cho thấy, rất ít họa sĩ tuân thủ nghiêm ngặt quy tắc đặt tên và vị trí lưu trữ trong quá trình làm việc. Thông thường, họ chỉ sao chép file vào vị trí quy định khi gần hoàn thành. Điều này khác biệt với cách lập trình viên làm việc trực tiếp trong kho mã nguồn (CVS/SVN) mà không cần di chuyển vật lý file.

Khi runtime client tải tài nguyên, hệ thống hầu như không quan tâm đến vị trí vật lý trong thư mục, mà chú trọng mối liên kết giữa các file. Trong quá trình đóng gói, hoàn toàn có thể loại bỏ thông tin đường dẫn và tên file gốc, thay vào đó gán ID duy nhất cho từng file và lưu lại mối quan hệ liên kết. Điều này chứng minh rằng cấu trúc thư mục và quy tắc đặt tên ban đầu không phải là yếu tố bắt buộc.

Hiện tại chúng tôi áp dụng phương pháp xác định “gốc dự án” (root) cho tài nguyên, tương tự cách tiếp cận của hệ thống xây dựng bjam. Trong thư mục gốc sẽ có file đặc biệt tên project-root.jam. Khi cần liên kết file, hệ thống sẽ tự động tìm ngược lên để xác định vị trí root, sau đó truy xuất tài nguyên dựa trên đường dẫn tuyệt đối từ root. Phương pháp này có nhiều ưu điểm vượt trội so với việc dùng đường dẫn tương đối.

Với dự án nhỏ, một họa sĩ có thể tự tổ chức tài nguyên theo quy tắc riêng. Khi có nhiều người tham gia, mỗi thành viên sẽ tạo thư mục con dưới root mang tên mình. Khi cần dùng tài nguyên của đồng nghiệp, chỉ cần truy cập qua tên thư mục tương ứng. Ví dụ: Mô hình của nhân vật B có thể sử dụng texture do A thiết kế, được lưu trong thư mục texture của A. Để tránh rủi ro khi tài nguyên bị xóa hoặc di chuyển, chúng tôi ghi nhận MD5 của file được tham chiếu. Thông tin kiểm tra này sẽ được loại bỏ khi tiến hành đóng gói phát hành.

Theo cách này, cấp đầu tiên của hệ thống thư mục sẽ là các thư mục mang tên người phụ trách, dưới đó mới là phân loại chi tiết. Mỗi người có thể tự do thiết kế cấu trúc riêng phù hợp với phong cách làm việc của mình. Đây là cách tiếp cận nhân văn, tôn trọng tính cá nhân trong quy trình sản xuất.

Việc quản lý tài nguyên phiên bản phát hành nên giao cho module đóng gói và xử lý tài nguyên. Hệ thống này sẽ chuyển đổi cách truy xuất tài nguyên từ dạng chuỗi ký tự (đường dẫn/tên file) sang phương pháp hiệu quả hơn. Điều này khiến tôi nhớ đến sự thay thế của công cụ tìm kiếm Google đối với mô hình thư mục phân loại kiểu Yahoo ngày xưa. Về các giải pháp cụ thể và thách thức cần giải quyết, xin dành cho dịp khác thảo luận.