'XML nhị phân' cho dữ liệu trò chơi?

Tôi đang làm việc trên một công cụ chỉnh sửa mức lưu dữ liệu của nó dưới dạng XML.

Điều này là lý tưởng trong quá trình phát triển, vì không khó để thực hiện các thay đổi nhỏ đối với định dạng dữ liệu và nó hoạt động độc đáo với dữ liệu giống như cây.

Tuy nhiên, nhược điểm là các tệp XML khá cồng kềnh, chủ yếu là do trùng lặp tên thẻ và thuộc tính. Cũng do dữ liệu số chiếm nhiều không gian hơn so với sử dụng kiểu dữ liệu gốc. Một mức nhỏ có thể dễ dàng kết thúc là 1Mb +. Tôi muốn giảm các kích thước này xuống đáng kể, đặc biệt nếu hệ thống này được sử dụng cho một trò chơi trên iPhone hoặc các thiết bị khác có bộ nhớ tương đối hạn chế.

Giải pháp tối ưu, cho bộ nhớ và hiệu năng, sẽ là chuyển đổi XML sang định dạng mức nhị phân. Nhưng tôi không muốn làm điều này. Tôi muốn giữ định dạng khá linh hoạt. XML giúp dễ dàng thêm các thuộc tính mới vào các đối tượng và cung cấp cho chúng một giá trị mặc định nếu một phiên bản cũ của dữ liệu được tải. Vì vậy, tôi muốn giữ theo thứ bậc của các nút, với các thuộc tính là cặp giá trị tên.

Nhưng tôi cần lưu trữ cái này ở định dạng nhỏ gọn hơn - để loại bỏ sự trùng lặp lớn của tên thẻ / thuộc tính. Cũng có thể để cung cấp cho các thuộc tính kiểu gốc, vì vậy, ví dụ dữ liệu dấu phẩy động được lưu trữ dưới dạng 4 byte cho mỗi float, không phải dưới dạng chuỗi văn bản.

Google / Wikipedia tiết lộ rằng 'XML nhị phân' hầu như không phải là vấn đề mới - nó đã được giải quyết một số lần. Có ai ở đây có kinh nghiệm với bất kỳ hệ thống / tiêu chuẩn hiện có nào không? - có bất kỳ lý tưởng nào cho việc sử dụng trò chơi - với thư viện trình tải / trình phân tích cú pháp / trình tải đa nền tảng miễn phí, nhẹ và có sẵn (C / C ++) không?

Hay tôi nên tự sáng tạo lại cái bánh xe này?

Hoặc tốt hơn hết là tôi quên đi lý tưởng và chỉ nén dữ liệu .xml thô của mình (nó sẽ đóng gói tốt với nén giống như zip) và chỉ cần tải bộ nhớ / hiệu năng khi tải?

Chúng tôi đã sử dụng XML nhị phân rất nhiều cho Superman Returns: The Videogame . Chúng tôi đang nói chuyện hàng ngàn và hàng ngàn tập tin. Nó hoạt động tốt, nhưng thực sự có vẻ không đáng nỗ lực. Nó đã ăn một phần đáng chú ý trong thời gian tải của chúng tôi và "tính linh hoạt" của XML không tăng lên. Sau một thời gian, các tệp dữ liệu của chúng tôi có quá nhiều định danh kỳ lạ, các tham chiếu bên ngoài cần được giữ đồng bộ và các yêu cầu lạ khác để chúng thực sự được chỉnh sửa một cách khả thi.

Ngoài ra, XML thực sự là một định dạng đánh dấu và không phải là định dạng dữ liệu. Nó được tối ưu hóa cho nhiều văn bản với các thẻ thỉnh thoảng. Nó không tuyệt vời cho dữ liệu có cấu trúc đầy đủ. Đó không phải là cuộc gọi của tôi, nhưng nếu nó đã được và tôi biết thì bây giờ tôi biết gì, có lẽ tôi đã thực hiện JSON hoặc YAML. Cả hai đều đủ để không yêu cầu nén và được tối ưu hóa để thể hiện dữ liệu , không phải văn bản .

Lưu trữ và chỉnh sửa các cấp của bạn như XML thông thường, nhưng công cụ trò chơi của bạn sẽ lười biếng nướng nó thành XML nhị phân trong khi tải và lưu XML nhị phân trở lại đĩa để có thể tải lần sau (nếu XML thô không thay đổi) .

Một cái gì đó như thế này:

data loadXml(xmlFile)
{
    if (xmlFile has changed OR binFile doesn't exist)
    {
        binFile = convertToBinary(xmlFile)
        save(binFile)
    }
    return loadBinaryXml(binFile)
}

Bằng cách đó bạn có được điều tốt nhất của cả hai thế giới. Khi phát hành, bạn chỉ cần đảm bảo tất cả các tệp nhị phân đều ở đó.

Bộ đệm giao thức Google có vẻ như là cách để đi, nhưng tôi đã không sử dụng chúng cho mình.
http://code.google.com.vn/p/protobuf/

Bạn xác định tệp .proto mô tả định dạng tệp:

message Person {
  required int32 id = 1;
  required string name = 2;
  optional string email = 3;
}

Điều này sau đó được biên dịch bằng một công cụ dòng lệnh tạo ra các lớp C / C ++ để ghi và phân tích các tệp dữ liệu nhị phân theo định dạng dữ liệu được xác định trước đó. Ngoài ra còn có một vài phần mở rộng cho các ngôn ngữ lập trình khác nhau.

Nhược điểm của ProtocolBuffer là chúng không phải là định dạng văn bản gốc. Bạn sẽ cần một công cụ để tạo, đọc và chỉnh sửa chúng. Nhưng điều này không phải là vấn đề nếu bạn chỉ sử dụng chúng để trao đổi dữ liệu giữa trình chỉnh sửa trò chơi và trò chơi của bạn. Tôi sẽ không sử dụng nó để xác định tập tin cấu hình;)

