Bổ Sung Thêm Về Quản Lý Tài Nguyên Trong Game
Gần đây, qua thực tiễn, tôi đã xác nhận được một số suy nghĩ trước đây của mình về quản lý tài nguyên. Luôn là niềm vui khi phát hiện ra những giả định của bản thân là chính xác.
Tổng quan lại những bài viết trước đây:
Quản lý bộ nhớ tài nguyên và tiền tải đa luồng
Đây không phải là ý tưởng đầu tiên tôi nhen nhóm, nhưng là bài viết đầu tiên tôi công khai trên blog và đưa vào thực hành. Một số nội dung trong đó, đặc biệt phần thiết kế đa luồng, sau này đã được thay thế vì quá phức tạp và không đáp ứng đủ yêu cầu. Một số chi tiết khó ổn định khi triển khai.
Tiếp nối suy nghĩ lung tung
Sau nhiều suy ngẫm và trải nghiệm thực tế, tôi đã xác nhận lại phần nào những điều trước đây. Điều được khẳng định là chiến lược tổng thể trong quản lý tài nguyên là đúng đắn: đó là tách biệt hoàn toàn với các hệ thống khác, đặc biệt là logic game. Vòng đời tài nguyên không nên phụ thuộc vào logic game.
Tái cấu trúc
Đây là bài viết gần nhất tôi chia sẻ về chủ đề này. Điểm quan trọng nhất rút ra là:
Với việc module tài nguyên giờ đây nắm rõ mối liên hệ giữa các file dữ liệu, ta có thể đơn giản mở một luồng riêng để “chạm nhẹ” (touch) vào những file có khả năng được dùng trong tương lai. Việc tiền tải và đệm dữ liệu hãy để hệ điều hành lo. Đây là một thiết kế gọn nhẹ và hiệu quả, không cần quá lo lắng về an toàn luồng.
Vậy hôm nay muốn nói gì?
Chỉ vì một sơ suất nhỏ, trong chương trình mới nhất, chúng tôi đã đặt ngưỡng giới hạn bộ nhớ của module quản lý tài nguyên ở mức 6MB. Điều đó có nghĩa là bất cứ khi nào lượng dữ liệu vượt quá 6MB, module sẽ tự động dọn dẹp những dữ liệu không cần thiết. Ban đầu, chúng tôi định đặt ngưỡng cao hơn, nhưng vì muốn nhanh chóng phát hiện lỗi nên đã cố ý giảm xuống để module hoạt động thường xuyên hơn.
Kết quả thu được khiến chúng tôi ngạc nhiên. Khi chạy một client với cảnh game phức tạp, theo dõi qua trình quản lý của hệ điều hành, bộ nhớ tiêu thụ vẫn ổn định ở mức 36MB! Ban đầu, cả nhóm còn không dám tin vì engine 3D riêng đã ngốn khoảng 30MB. Nhưng hóa ra, chỉ cần 6MB cho dữ liệu tài nguyên là đủ. (Game 3D tiết kiệm bộ nhớ hơn game 2D ở điểm này).
Tại sao client vẫn mượt mà bất chấp việc giới hạn như vậy? Có lẽ nhờ cơ chế cache thông minh của hệ điều hành. Hơn nữa, máy thử nghiệm có tới 2GB RAM nên gần như không xảy ra thao tác đọc đĩa cứng.
Khi chúng tôi nâng ngưỡng lên 128MB, client nhanh chóng chiếm trọn khoảng trống được cấp, nhưng trải nghiệm không cải thiện đáng kể. Thậm chí, nếu mở nhiều chương trình tương tự cùng lúc, chúng sẽ cạnh tranh RAM gay gắt.
Với dữ liệu thực tế này, những ý tưởng gần đây tôi viết về trình chỉnh sửa bản đồ trở nên ứng dụng thực tế hơn. Thực tế, chính client nói trên là một công cụ quan sát tạm thời chúng tôi xây dựng để kết nối với editor server (Chỉ một lập trình viên viết trong một ngày dựa theo tài liệu giao thức. Lưu ý: hiện tại chỉ mới định nghĩa giao thức, chưa có thư viện SDK chung). Người dùng có thể kết nối vào server để di chuyển trong cảnh game đang được sửa, thậm chí xem trực tiếp những thay đổi của đồng nghiệp.
Theo ý tưởng của tôi, nếu các họa sĩ muốn theo dõi toàn cảnh trong khi chỉnh sửa hoặc quan sát khu vực từ góc khác, họ chỉ cần khởi động thêm một công cụ quan sát, điều chỉnh góc nhìn phù hợp rồi “gắn” lên góc màn hình.
Việc tiêu tốn ít RAM và CPU khiến chuyện này trở nên tiện lợi. Bên cạnh đó, hiện tại trình editor của chúng tôi lấy toàn bộ tài nguyên qua mạng, nhưng vẫn hoạt động mượt mà trên mạng LAN 100Mbps, tạo điều kiện cho nhiều người làm việc đồng thời.
Editor server lưu trữ toàn bộ quy trình làm việc của nhóm mỹ thuật. Khi dự án kết thúc, tôi dự định sẽ làm một video trình diễn quá trình từ vô đến hữu của thế giới game ảo.
Lưu ý: Đã kiểm tra kỹ lưỡng, đảm bảo không còn ký tự không phải tiếng Việt.