Một định dạng tập tin tốt để lưu dữ liệu trò chơi là gì? [đóng cửa]

Tôi cần lưu một số dữ liệu trò chơi tùy chỉnh. Bản đồ, người chơi, v.v.

Tất cả trong số họ sẽ có "đối tượng phụ". Ví dụ: bản đồ và bản đồ sẽ có một "mảng" gạch. tức là dữ liệu phân cấp. Hy vọng không có gì nhị phân.

Điều gì sẽ là một định dạng tốt cho những điều này?

Cho đến nay tôi đã xem xét:

Serailization: Đây là NHANH CHÓNG và dễ dàng, nhưng có xu hướng bị phá vỡ khi tôi thay đổi các lớp bên dưới :(

XML: Tôi thực sự ghét phân tích cú pháp này. Trường hợp thử nghiệm của tôi là hơn 100 dòng mã và có vẻ như hàng tấn "công việc bận rộn" với định dạng rất đơn giản.

INI: sẽ thực sự vụng về cho dữ liệu phân cấp.

Protobuf: Không bao giờ sử dụng nó, nhưng đọc bạn phải thực hiện rất nhiều thao tác thủ công xung quanh và phá vỡ nếu bạn thay đổi lớp học.

Sự lựa chọn khác? Đó là lý do tại sao tôi ở đây!

Chỉnh sửa: đây là Java btw.

Chỉnh sửa 2:

Tôi giải quyết "Tuần tự nhị phân có kiểm soát" (xem bên dưới).

Ưu điểm:

• nó nhanh

• nó nhỏ (trên đĩa) và có thể dễ dàng nén / giải nén trong quá trình đọc / ghi.

• thật dễ dàng để đọc / ghi từ trò chơi và bộ công cụ.

• Tôi có thể quyết định những gì cần bao gồm / loại trừ đối tượng.

• Đối tượng / Dữ liệu có thể được lồng nhau.

Nhược điểm:

• Không thể chỉnh sửa bằng tay (như XML, YAML, v.v.)

• Không thể dễ dàng đọc / sửa đổi nó với các tập lệnh

• Tuần tự hóa Java theo mặc định là khá chậm / cồng kềnh so với các hàm ý khác, nhưng nó ổn định và hoạt động

Để hiển thị dữ liệu chữ tượng hình, YAML hoặc JSON sẽ là các tùy chọn tốt. Họ là xa đơn giản và dễ dàng hơn để phân tích hơn XML.

Một lựa chọn khác sẽ là một quá trình tuần tự hóa nhị phân "được kiểm soát". Mọi đối tượng đều viết nó ra một cách có kiểm soát, tức là

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

id Tech 4 (động cơ Quake 4 / Doom 3) sử dụng cách tiếp cận như vậy.

Một định dạng nhị phân được làm tốt thực sự có tất cả các lợi thế, nó nhanh, nhỏ một cách hợp lý và linh hoạt như bạn tạo ra.

Tạo một định dạng nhị phân, bạn bị ràng buộc bởi không có quy tắc, đó là một lợi thế lớn, nhưng trớ trêu thay, phần lớn những gì đã tạo cho cấu trúc tệp nhị phân một tên xấu. XML, JSON và những thứ tương tự đưa ra rất nhiều quyết định cho bạn, chúng không phải lúc nào cũng tối ưu, nhưng chúng là những lựa chọn hợp lý an toàn thường sẽ giúp bạn tránh khỏi một số vấn đề phổ biến khác.

Xác định những vấn đề này, thiết kế định dạng của bạn với những vấn đề trong tâm trí và bạn có thể tạo một định dạng nhị phân tuyệt vời.

Nếu bạn không đủ kinh nghiệm / đủ tự tin để tạo định dạng nhị phân và lượng dữ liệu đủ nhỏ để tác động tốc độ sẽ không đáng kể, tôi khuyên bạn nên sử dụng JSON, thật đơn giản, nhưng thực hiện công việc.

Sự lựa chọn định dạng tệp của bạn phụ thuộc rất nhiều vào bộ công cụ hiện tại của bạn và trò chơi bạn dự định thực hiện. Nói vậy ...

Toolset là một trong những yếu tố quan trọng nhất khi quyết định định dạng tệp trò chơi. Nếu bạn tạo định dạng nhị phân , bạn phải luôn đảm bảo rằng bạn có các công cụ để nhập dữ liệu trò chơi của mình. Điều này có thể đơn giản như trình soạn thảo hex hoặc phức tạp như Unreal Editor.

Tôi đoán ưu điểm chính của XML, YAML hoặc bất kỳ tệp ngôn ngữ nào khác là bạn có thể chỉnh sửa dễ dàng thông qua trình soạn thảo văn bản. Và sử dụng một tiêu chuẩn hiện có, nó đảm bảo bạn không thể sai . Nhưng, điều này là vô cùng tẻ nhạt khi bạn có một ngàn tập tin, đưa tôi đến điểm tiếp theo của tôi.

Trò chơi. Bạn đang làm loại trò chơi nào? Tại sao tôi nói điều này sẽ ảnh hưởng đến định dạng tập tin? Bởi vì, nếu bạn đang tạo ra thứ gì đó như máy bay ném bom 2D, bạn có thể thoát khỏi một tệp văn bản đơn giản như:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

Nói cách khác, luôn luôn đi đến định dạng rõ ràng nhất cho dữ liệu cụ thể của bạn . Game nhập vai là thể loại game phức tạp nhất để thực hiện. Họ yêu cầu rất nhiều dữ liệu. Nhưng không có nghĩa là bạn phải dán một định dạng cụ thể , có thể là nhị phân hoặc dựa trên văn bản cho tất cả dữ liệu trong trò chơi.

• Bản đồ, các hạt và các công cụ đồ họa khác có xu hướng sử dụng định dạng nhị phân tùy chỉnh. Bởi vì đó là cách đơn giản nhất để thực hiện nó. Nó không phải là con người lành mạnh để mô tả bản đồ bằng văn bản. Thường được chỉnh sửa thông qua các trình soạn thảo bản đồ / cấp / hạt.
• Người chơi, vật phẩm, kẻ thù, kỹ năng và nhiệm vụ là những thống kê ảnh hưởng đến cân bằng trò chơi . Họ thường yêu cầu rất nhiều đầu vào và tinh chỉnh. Tôi muốn làm điều này bằng cách đặt nó vào một tệp XML để dễ thực hiện, nhưng vẫn có một trình soạn thảo đối tượng cho các nhà thiết kế để chơi. Tốt nhất của cả hai thế giới .

Nói chung, bạn muốn mô tả văn bản với định dạng văn bản và đồ họa với định dạng nhị phân. Sau đây sẽ cho bạn một ví dụ:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

Tóm lại, theo khuyến nghị đầy đủ nhất của tôi là nếu có thể, bạn không kịch bản dữ liệu của mình, trừ khi thực sự cần thiết . Người dùng cuối không quan tâm đến định dạng tuyệt vời như thế nào, miễn là trò chơi có thể chơi được, đó mới là vấn đề.

Chúc mừng, roy =)