Nén các tệp xml thô cũng sẽ hoạt động. Bạn đang làm loại trò chơi nào? Nếu nó dựa trên cấp độ thì bạn chỉ nên tải tất cả các tài nguyên cần thiết một lần khi cấp được tải.

cập nhật: Có một số dự án cho các ngôn ngữ khác như C # hoạt động với ProtocolBuffers:
http://code.google.com.vn/p/protobuf/wiki/ThirdPartyAddOns

Còn định dạng JSON thì sao?

http://www.json.org/xml.html

Sử dụng JSON.

(Dựa trên phản hồi của Munificent, và phần lớn là để đáp lại những lo lắng của bạn thể hiện ở nơi khác)

Bạn đã đề cập đến mối quan tâm rằng JSON có vấn đề lãng phí các yếu tố đặt tên không gian, như XML. Nó không.

JSON được xây dựng trên hai cấu trúc: cặp tên / giá trị ( đối tượng ) và danh sách các giá trị ( mảng ) theo thứ tự. XML chỉ được xây dựng trên các cặp tên / giá trị.

Nếu bạn nghĩ JSON dựa vào các đối tượng bạn đã đọc JSON được xây dựng để tự mô tả và có thể đọc được, như thế này (sử dụng các cặp chữ số bát phân để biểu thị các byte đơn):

{
    "some": ...,
    "data": ...,
    "fields": ...,
    "cars": [
        {"name":"greg","cost":8C,"speed":FA,"age":04,"driverID":384FFFFF},
        {"name":"ole rustbucket","cost":00,"speed":00,"age":2A,"driverID":04FF54A9}
    ]
}

Tuy nhiên, bạn cũng có tùy chọn viết nó như thế này, miễn là bạn biết mọi thứ sẽ ở đâu (và vì vậy có thể tìm chỉ số 4, thay vì đối tượng "xe hơi", để lấy danh sách xe của bạn):

{
    [
        ...,
        ..., 
        ...,
        [["greg",8C,FA,04,384FFFFF],["ole rustbucket",00,00,2A,04FF54A9]],
        ...,
    ]
}

Liệu nó có được ngắn gọn hơn chỉ có [, ], ,và giá trị của bạn?

Vâng, điều đó sẽ xảy ra nếu bạn sẵn sàng đến gần hơn và gần hơn với luồng nhị phân thuần túy.

"cars":{"names":["greg","ole rustbucket"],"stream":8CFA04384FFFFF00002A04FF54A9}
or
[["greg","ole rustbucket"],8CFA04384FFFFF00002A04FF54A9]

Đừng tự bắn vào chân mình bằng cách tối ưu hóa quá nhiều.

Tôi biết bạn đã chấp nhận câu trả lời, nhưng Google cả "Fast Infoset" (XML nhị phân) và vtd-xml.

Mặc dù (VTD) sau này có thể không giải quyết được khía cạnh nén của việc sử dụng XML của bạn, nhưng nó có thể tăng tốc độ truy cập nút trên các tệp lớn, đáng kể (nó sử dụng từ điển nhị phân 'từ điển' để nhảy đến các nút và không tạo đối tượng cho mỗi nút , thay vì làm việc trên chuỗi XML gốc). Do đó, việc tra cứu XML của nó [được cho là] nhanh hơn và nó không đòi hỏi nhiều bộ nhớ trong quá trình để truy cập / thao tác với tài liệu XML.

Cả hai điều trên đều có các ràng buộc trong các ngôn ngữ phổ biến (bao gồm C #).

Chúc mừng

Giàu có

Bạn có thể thử Karvonite . Nó được cho là nhanh nhẹn. Đó là một khung kiên trì sẽ thích ứng với các thay đổi trong dữ liệu của bạn khá tốt (điều này tốt so với việc tự xử lý nhị phân của bạn). Tôi thực sự không chắc chắn làm thế nào dữ liệu được cấu trúc, nhưng các tệp nhỏ hơn rất nhiều so với các tệp cồng kềnh xml. (Tôi cho rằng nó lưu dữ liệu ở định dạng nhị phân thay vì văn bản như xml)

Điều duy nhất tôi có thể nghĩ đến với điều này là nếu dữ liệu của bạn bị hỏng hoặc một số cách gây rối theo cách mà Karvonite không thích nó, bạn sẽ cảm thấy xót xa cho những người tạo ra nó trừ khi bạn tìm ra cách cấu trúc của dữ liệu hoạt động.

Cách bạn chỉ định cách lưu / tải dữ liệu của mình là bạn chỉ cần mở trình soạn thảo kiên trì của họ, nhập cụm của bạn với tất cả các đối tượng dữ liệu và chọn một số hộp kiểm để hiển thị những đối tượng bạn muốn được hỗ trợ và trường / thuộc tính nào cần lưu.

Nó đáng để thử. Vì bạn đang sử dụng C #, điều này phù hợp với ngôn ngữ của bạn vì nó hoạt động với XNA (Windows, Xbox360 và Windows Phone 7 mà tôi nghĩ bạn quan tâm từ khi bạn đề cập đến iPhone?).

Chỉnh sửa: Chỉ cần lưu ý rằng bạn chỉ sử dụng C # cho các công cụ. Điều này có lẽ sẽ không phù hợp lắm trong quy trình làm việc của bạn. Vì một số lý do, tôi đã có XNA trong đầu.