Định dạng tệp phẳng tốt để lưu trữ bản đồ ô 2D có thể phát triển vô hạn theo bất kỳ hướng nào?

Tôi đang tạo một công cụ bản đồ đơn giản sẽ tự động mở rộng theo bất kỳ hướng nào với nội dung được tạo theo thủ tục khi cần.

Cách tốt để lưu trữ dữ liệu bản đồ, được neo ở gốc 0,0 để một tập hợp con hình chữ nhật của dữ liệu bản đồ có thể được tải nhanh chóng và hiệu quả từ bất kỳ điểm nào trên bản đồ?

Tôi có một ý tưởng rằng có lẽ tôi nên phân chia bản đồ thành các khu vực riêng biệt và sau đó sử dụng một số loại định dạng tiêu đề để xác định vị trí trong tệp trong một khu vực cụ thể. Đây có phải là một kỹ thuật tốt hay có những kỹ thuật tốt hơn, hiệu quả hơn mà tôi có thể xem xét?

Tôi sẽ khuyên bạn không nên sử dụng một tệp phẳng duy nhất cho lượng dữ liệu vô hạn về mặt lý thuyết.

Nếu bạn có một lượng dữ liệu vô hạn về mặt lý thuyết thì bạn cần truy cập ngẫu nhiên , có nghĩa là nhiều tệp hoặc cơ sở dữ liệu - hoặc định dạng tệp phẳng được lập chỉ mục, bao gồm giải quyết lại các vấn đề lập chỉ mục đã được giải quyết bằng hệ thống tệp hoặc cơ sở dữ liệu.

Nếu bạn trải rộng các đoạn của mình trên nhiều tệp, việc lấy đoạn mã ở (-110, 5000) chỉ là vấn đề "% APPDATA% / game / map / -110 / 5000.dat" (hoặc một số tên tệp khác nếu bạn muốn bắt đầu nén chúng). Cơ sở dữ liệu chỉ cần một truy vấn. Nếu một đoạn không có bất kỳ dữ liệu nào, bạn không thể lưu trữ bất cứ thứ gì. Một tập tin phẳng duy nhất không cung cấp tốc độ và sự thuận tiện của việc truy cập ngẫu nhiên ngay lập tức.

Trong một tệp có kích thước tùy ý, để truy cập ngẫu nhiên nhanh, bạn phải có sự đảm bảo cho vị trí của bất kỳ khối dữ liệu nào, có nghĩa là sử dụng một chỉ mục (vì tìm kiếm nhị phân thô qua các khối dữ liệu của bạn làm tổn thương hiệu suất và tạo lưới trong tệp có các điểm "trống" cung cấp cho bạn vấn đề của Byte56 ). Khi bạn phát triển một hệ thống lập chỉ mục, cung cấp cho nó hiệu quả và tự viết API, bạn đã tạo lại một cái gì đó như hệ thống tệp hoặc cơ sở dữ liệu. Trừ khi bạn thực sự đạt được điều gì đó khi làm điều đó có thể không đáng để đầu tư. Chẳng hạn, Steam hưởng lợi ồ ạt từ các định dạng tệp GCF / NCF của họ.

Nếu bạn muốn một số bảo mật cho khoản tiết kiệm của mình, bạn vẫn có thể làm điều đó. Chẳng hạn, bạn có thể mã hóa từng đoạn riêng lẻ. Để ngăn chúng bị xóa, bạn có thể có hàm băm trung tâm dựa trên dữ liệu đã lưu. Nếu dữ liệu đã lưu không khớp với hàm băm (và chương trình của bạn không gây ra thay đổi), một đoạn dữ liệu đã bị xóa.

Giải pháp được sử dụng thường xuyên nhất dường như là chia thành nhiều tệp, tuy nhiên câu hỏi của bạn chỉ ngụ ý một tệp duy nhất. Tùy chọn hợp lý duy nhất cho điều này (theo ý kiến ​​của tôi) là mô phỏng một hệ thống tệp rất đơn giản bên trong tệp duy nhất đó. Điều này thực sự không khó lắm, nhưng bạn thực sự nên cân nhắc sử dụng nhiều tệp nếu có thể.

Nếu bạn phải bám vào một tệp, thì bạn có thể tìm thấy nguồn cảm hứng cho việc triển khai của mình từ ext2 fs. http://en.wikipedia.org/wiki/Ext2 Tôi biết rằng nó đã giúp tôi đưa ra một số quyết định tốt khi tôi phải thực hiện một FS đơn giản cho một trò chơi.

Nhưng thực sự, đối với bất kỳ bản đồ đang phát triển nào, tốt hơn là chỉ sử dụng một tệp cho mỗi đoạn "truy cập".

Tôi đã triển khai một hệ thống chunk cho trò chơi của mình khi tôi đang nghịch ngợm với thế giới vô tận (không chắc tôi có giữ chúng hay không). Để sử dụng với một tệp duy nhất, lúc đầu, tôi đã sử dụng vị trí thế giới của khối để tính toán một byte bù vào tệp. Điều này giả định kích thước khối tĩnh, hoặc ít nhất là tối đa tĩnh. Tuy nhiên, nếu người dùng chỉ đi một hướng trong một thời gian, tệp này sẽ trở nên khá thưa thớt về kích thước của nó, vì có những vùng đất rộng lớn chưa được tạo nên nên có khoảng trống trong tệp.

Tôi cũng đã thử một hệ thống hai tập tin. Một tệp giữ bản đồ của các cặp "vị trí chunk" thành "cặp chunk bù". Thứ hai giữ tất cả các khối. Khi một đoạn mới được tạo, nó chỉ đơn giản là ở phần cuối của tệp chunk và phần bù của nó được lưu trong vị trí-> tệp bù. Đây là một vấn đề khi bạn có RẤT NHIỀU khối và việc tìm phần bù trong vị trí-> tệp bù mất một chút thời gian. Nếu bạn thấy khả thi, bạn có thể tải vị trí-> dữ liệu bù vào bản đồ băm khi tải, để có quyền truy cập nhanh.

Hiện tại tôi đang sử dụng tùy chọn thứ hai, nhưng có thể chuyển sang thứ khác nếu tôi thấy rằng hiệu suất bị thiếu. Có thể với thông tin này, bạn sẽ có thể tạo ra thứ gì đó phù hợp với mình. Chúc may mắn!