데이터 저장 방법을 선택하는 방법은 무엇입니까?

한 남자에게 물고기를 주면 하루 동안 그에게 먹이를줍니다. 한 남자에게 물고기를 가르치면 평생 먹입니다. - 중국어 속담

실제 프로젝트에 어떤 종류의 데이터 저장소를 사용해야하는지 물어볼 수 있지만 낚시 하는 법을 배우고 싶기 때문에 새 프로젝트를 시작할 때마다 물고기 를 요구할 필요가 없습니다 .

게임 이외의 프로젝트에 데이터를 저장하기 위해 XML 파일과 관계형 데이터베이스라는 두 가지 방법을 사용할 때까지. NoSQL 종류 의 다른 종류의 데이터베이스도 있다는 것을 알고 있습니다. 그러나 나는 나에게 더 많은 선택이 있는지, 또는 임의의 선택을 제외하고 처음에 선택하는 방법을 알지 못할 것입니다.

질문은 다음과 같습니다. 게임 프로젝트를위한 데이터 스토리지 종류를 어떻게 선택해야합니까?

그리고 선택할 때 다음 기준에 관심이 있습니다.

• 프로젝트의 크기
• 게임이 목표로하는 플랫폼과 사용 된 개발 플랫폼.
• 데이터 구조의 복잡성
• 많은 프로젝트에서 데이터의 이식성을 추가 했습니다.
• Added2 Silmutaneous는 다른 프로젝트의 사이에 데이터를 사용합니다. (즉, 사용자 데이터)
• 데이터에 얼마나 자주 액세스해야하는지 추가
• 동일한 애플리케이션에 여러 유형의 데이터 추가
• Added2 복수의 데이터 스토리지 구성.
• 무엇을 사용할지 결정할 때 관심이 있다고 생각되는 다른 점이 있습니다.

편집 내용 XML / JSON / Text 또는 데이터베이스를 사용하여 게임 컨텐츠를 저장하는 것이 더 낫습니까? , 그러나 그것이 내 요점을 정확하게 다루지 못한다고 생각했습니다. 이제 내가 틀렸다면 기꺼이 오류를 내 방식으로 보여줄 것입니다.

EDIT2 관련성이 있다고 생각되는 몇 가지 사항을 추가했습니다. 또한 플랫 파일 스토리지 및 관계형 데이터베이스 외에 다른 옵션이 무엇인지 듣고 싶습니다. 예를 들어 비 관계형 데이터베이스는 어떻습니까? 이전에 언급 한 다른 옵션보다 그러한 데이터베이스를 사용하는 것이 적절한 경우?

장르가 많기 때문에 귀하의 질문은 실제로 광범위하지만 전문 소프트웨어 개발자의 관점은 다음과 같습니다.

사용하는 데이터 지속성 메커니즘을 결정하는 데 사용할 기준 목록을 제공했습니다. 그것들은 :

• 프로젝트의 크기
• 게임이 목표로하는 플랫폼.
• 데이터 구조의 복잡성
• 많은 프로젝트에서 데이터의 이식성.
• 데이터에 얼마나 자주 액세스해야합니까
• 동일한 응용 프로그램에 대한 여러 유형의 데이터
• 무엇을 사용할지 결정할 때 관심이 있다고 생각되는 다른 점이 있습니다.

먼저 사용할 수있는 옵션을 설정해야합니다. 언어 나 기술을 지정하지 않았으므로 정확히 말하기는 어렵지만 XML 과 관계형 데이터베이스 저장소 중에서 결정하려고합니다 .

중요한 차이점은 XML 은 실제로 직렬화 기술만큼 스토리지 메커니즘 이 아니라는 것 입니다. 게임의 메모리 내 구조를 나타내는 방법입니다. 따라서 플랫 파일 과 관계형 데이터베이스 스토리지에 대해 이야기하고 있습니다. 이것 만이 유일한 옵션은 아니지만 가장 일반적이므로 사용하겠습니다.

플랫 파일의 경우 :

• XML
• JSON
• YAML
• XAML
• 일반 텍스트

데이터베이스의 경우 :

• SQL 서버
• MySQL
• DB2
• 신탁
• 더 많은

편집 : 파일 및 관계형 데이터베이스 외에도 다른 유형의 메커니즘에 대해 질문했습니다. 내가 정기적으로 사용하는 다른 주목할만한 유형의 데이터베이스는 기본적으로 키-값 기반 인 "버클리 스타일"데이터베이스입니다. 이들은 B- 트리를 사용하여 데이터를 구성하는 경향이 있으므로 조회 속도가 빠릅니다. 원하는 것을 정확히 알고있는 구성 / 설정 조회에 유용합니다 (예 : "Level 1"에 대한 모든 원격 측정 데이터 제공).

이제 모든 기본 사항을 벗어 났으므로 몇 가지 기준을 살펴 보겠습니다.

