Tại sao sử dụng tệp kê khai tài sản?


11

Đôi khi, bạn sẽ thấy mọi người khuyên bạn thay vì sử dụng tệp đồ họa / âm thanh / v.v. như thế này...

// Game code
Image myImage = new Image("path/to/image.png");

... bạn nên sử dụng một bảng kê khai như một mức độ không xác định thay thế:

// Manifest file
MY_IMAGE: path/to/image.png

// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");

Những lý do nào tôi sẽ có cách tiếp cận này? Nếu tôi không sử dụng ngôn ngữ được biên dịch, liệu có còn lý do để làm điều này không?

Câu trả lời:


8

Hầu hết các tệp kê khai thời gian được liên kết với một số loại định dạng tệp lưu trữ. Chẳng hạn, một tệp JAR trong java chỉ đơn giản là một tệp zip với tệp kê khai liệt kê các tài sản trong tệp zip và nơi tìm thấy chúng. Trong trường hợp đó, "path / to / image.png" không phải là đường dẫn hệ thống tập tin thực sự mà thay vào đó là thông tin về cách tìm đối tượng trong kho lưu trữ nén. Ngoài lợi thế về không gian đĩa của việc nén, sử dụng kho lưu trữ tệp có thể cải thiện hiệu suất vì các cửa sổ có thời gian rất khó xử lý với hàng chục ngàn tệp riêng lẻ trong một số lượng nhỏ thư mục.

Bằng cách sử dụng một tệp kê khai của loại này, bạn hoàn toàn có thể trừu tượng nơi một khối dữ liệu nhất định đến từ. Có thể tệp của bạn nằm trên đĩa DVD hoặc phát trực tuyến trên internet hoặc bên trong tệp zip. Bạn sẽ phải viết một số mã bổ sung để xử lý các trường hợp này, nhưng bằng cách sử dụng tệp kê khai, logic trò chơi của bạn không phải quan tâm đến tất cả những thứ được tải từ đâu.

Bây giờ, nếu bạn đang sử dụng ngôn ngữ chưa được biên dịch, tệp kê khai này chắc chắn có thể là tệp nguồn C #, nhưng thật tuyệt nếu bạn có thể dễ dàng sửa đổi tệp kê khai nào bạn đang sử dụng tại thời điểm thực hiện ứng dụng khách dựa trên cài đặt đăng ký hoặc một cái gì đó tương tự. Chẳng hạn, bạn có thể kiểm tra trong khi thực hiện để xem có tồn tại bộ đệm trên ổ cứng không, hoặc chỉ có DVD. Sau đó, bạn có thể chuyển đổi bảng kê khai để sử dụng tùy thuộc vào thiết lập có sẵn.


Tôi có thể thấy sự cần thiết phải trừu tượng hóa các vị trí tệp trong các tình huống phức tạp nhưng chỉ cần tìm nạp các tệp từ kho lưu trữ zip không cần phải có bảng kê khai vì tên tệp và đường dẫn được lưu giữ trong kho lưu trữ.
Alex Jasmin

4

Một lý do: lập trình hướng dữ liệu.

Mã của bạn có thể chỉ muốn biết nó cần một kết cấu "LightWood" và cho phép người quản lý tài nguyên sử dụng khóa này để tìm đúng đường dẫn đến tệp. Hơn nữa, trong các tập lệnh, mọi người không muốn nhớ đường dẫn tệp. Chúng lộn xộn, chúng có thể không chính xác. Hãy để bảng kê khai tìm ra vị trí của tệp và để con người tìm ra tài liệu họ cần bằng tên của nó chứ không phải tên tệp.

<material name="wood">
  <diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
  <normals>environment.zip/wood_normals.jpg</normals>
  <shader>environment.zip/wood.fx</shader>
  <specular color="1,1,1,1" power="0.5" flat="yes" />
</material>

2

Là một mẫu thiết kế chung, các bảng kê khai rất hữu ích khi bạn muốn thu thập tất cả thông tin về một tập hợp các đối tượng khác nhau vào một nơi. Nó không phải là về các tệp lưu trữ / đóng gói, hoặc về sự gián tiếp để cho phép mọi thứ được di chuyển mà không cần biên dịch lại / cập nhật các tài liệu tham khảo gốc. Thật vậy, cái sau có thể giới thiệu nhiều vấn đề hơn nó giải quyết, vì vậy bạn sẽ chỉ làm điều đó nếu nó giải quyết được một nhu cầu cụ thể mà bạn có.

