답변:
이론적으로 무한한 양의 데이터에 단일 플랫 파일을 사용하지 않는 것이 좋습니다.
이론적으로 무한한 양의 데이터가있는 경우 무작위 액세스 가 필요합니다. 즉, 여러 파일 또는 데이터베이스 또는 색인 된 플랫 파일 형식을 의미합니다. 여기에는 파일 시스템 또는 데이터베이스로 이미 해결 된 색인 문제를 해결하는 것이 포함 됩니다.
청크를 여러 파일에 분산시키는 경우 (-110, 5000)에서 청크를 얻는 것은 "% APPDATA % / game / map / -110 / 5000.dat"(또는 원하는 경우 다른 파일 이름)을 말하면됩니다. 압축 시작). 데이터베이스에는 쿼리가 필요합니다. 청크에 데이터가 없으면 아무것도 저장할 수 없습니다. 하나의 플랫 파일은 배트에서 바로 임의 액세스의 속도와 편리함을 제공하지 않습니다.
임의 크기의 단일 파일에서 빠른 임의 액세스를 위해서는 모든 데이터 청크의 위치를 보장해야합니다. 즉, 데이터 청크를 통한 원시 이진 검색으로 인해 성능이 저하되고 그리드에서 "blank"지점이있는 파일은 Byte56의 문제를 제공합니다 ). 인덱싱 시스템을 개발하고 효율성을 높이고 API를 작성하면 파일 시스템이나 데이터베이스와 같은 것을 다시 만들었습니다. 실제로 무언가를 얻지 않으면 투자 가치가 없을 것입니다. 예를 들어 Steam은 GCF / NCF 파일 형식의 이점을 크게 활용할 수 있습니다.
당신이 저장에 대한 보안을 원한다면, 여전히 그렇게 할 수 있습니다. 예를 들어 각 개별 청크를 암호화 할 수 있습니다. 그것들이 삭제되는 것을 막기 위해 기존의 저장된 데이터를 기반으로 중앙 해시를 가질 수 있습니다. 저장된 데이터가 해시와 일치하지 않으면 (그리고 프로그램이 변경을 유발하지 않은 경우) 청크가 삭제됩니다.
가장 많이 사용되는 솔루션은 많은 파일로 분할되는 것으로 보이지만 귀하의 질문은 단일 파일만을 의미합니다. 이것에 대한 유일한 합리적인 옵션은 (내 의견으로는) 해당 단일 파일 내에서 매우 간단한 파일 시스템을 에뮬레이트하는 것입니다. 실제로 어려운 일이 아니지만 가능한 경우 여러 파일을 사용하는 것이 좋습니다.
하나의 파일을 고수 해야하는 경우 ext2 fs에서 구현에 대한 영감을 얻을 수 있습니다. http://en.wikipedia.org/wiki/Ext2 게임에 간단한 FS를 구현해야 할 때 결정을 내리는 데 도움이 되었다는 것을 알고 있습니다.
그러나 실제로 성장하는지도의 경우 일반적으로 각 "액세스 된"청크에 파일을 사용하는 것이 좋습니다.
나는 무한한 세계를 만날 때 내 게임을 위해 청킹 시스템을 구현했습니다. 단일 파일과 함께 사용하기 위해 처음에는 청크의 월드 위치를 사용하여 파일에 대한 바이트 오프셋을 계산했습니다. 정적 청크 크기 또는 최소한 정적 최대 값을 가정합니다. 그러나 사용자가 잠시 한 방향으로 향하는 경우, 아직 생성되지 않은 넓은 면적의 영역이있어서 파일에 빈 공간이 있었기 때문에이 파일은 크기가 매우 희박합니다.
나는 또한 두 개의 파일 시스템을 시도했다. 하나의 파일에는 "청크 위치"와 "청크 파일 오프셋"쌍의 맵이 있습니다. 두 번째는 모든 청크를 보유합니다. 새로운 청크가 생성되면 청크 파일의 끝에서 계속 진행되며 오프셋은 위치-> 오프셋 파일에 저장됩니다. 이것은 덩어리가 많고 위치-> 오프셋 파일에서 오프셋을 찾는 데 약간의 시간이 걸렸을 때 문제였습니다. 가능한 경우,로드시 위치-> 오프셋 데이터를 해시 맵에로드하여 빠르게 액세스 할 수 있습니다.
현재 두 번째 옵션을 사용하고 있지만 성능이 떨어지는 것을 발견하면 다른 것으로 전환 할 수 있습니다. 이 정보를 사용하면 자신에게 맞는 것을 만들 수 있습니다. 행운을 빕니다!