프로젝트의 크기

일부는 동의하지 않을 수 있지만 프로젝트 크기가 데이터 지속성 메커니즘에 큰 영향을 미치지는 않습니다. 원하는 메커니즘에서 데이터를 저장 /로드하는 재사용 가능한 함수 라이브러리를 구축하려고합니다. 필요한 경우 지속성 메커니즘을 쉽게 변경할 수 있도록 추상화 계층을 구현하는 것이 좋습니다 ( 어댑터 패턴 확인 ).

소규모 프로젝트의 경우 파일 시스템에서 XML을 사용하면 제대로 작동 할 수 있지만 플레이어가 마음대로 데이터를 변경할 수 없도록 일부 보안 문제 (예 : 암호화)를 해결하려고합니다.

게임이 목표로하는 플랫폼.

플랫폼도 큰 문제가되지 않습니다. 대상 플랫폼보다 개발 플랫폼에 더 관심을 가져야합니다. 그 이유는 일부 언어는 특정 유형의 마크 업 또는 데이터베이스를 다른 유형보다 즉시 처리하기 때문입니다. 위의 내용을 거의 모든 언어로 사용할 수는 없지만 지원되는 도구를 사용하는 것이 가장 좋습니다. 모든 플랫폼은 플랫 파일을 지원하고 XML을 구문 분석하지만, 모바일 플랫폼에서는 가능하면 이진 직렬화를 고려하거나 최소한 XML을 저장하도록 최적화해야합니다.

데이터 구조의 복잡성

이것은 까다로운 것입니다. 관계형 데이터베이스는 엔티티와 그 관계를 저장하는 데 유용합니다. 파일 시스템의 파일을 사용하는 것보다 관계형 저장소를 사용하여 구조를 강화하는 것이 더 좋습니다. 엔터티 간의 관계 유형과 엔터티를 변경하거나 관련 엔터티를 찾는 빈도를 고려하십시오. 매우 복잡한 구조의 경우 데이터베이스 경로를 사용하는 것이 좋습니다.

많은 프로젝트에서 데이터의 이식성.

이식성과 관련하여 데이터베이스는 파일보다 자연스럽게 더 무겁다는 사실을 고려해야합니다. 설치 및 구성 오버 헤드가 있으며 플랫폼마다 다른 데이터베이스를 사용할 수 있습니다. SQLite는이 문제를 해결하는 좋은 방법입니다. 그러나 이식성과 관련하여 XML과 같은 파일 기반 솔루션을 사용하면 더 쉽게 시간을 보낼 수 있습니다.

편집 : 귀하의 의견 중 하나에 이식성에 대해 언급 한 다른 우려 사항이 있습니다. 궁극적으로 데이터 나 제품 또는 파일 형식에 너무 밀접하게 연결되는 것을 원하지 않습니다. 컴파일하거나로드 할 때 데이터베이스 / 파일 시스템에서 쉽게 구문 분석하고 저장할 수있는 일종의 추상 형식 (탭으로 구분 된 파일, XML 등)으로 주식 데이터 (레벨, 적 등)를 저장할 수있는 것이 가장 좋습니다. 시각. 즉, 저장 메커니즘을 변덕스럽게 바꾸고 구문 분석 부분을 다시 작성할 수 있습니다.

데이터에 얼마나 자주 액세스해야합니까

많은 데이터 액세스는 일종의 캐싱 메커니즘이없는 한 많은 I / O를 의미합니다. 데이터베이스는 구조를 메모리에 유지하며 데이터 조작 및 검색에 좋습니다. 실제로 지속적으로 데이터를 유지하는 경우 데이터베이스를 사용하는 것이 좋습니다.

동일한 응용 프로그램에 대한 여러 유형의 데이터

볼륨은 반드시 고려해야 할 사항이지만 수천 또는 수백만 개의 객체를 유지하는 것에 대해 이야기하지 않는 한 파일 시스템은 여전히 ​​솔루션으로 받아 들일 수 있습니다.

게임 타입

구축하는 게임 유형은 선택한 플랫폼에 큰 영향을 줄 수 있습니다. 예, 대부분의 클라이언트 전용 싱글 플레이어 게임의 경우 압축 또는 암호화 된 파일 시스템 기반 솔루션을 사용하는 것이 좋습니다. 그러나 온라인 구성 요소가있는 게임에 대해 이야기한다면 미친 것입니다. 데이터베이스 경로로 가서 두통을 피하십시오. 서버가 백엔드 클러스터를 사용하여 모든 데이터를 관리하도록합니다.

이 피드백이 도움이 되길 바랍니다. 그것은 완전히 포괄적 인 것은 아니며, 결정을 내리는 것은 궁극적으로 당신에게 달려 있지만, 나의 논평은 당신에게 생각할 것들을 줄 것입니다.

