자산 관리, 데이터베이스 또는 버전 관리 시스템?

게임 자산 (메시, 텍스처, 사운드, 비디오)을 개발하면서 관리합니까?

1. 버전 관리 시스템에서 소스 코드와 함께 유지합니까? (perforce, git 등…)
2. 아니면 자산을 전담하는 중앙 백업 데이터베이스가 있고 편집자가 항상 작업하는 것을 좋아합니까? (PostgreSQL, MySQL 등…)
3. 다른?

각각의 장단점은 무엇이며 왜 하나를 선택해야합니까?

우리 중 많은 사람들, 특히 소규모 게임 을하는 경우 소스와 동일한 저장소에 자산이 있어야합니다 .

자산이 별도의 저장소에 속한다는 제안은 매우 큰 자산 세트 또는 명확하게 정의 된 엔진 / 데이터 경계가있는 경우 다소 큰 자산 세트에만 적합합니다. 특별한 기술적 이유가 없다면 나쁜 조언입니다!

버전 컨트롤이 버전 컨트롤처럼 동작 하기를 원합니다 . 되감기 및 빨리 감기 및 브랜치 및 병합 수정을 계속하면서 게임을 계속 작동 시키려고합니다. 그리고 코드와 자산 은 서로 의존 할 것 입니다.

예를 들어 : 코드에서 셰이더에 매개 변수를 설정할 수 있으며 해당 셰이더는 텍스처에 따라 달라질 수 있습니다. 또는 레벨의 데이터 형식이 특정 버전의 게임 코드에 따라 달라질 수 있습니다.

거의 확실하게 지저분해질 것입니다. 깔끔하게 유지하는 것보다 할 일이 더 좋습니다.

Mike Wagner가 ( 이 답변에 대해 ) 주석을 달았 듯이 버전 관리하에있는 모든 "진행중인"버전의 자산을 원하거나 필요로하지 않습니다! 코드에서 사용하는 최종 / 작동 버전 만 가능합니다. 종종 도구에서 내보내는 것입니다.

(진행중인 버전의 자산을 버전 제어하려는 경우에도 괜찮습니다. 별도의 저장소에 적합합니다. 개인적으로 좋은 폴더 구성과 적절한 백업 시스템으로 충분합니다.)

즉, 버전 관리 하에서 "진행중인"자산을 고수하는 옵션을 갖는 것이 좋은 경우가 있습니다. 일반적으로 여기에는 다중 내보내기 이미지를 단일 텍스처로 병합하는 등의 '내보내기'단계를 처리 할 수있는 콘텐츠 파이프 라인이 포함됩니다.

버전 관리 시스템.

롤업 방식을 사용하면 버전 관리 시스템을 효과적으로 롤링 할 수 있으므로 이미 수년간의 설계 / 코드 / 테스트주기를 거친 상용 시스템을 사용하는 것이 좋습니다.

자산을 소스와 별도의 리포지토리에 보관하여 체크 아웃 / 동기화 시간을 최소로 쉽게 유지하고 보관할 이력 양에 대해 다른 결정을 내립니다 (디스크 공간이 저렴하지만 가능할 때마다 모두 보존). 프로젝트 기간 동안 그렇게 많이 변경하지 마십시오).

XML 파일을 이진으로 표시하고 병합 도구는 중첩 된 마크 업을 병합하는 데 매우 좋지 않은 경향이 있으며 도구가 충돌이 없다고 생각하면 아티스트가 깨진 마크 업을 발견하지 못할 것입니다.

가능하면 모든 커밋마다 구문 검사 또는 자산 빌드를 준비하고 커밋이 실패하면 커밋하는 사람에게 이메일로 커밋을 거부하십시오. 이를 통해 많은 시간을 절약 할 수 있습니다.

크기 측면에서 여유가 있다면 하나의 저장소에있는 모든 것. 1TB 근처의 Subversion 저장소에 대해 들었습니다. 현재 400GB 미만입니다.

또한 예술가들은 개념의 대략적인 30 가지 개요를 포함하여 모든 것을 조사합니다. "소스 자산"과 "내 보낸"(자산 빌드 스크립트에 들어가는)에 별도의 폴더 트리를 사용합니다. 내일 버스로 아티스트가 타격을 받으면 다음 날 누군가 자신의 자산에 대한 작업을 계속할 수 있어야합니다. 한때 게임이 2D 였고 스프라이트가 복잡한 애니메이션 Max 장면에서 사전 렌더링되었을 때, 우리는 RTS 게임에 약간의 엉터리가 있고 매우 일관된 모양 (나머지 유닛의 나머지 부분)으로 RTS 게임에 여러 유닛을 배송해야했습니다. 원래 아티스트가 종료되었고 원래 Max 장면이 없었기 때문에 약간 다른 조명 및 앤티 앨리어싱 설정으로 다시 렌더링해야했습니다. 님'