Làm thế nào để thiết kế một AssetManager?

Cách tiếp cận tốt nhất để thiết kế AssestManager sẽ chứa các tham chiếu đến đồ họa, âm thanh, v.v. của trò chơi là gì?

Những tài sản này có nên được lưu trữ trong cặp khóa / giá trị Bản đồ không? Tức là tôi yêu cầu tài sản "nền" và Bản đồ trả về bitmap liên quan? Có cách nào tốt hơn không?

Cụ thể tôi đang viết một trò chơi Android / Java, nhưng câu trả lời có thể chung chung.

Nó phụ thuộc vào phạm vi trò chơi của bạn. Một người quản lý tài sản là hoàn toàn cần thiết cho các tiêu đề lớn hơn, ít hơn cho các trò chơi nhỏ hơn.

Đối với các tiêu đề lớn hơn, bạn phải quản lý các vấn đề như sau:

• Tài sản được chia sẻ - là kết cấu gạch đang được sử dụng bởi nhiều mô hình?
• Tuổi thọ tài sản - tài sản bạn đã tải 15 phút trước không còn cần thiết nữa? Tham chiếu đếm tài sản của bạn để đảm bảo bạn biết khi nào một cái gì đó kết thúc với vv
• Trong DirectX 9 nếu một số loại tài sản nhất định được tải và thiết bị đồ họa của bạn bị 'mất' (điều này xảy ra nếu bạn nhấn Ctrl + Alt + Del trong số những thứ khác) - trò chơi của bạn sẽ cần tạo lại chúng
• Đang tải tài sản trước khi cần chúng - bạn không thể xây dựng các trò chơi thế giới mở lớn mà không có điều này
• Tải tài sản hàng loạt - Chúng tôi thường đóng gói rất nhiều tài sản vào một tệp để cải thiện thời gian tải - việc tìm kiếm xung quanh đĩa rất tốn thời gian

Đối với các tiêu đề nhỏ hơn, những điều này không phải là vấn đề, các khung như XNA có người quản lý tài sản bên trong chúng - có rất ít điểm trong việc phát minh lại nó.

Nếu bạn thấy mình cần một người quản lý tài sản, thực sự không có giải pháp nào phù hợp với một kích thước, nhưng tôi đã thấy rằng một bản đồ băm với khóa là hàm băm * của tên tệp (được hạ thấp và phân tách tất cả 'cố định') hoạt động tốt cho các dự án tôi đã làm việc.

Thông thường không nên dùng tên mã hóa cứng trong ứng dụng của bạn, thường tốt hơn là có định dạng dữ liệu khác (chẳng hạn như xml) mô tả tên tệp thành 'ID'.

• Là một lưu ý phụ thú vị, bạn thường nhận được một xung đột băm cho mỗi dự án.

(Cố gắng tránh "không sử dụng người quản lý tài sản" -discussion ở đây, vì tôi coi đó là điều không chính đáng.)

Bản đồ khóa / giá trị là một cách tiếp cận rất có thể sử dụng.

Chúng tôi có một triển khai ResourceManager nơi các nhà máy cho các loại tài nguyên khác nhau có thể đăng ký.

Phương thức "getResource" sử dụng các mẫu để tìm Nhà máy chính xác cho nguồn lực mong muốn và trả về một ResourceHandle cụ thể (một lần nữa sử dụng mẫu để trả về một SpecResourceHandle).

Các tài nguyên được Resourcemanager (bên trong ResourceHandle) giới thiệu và phát hành khi không cần thiết nữa.

Addon đầu tiên chúng tôi viết là phương thức "tải lại (XYZ)", cho phép chúng tôi thay đổi tài nguyên từ bên ngoài công cụ đang chạy mà không thay đổi bất kỳ mã hoặc tải lại trò chơi. (Điều này rất cần thiết khi các nghệ sĩ làm việc trên bảng điều khiển;))

Hầu hết thời gian chúng tôi chỉ có phiên bản của Trình quản lý tài nguyên, nhưng đôi khi chúng tôi tạo một phiên bản mới chỉ cho một cấp độ hoặc bản đồ. Bằng cách này, chúng tôi chỉ có thể gọi "tắt máy" trên levelResourceManager và đảm bảo không có gì bị rò rỉ.

(tóm tắt) ví dụ

// very abbreviated!
// this code would never survive our coding guidelines ;)

ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0

pRm->releaseResource( pRm );

// [...]
pRm->shutdown(); // will log any leaked resource

Các lớp Manager dành riêng hầu như không bao giờ là công cụ kỹ thuật phù hợp. Nếu bạn chỉ cần tài sản một lần (như nền hoặc bản đồ), bạn chỉ nên yêu cầu một lần và để nó chết bình thường khi bạn hoàn thành nó. Nếu bạn cần lưu trữ một loại đối tượng cụ thể, bạn nên sử dụng một nhà máy trước tiên kiểm tra bộ đệm và tải một cái gì đó, đặt nó vào bộ đệm và sau đó trả về nó - và nhà máy đó có thể chỉ là một hàm tĩnh truy cập vào một biến tĩnh , không phải là một loại của riêng nó.