BSON khá đẹp. http://bsonspec.org/ . Việc phân tích JSON sau đó dễ dàng hơn và tốt hơn trong việc chứa dữ liệu nhị phân, nhưng vẫn có cấu trúc đẹp. Nó hơi giống với bộ đệm giao thức. Nhược điểm là dường như không có nhiều công cụ hỗ trợ cho nó bên ngoài mongodb.

EDIT: MsgPack ( http://msgpack.org/ ) cũng tương tự như BSON và dường như đang tăng thêm lực kéo.

Điều gì đã xảy ra với định dạng dữ liệu nhị phân tùy chỉnh của bạn? Nếu bạn sợ tuần tự hóa thô, hãy viết hệ thống của riêng bạn viết các trường khi cần và đọc lại chúng. Không cần xml, điều này thực sự quá cồng kềnh và phức tạp cho các tình huống mà bạn không cần sự minh bạch mà định dạng cung cấp. Chỉ cần xác định định dạng tệp được chỉ định rõ và tuân theo định dạng đó, có thể có một số chỗ để mở rộng tập dữ liệu của bạn trong mỗi bản ghi bằng cách đệm chúng với các giá trị null (giả sử bạn có bản ghi 100 byte ngay bây giờ, đệm đến 150 để sử dụng trong tương lai.
Thêm số phiên bản và có thể là tổng kiểm tra để bạn có thể biết những trường nào cần điền và kiểm tra tính hợp lệ để kiểm tra tính hợp lệ và bạn sẽ ổn.

Bạn có thể trộn XML hoặc một số định dạng khác với các lần chèn Base64 cho một số dữ liệu cụ thể và đối với các trường bạn cần có thể đọc được, bạn có thể sử dụng văn bản thông thường