편집 : hybdrid 접근 방식이 많은 의미가있는 경우가 있습니다. 예를 들어 MMORPG를 개발 중이라고 가정 해 봅시다. 클라이언트 쪽에서는 위에서 언급 한 것처럼 다른 플레이어에 대한 캐시 된 데이터를 비 관계형 데이터베이스에 저장할 수 있습니다. 서버 측에서는 모든 게임 데이터를 관계형 데이터베이스에 저장하여 보관합니다. 그리고 다시 클라이언트 쪽에서는 로그 데이터, 구성 데이터 등을 XML / 플랫 파일에 저장하여 쉽게 액세스 할 수 있습니다.

또 다른 포스터는 데이터베이스에 프로덕션을 위해 데이터를 저장하더라도 개발에 플랫 파일을 대신 사용할 수있는 방법을 사용하는 것이 좋지만 때로는 믹스에서 다른 제품을 쉽게 제거 할 수 있다고 언급했습니다. .

최근에 나는 관계형 데이터베이스에 추가하는 강성 / 어려움으로 인해 스스로 제약을 받았다는 것을 알게되었습니다. 게임, 상태 및 유연성에 매우 적합한 문서 기반 데이터베이스 (예 : couchdb)를 탐색하고 싶습니다. 그러나 소규모 프로젝트에 대해 여러 데이터베이스 유형을 설정하는 것은 실용적이지 않습니다. 결과적으로 데이터베이스의 특정 필드에서 이진 Blob 필드를 사용하는 것과 비슷한 해킹을 설정했습니다.

내가하고있는 일은 데이터베이스에서 json 인코딩 데이터와 데이터를 json으로 변환하고 필요할 때마다 다시 출력하는 래퍼를 사용하는 것입니다. 따라서 기본 문자 프로필은 데이터베이스에서 다음과 같이 보일 수 있습니다.

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json은 여전히 ​​데이터베이스에서 잘 읽을 수 있으므로 SQL을 사용하여 금속에 대해 직접 작업하고 때로는 데이터베이스에 직접 액세스하는 경우 원하는 경우 수동으로 수정할 수 있습니다.

이제 그 모든 것이 해킹이므로 복사하는 것은 좋지 않지만 여기에는 전반적인 요점이 있습니다. 하나의 시스템에만 의존하지 마십시오. 관계형 데이터베이스를 사용하고 시스템을 퍼지하십시오. 또는 두 가지 유형의 데이터 스토리지 시스템 (예 : 플랫 파일 및 관계형 데이터베이스)을 사용하면 두 가지 이점을 최대한 활용할 수 있습니다. 사람들이 무엇을 제안하거나 어떤 시스템을 사용하든 관계없이 다른 접근 방식이 더 나은 상황을 찾을 수 있으므로 대안을 추가하고 어디로 가야하는지 확인하십시오.

RTS 유전자에서 게임 데이터는 파일에 저장되었습니다.

단위와 속성은 INI 또는 XML 파일 또는 기타 텍스트 기반 형식으로 저장되었으며 모델은 이진 형식 또는 텍스트 기반 형식이 혼합되었으며 텍스처와 사운드 및 기타 미디어가 주류 형식으로되어 있습니다. 때때로 그것은 조잡한 암호화를 가진 컨테이너에 있었으며 Westwood의 혼합 형식이 떠 오릅니다. 그러나 이것은 대부분 난독 화입니다. 내부를 보면 처리하기 쉬운 형식의 일반 파일 일뿐입니다.

온라인 플레이가 등장함에 따라 인터넷을 통해 게임 데이터를 설치 후 프로비저닝하는 것이 점점 일반화되고 있지만 종종 파일 시스템에 저장됩니다.

왜 하나의 데이터 저장 방법을 사용합니까?

대부분의 경우 전 세계에 출시 된 게임에는 개발 중에 게임에 필요한 것과 동일한 데이터 저장 기능이 필요하지 않습니다.

다음은 일부 릴리스 / 개발 요구 사항을 비교 한 것입니다.

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

이상적으로는 데이터로드 모듈에 대한 인터페이스를 정의한 다음 각각 특정 요구에 맞는 여러 버전을 만듭니다.

몇 년 전 한 프로젝트에서 CD로 레벨 데이터를로드하는 데 너무 오랜 시간이 걸렸습니다 (HD도 좋지 않았습니다). 그래서 나는 다음을 생각해 냈습니다. 레벨 데이터를로드하는 세 가지 방법이 있습니다.

1. 일반 로딩-자산이 변경되는 개발 시간
2. 시험판-일반 데이터를 빠른 로딩 데이터로 효과적으로 변환하는 방법
3. 릴리스-빠른 데이터 만 (편집 할 수 없음)

이는 로딩 시간을 분에서 초로 줄였습니다.