Ưu điểm lớn của bảng kê khai là chúng hoạt động như một chỉ mục cho một lượng lớn dữ liệu trong một nơi nhỏ gọn duy nhất. Vì vậy, chúng cải thiện hiệu suất (vì bạn chỉ có thể tải toàn bộ tệp kê khai từ đĩa và giữ nó trong bộ nhớ), đặc biệt trong trường hợp bạn cần lặp lại trên nhiều đối tượng, nhưng bạn không biết trước những đối tượng đó sẽ là gì . Nếu các đối tượng nằm trên đĩa, đặc biệt nếu chúng ở nhiều nơi, bạn phải chạm vào hệ thống tệp mỗi lần bạn muốn lặp lại qua các tệp. Đối với các hệ thống tệp dựa trên đĩa, thời gian cần thiết để chạm vào hệ thống tệp là nghiêm ngặt, do đó, việc lặp lại các tệp trong một thư mục là một chi phí lớn. Bằng cách xây dựng trước một bảng kê khai các tệp tại thời điểm xây dựng (NB: không biên dịch thời gian), bạn giao dịch chi phí đó cho việc sử dụng bộ nhớ.

Các tệp lưu trữ yêu cầu sử dụng các bảng kê khai, đơn giản vì bảng nội dung cho kho lưu trữ về cơ bản là một bảng kê khai, do đó bạn có được hành vi miễn phí. Và nếu bạn được yêu cầu sử dụng bảng kê khai tài sản ở một địa điểm, có thể rõ ràng hơn để khẳng định rằng tất cả tài sản được tham chiếu thông qua bảng kê khai; cho phép bạn trừu tượng vị trí / cơ chế lưu trữ thực tế của các tài sản từ các tham chiếu đến các tài sản đó trong mã. Bằng cách đó, bạn có thể có một loại tham chiếu tài sản duy nhất trong mã của mình và không phải phân biệt giữa các đường dẫn tệp, đường dẫn tệp lưu trữ + offset hoặc tài sản phụ.


1

Ngoài các câu trả lời khác, nó cũng làm cho mã của bạn tách biệt hơn một chút so với tài sản của bạn. Ví dụ, bạn có thể cho phép một nghệ sĩ làm việc trực tiếp với các tệp kê khai mà không cần phải có một lập trình viên thực hiện thay đổi và tạo một bản dựng mới. Tất cả những gì cần làm là thay đổi tệp kê khai để trỏ đến một hình ảnh mới và chỉ cần chạy lại trò chơi.


0

Các tệp kê khai cung cấp một lớp không xác định giữa tên tài nguyên và vị trí của nó. Sau các lớp bổ sung chỉ là một dấu hiệu của thiết kế quá mức. Tuy nhiên, đôi khi lớp bổ sung đó chỉ là những gì cần thiết để xây dựng một giải pháp thanh lịch và hiệu quả.

Dưới đây là một ví dụ cụ thể đơn giản, nơi phân tách tên tài nguyên / vị trí đã giúp tôi. Trong khi phát triển, tài sản nghệ thuật của tôi nằm trong sự kiểm soát sửa đổi với mã nguồn. Nó rất thuận tiện và cho phép tôi lặp lại nhanh chóng. Thông thường tên tài nguyên phản ánh vị trí của nó. Các biểu hiện phát triển là rất thẳng về phía trước.

Tôi không muốn phân phối một trò chơi với các tài sản nằm rải rác xung quanh. Vì vậy, khi tôi sẵn sàng phân phối nó, tôi có thể dễ dàng nén tài sản của mình vào một tệp tài nguyên và xây dựng một bảng kê khai mới.

Ngoài ra kết cấu nền là một cách tuyệt vời để vắt hiệu năng hơn một chút khỏi hệ thống đồ họa. Atlat rất nhanh nhưng chúng là một nỗi đau để làm việc trong khi nghệ thuật vẫn đang được phát triển. Giải pháp của tôi là chỉ xây dựng tập bản đồ vào cuối khi tôi tối ưu hóa trò chơi. Vì tôi đang sử dụng bảng kê khai, tất cả những gì tôi cần làm là cập nhật bảng kê khai để trỏ đến vị trí tập bản đồ và trò chơi hiện đang sử dụng tập tin thay vì tập tin thẳng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.