게임 데이터 저장에 적합한 파일 형식은 무엇입니까? [닫은]

커스텀 게임 데이터를 저장해야합니다. 지도, 선수 등

그들 모두는 "하위 오브젝트"를 갖습니다. 예를 들어지도와지도에는 "배열"타일이 있습니다. 즉, 계층 적 데이터. 희망적으로 바이너리는 없습니다.

이것들에게 좋은 형식은 무엇입니까?

지금까지 나는 고려했다 :

Serailization : 빠르고 빠르지 만 기본 클래스를 변경하면 중단되는 경향이 있습니다.

XML : 나는 이것을 파싱하는 것을 정말로 싫어한다. 내 테스트 케이스는 100 줄 이상의 코드였으며 매우 간단한 형식의 톤의 "바쁜 작업"처럼 보였습니다.

INI : 계층 적 데이터에 대해서는 서투른 것입니다.

Protobuf : 사용하지는 않았지만 클래스를 변경하면 많은 수동 뭉개기를해야하고 중단됩니다.

다른 옵션? 그래서 내가 여기 있습니다!

편집 : 이것은 Java btw입니다.

편집 2 :

"제어 이진 직렬화"(아래 참조)에 정착했습니다.

장점 :

• 빠르다

• 디스크가 작고 읽기 / 쓰기 중에 쉽게 압축 / 압축 해제 할 수 있습니다.

• 게임과 툴셋에서 읽기 / 쓰기가 매우 쉽습니다.

• 객체의 포함 / 제외를 결정할 수 있습니다.

• 개체 / 데이터를 중첩 할 수 있습니다.

단점 :

• 직접 편집 할 수 없습니다 (예 : XML, YAML 등)

• 스크립트로 쉽게 읽거나 수정할 수 없습니다

• 기본적으로 Java Serialization은 다른 기능에 비해 상당히 느리거나 부풀어 있지만 안정적이며 작동합니다.

계층 적 데이터를 표시하려면 YAML 또는 JSON 이 좋은 옵션입니다. 그들은는 지금까지 XML에 비해 구문 분석을 간단하고 쉽게.

또 다른 옵션은 "제어 된"이진 직렬화 프로세스입니다. 모든 객체는 제어 된 방식으로 상태를 기록합니다. 즉

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

id Tech 4 (Quake 4 / Doom 3 엔진)는 이러한 접근 방식을 사용합니다.

잘 만들어진 이진 형식은 실제로 모든 이점을 얻었으며, 빠르고, 작고, 유연합니다.

이진 형식을 만들면 규칙이 없어야합니다. 이는 큰 이점이지만 아이러니하게도 이진 파일 구조에 잘못된 이름을 부여한 것입니다. XML, JSON 등은 당신을 위해 많은 결정을 내리지 만, 항상 최적의 것은 아니지만, 일반적으로 다른 일반적인 문제를 피하는 데 도움이되는 합리적으로 안전한 선택입니다.

이러한 문제를 파악하고 문제를 염두에두고 형식을 디자인하면 멋진 이진 형식을 만들 수 있습니다.

바이너리 형식을 만들 정도로 경험이 많거나 확신이없고 속도가 미미할 정도로 데이터의 양이 작 으면 JSON을 사용하는 것이 좋습니다. 간단하지만 작업을 수행합니다.

파일 형식 선택은 현재 도구 세트 와 제작하려는 게임 에 따라 크게 달라집니다 . 그 말로 ...

툴셋은 게임 파일 형식을 결정할 때 가장 중요한 요소 중 하나입니다. 이진 형식 을 만드는 경우 항상 게임 데이터를 입력 할 수있는 도구가 있는지 확인해야합니다 . 16 진수 편집기만큼 간단하거나 언리얼 편집기처럼 복잡 할 수 있습니다.

XML, YAML 또는 기타 언어 파일의 주요 장점은 텍스트 편집기를 통해 쉽게 편집 할 수 있다는 것 입니다. 또한 기존 표준을 사용하면 잘못 될 수 없습니다 . 그러나 수천 개의 파일이있을 때 이것은 매우 지루 합니다.

경기. 어떤 종류의 게임을 만들고 있습니까? 왜 이것이 파일 형식에 영향을 줄 것이라고 말합니까? 2D bomberman과 같은 것을 만드는 경우 다음과 같은 간단한 텍스트 파일을 사용하여 벗어날 수 있습니다 .

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

다시 말해, 항상 특정 데이터에 가장 명확한 형식으로 이동하십시오 . 롤 플레잉 게임 은 가장 복잡한 게임 장르입니다. 많은 데이터가 필요합니다. 그러나 게임의 모든 데이터에 대해 바이너리 또는 텍스트 기반 의 특정 형식을 고수해야한다는 의미는 아닙니다 .

• 지도, 입자 및 기타 그래픽 요소 는 사용자 정의 이진 형식을 사용하는 경향이 있습니다. 그것을 구현 하는 가장 간단한 방법 이기 때문 입니다. 텍스트를 사용하여지도를 설명하는 것은 사람이 제정신이 아닙니다. 일반적으로 맵 / 레벨 / 입자 편집기를 통해 편집됩니다.
• 플레이어, 아이템, 적, 기술 및 퀘스트는 게임 밸런스에 영향을주는 통계입니다 . 일반적으로 많은 입력과 조정이 필요합니다. 구현하기 쉽도록 XML 파일에 넣었지만 디자이너가 사용할 수있는 개체 편집기를 사용하여이 작업을 수행하고 싶습니다. 두 세계의 최고 .

일반적으로 텍스트 형식으로 텍스트를 설명하고 이진 형식으로 그래픽을 설명하려고합니다. 다음은 예제를 제공해야합니다.

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

요약하면, 가능한 한 절대적으로 필요한 경우가 아니라면 데이터를 스크립팅하지 않는 것이 가장 좋습니다 . 최종 사용자는 게임이 재생 가능한 한 형식이 얼마나 멋진 지 신경 쓰지 않습니다.

건배, 로이 =)

BSON은 꽤 좋습니다. http://bsonspec.org/ . JSON보다 구문 분석이 쉽고 이진 데이터를 포함하는 것이 더 좋지만 여전히 훌륭한 구조를 가지고 있습니다. 프로토콜 버퍼와 다소 비슷합니다. 단점은 mongodb 외부에서 그것에 대한 많은 도구 지원이있는 것처럼 보입니다.

편집 : MsgPack ( http://msgpack.org/ )도 BSON과 유사하며 더 많은 견인력을 얻고있는 것 같습니다.

사용자 정의 이진 데이터 형식은 어떻게 되었습니까? 원시 직렬화를 두려워하는 경우 필요에 따라 필드를 작성하고 다시 읽는 자체 시스템을 작성하십시오. XML이 필요하지 않습니다. 형식이 제공하는 투명성이 필요하지 않은 상황에서는 실제로 너무 크고 복잡합니다. 잘 지정 된 파일 형식을 정의하고 고수하십시오. 각 레코드에서 데이터 세트를 null 값으로 채워서 확장 할 수있는 공간을 남겨 두십시오 (100 바이트 레코드가 있으므로 나중에 사용할 수 있도록 150으로 채 웁니다).
버전 번호와 체크섬을 추가하면 어떤 필드를 채워야하는지 알 수 있고 유효성에 대한 유효성 검사를 할 수 있습니다.

특정 데이터에 대해 XML 또는 다른 형식을 Base64 삽입과 혼합 할 수 있으며 가독성이 필요한 필드에는 일반적인 TEXT를 사용할 수 있습니다