Steve Yegge (trong số nhiều người, nhiều người khác) đã viết một câu chuyện hay về cách các lớp quản lý vô dụng, bằng cách mô hình singleton, cuối cùng trở thành. http://sites.google.com.vn/site/steveyegge2/singleton-considered-stool

Tôi đã luôn nghĩ rằng một người quản lý tài sản tốt nên có nhiều chế độ hoạt động. Các chế độ này rất có thể là các mô-đun nguồn riêng biệt tuân thủ một giao diện chung. Hai chế độ hoạt động cơ bản sẽ là:

• Chế độ sản xuất - tất cả tài sản là cục bộ và tước bỏ tất cả dữ liệu meta
• Chế độ phát triển - các thử nghiệm được lưu trữ trong cơ sở dữ liệu (ví dụ: MySQL, v.v.) với dữ liệu meta bổ sung. Cơ sở dữ liệu sẽ là một hệ thống hai lớp với cơ sở dữ liệu cục bộ lưu trữ cơ sở dữ liệu dùng chung. Người tạo nội dung sẽ có thể chỉnh sửa và cập nhật cơ sở dữ liệu được chia sẻ và các bản cập nhật được tự động chuyển sang hệ thống nhà phát triển / QA. Nó cũng có thể tạo nội dung giữ chỗ. Vì mọi thứ đều nằm trong cơ sở dữ liệu, các truy vấn có thể được thực hiện trên cơ sở dữ liệu và các báo cáo được tạo để phân tích trạng thái của sản xuất.

Bạn sẽ cần một công cụ có thể lấy tất cả các thử nghiệm từ cơ sở dữ liệu được chia sẻ và tạo bộ dữ liệu sản xuất.

Trong những năm làm nhà phát triển, tôi chưa bao giờ thấy bất cứ điều gì như thế này, mặc dù tôi chỉ làm việc cho một số ít các công ty nên quan điểm của tôi không thực sự đại diện.

Cập nhật

OK, một số phiếu tiêu cực. Tôi sẽ mở rộng về thiết kế này.

Thứ nhất, bạn không thực sự cần các lớp học vì nếu bạn có:

TextureHandle tex = pRm->getResource<Texture>( "test.otx" );

bạn biết loại, vì vậy chỉ cần làm:

TextureHandle tex = new TextureHandle ("test.otx");

nhưng sau đó, điều tôi đã cố gắng nói ở trên là dù sao bạn cũng sẽ không sử dụng tên tệp rõ ràng, kết cấu cần tải sẽ được chỉ định bởi mô hình mà kết cấu được sử dụng, vì vậy bạn thực sự không cần tên người đọc được, nó có thể là một giá trị nguyên 32 bit, giúp CPU xử lý dễ dàng hơn nhiều. Vì vậy, trong hàm tạo cho TextureHandle, bạn có:

if (texture already loaded)
  update texture reference count
else
  asset_stream = new AssetStream (resource_id)
  asset_stream->ReadBytes
  create texture
  set texture ref count to 1

AssetStream sử dụng tham số resource_id để tìm vị trí của dữ liệu. Cách thức thực hiện việc này sẽ phụ thuộc vào môi trường bạn đang chạy:

Trong Phát triển: luồng tìm kiếm ID trong cơ sở dữ liệu (ví dụ sử dụng SQL) để lấy tên tệp và sau đó mở tệp, tệp có thể được lưu trữ cục bộ hoặc được kéo từ máy chủ nếu tệp cục bộ không tồn tại hoặc là hết hạn.

Trong Bản phát hành: luồng tìm kiếm ID trong bảng khóa / giá trị để lấy phần bù / kích thước thành một tệp lớn, được đóng gói (như tệp WAD của Doom).

Những gì tôi muốn làm cho tài sản là để thiết lập một người quản lý một lần . Lấy cảm hứng từ công cụ Doom, các khối là các phần dữ liệu chứa tài sản, được lưu trữ trong một tệp cục khai báo tên, độ dài, loại (bitmap, âm thanh, đổ bóng, v.v.) và loại nội dung (tệp, một khối khác, bên trong các tập tin cục bộ). Khi khởi động, các khối này được nhập vào cây nhị phân, nhưng chưa được tải. Mỗi bản đồ (cũng là một cục) có một danh sách các phụ thuộc, đơn giản là tên của các khối mà bản đồ cần để hoạt động. Các cục này, trừ khi chúng đã được tải, được tải tại thời điểm bản đồ được tải. Ngoài ra, các khối bản đồ liền kề của bản đồ được tải, không chỉ cùng một lúc, nhưng khi động cơ không hoạt động vì một số lý do. Điều này có thể làm cho các bản đồ liền mạch, và không có màn hình tải.

Phương pháp của tôi là hoàn hảo cho các bản đồ thế giới mở, nhưng một trò chơi dựa trên cấp độ sẽ không được hưởng lợi từ sự liền mạch mà phương pháp này mang lại cho bạn. Hi vọng điêu nay co ich!