콘텐츠 파이프 라인 도구를 엔진에 포함해야합니까?

게임 엔진은 얼마나 작아야합니까? 얼마나 많은 콘텐츠 파이프 라인을 엔진에 내장해야합니까?

슈퍼 엔진이 유용한 몇 가지 사용 사례 :

• 사용자 콘텐츠를로드 할 때 사용자는 텍스처를 패키징 할 필요가 없습니다. 엔진은로드시 처리합니다.

• 스크립트는 사전 생성 된 것보다 훨씬 큰 글꼴을 요청합니다. 엔진은 ttf 파일을 구문 분석하여 새로운 텍스처 아틀라스를 만들 수 있습니다.

• 헤일로 위조 .

이 중 어느 것도 물론 무료는 아닙니다. 이를 위해서는 컨텐츠 파이프 라인 도구를 C ++로 작성해야합니다. 파이프 라인에서 사용하는 지원 라이브러리는 장치에서 사용하기 위해 컴파일해야합니다. 컨텐츠 생성에 버그가 없어야합니다. 그리고 일반적으로 엔진을 더 크고 다루기 어렵게 만듭니다.
다른 장단점이 무엇입니까?
전문가가 단점보다 더 중요합니까?

몇 가지 구체적인 질문 :

• 엔진이 다양한 이미지 형식을로드 할 수 있어야합니까? TGA 전용 로더는 코딩이 매우 쉽습니다.

• 오디오 형식은 어떻습니까? WAV 파일 로딩 만 지원할 수 있습니까? 종종 거대한 주변 음악 파일은 어떻습니까?

• 엔진이 동적 TTF 구문 분석 및 아틀라스 생성이 가능해야합니까?

• 텍스처 패킹.

블로그 내에서 Noel Llopis의 게임은 최근 "원격 게임 편집"게시물 에서 이에 대해 언급했습니다 . 첫 단락 :

나는 오랫동안 최소 게임 런타임의 팬이었습니다. 오프라인 또는 별도의 도구로 수행 할 수있는 모든 작업은 런타임에서 벗어나야합니다. 게임 아키텍처와 코드는 매우 단순 하고 단순하다 .

(이 기사는 귀하가 100 % 동의하는지 여부에 관계없이 Noel의 대부분의 자료와 마찬가지로 강력히 권장되는 기사입니다.)

여기서 핵심은 엔진 외부의 복잡성을 유지하는 것입니다. 여전히 유연성을 가질 수 있지만 컨텐츠 파이프 라인에서는 유연성이 있습니다. 또한 데이터를 변환하고 이동하는 데 시간을 소비하지 않으면 서 성능이 향상됩니다.

더 나은 성능은 엔진 내 편집 기능의 일부를 잃어 버렸음에도 불구하고 반복 시간이 더 짧아 질 수 있습니다.

" 유닉스 철학 " 의 신조 중 일부를 채택 하면 작은 모듈 식 파이프 라인과 같은 툴체인을 유연하게 유지할 수 있습니다.

나의 개인적인 철학 : 가능한 많은 데이터를 오프라인에서 가능한 한 많이 굽지 만 언제든지 새로운 구운 데이터를 수신 할 수 있도록 엔진을 지원합니다. (이 새로운 데이터는 "새로 고침"버튼을 누르고 다음 레벨을 시작하면 새로운 영역으로 전환 할 때까지 편리한 시점까지 게임을 시작할 필요가 없습니다. 최소한의 코드 복잡성과 코딩 노력으로 반복 시간)

회사에서 아티스트 / 디자이너를 향한 대부분의 도구는 UI 문제에 중점을 둡니다. 단일 애셋이나 배치의 조작 용이성 등. 때로는 Photoshop 또는 3DS Max와 같은 타사 도구 일뿐입니다. 이러한 도구는 중간 형식 (보통 소스 이진 데이터를 참조하는 xml)으로 내 보냅니다. 중간 형식은 백엔드 "데이터 메이크"도구에 의해 선택되어 대상 플랫폼에 유용하고 빠른 로딩을 제공합니다.

추가 백엔드 데이터 작성 도구를 추가하거나 기존 백엔드 데이터 작성 도구를 확장하여 이식성을 달성 할 수 있습니다. 이는 컨텐츠 작성자에게는 보이지 않는 이점이 있습니다.

이제 적절한 증분 데이터를 만들면 몇 초 내에 베이크 형식을 변경할 수 있습니다. 엔진이 스파이더 또는 툴이 스파이더 일 수 있으며 리소스 시스템에 표시되어 편리 할 때 다시로드 할 수 있습니다.

도구, 특히 백엔드 데이터 작성 도구는 종종 엔진 코드보다 더 거칠고 버그가 많습니다. 리팩터링 / 재 작성, 확장 및 테스트하기가 더 쉽기 때문에 이것은 괜찮습니다. 당신은 그들의 행동에 대한 사양을 가지고 있으며 일부 엔진 코드와 비교하여 그것들을 단위 테스트하기가 쉽습니다.

귀하의 질문에 대한 의견 :

엔진이 다양한 이미지 형식을로드 할 수 있어야합니까? TGA 전용 로더는 코딩이 매우 쉽습니다.

(제외 : 엔진에서 TGA 디코더를 사용하는 경우에도 핸드 코딩하지 마십시오. 문제를 묻는 것입니다. 대부분의 이미지 형식에는 미묘한 점이 많고, 준수하지 않는 도구가 많이 있습니다 정확하게 지정되지 않은 형식으로 정확하게 처리하십시오. 이미지 처리를 위해 잘 테스트 된 기존 라이브러리 코드를 찾는 것이 가장 좋습니다.)

여기에서 도구를 TGA에서 내부 텍스처 형식과 메타 데이터로 변환해야합니다.

오디오 형식은 어떻습니까? WAV 파일 로딩 만 지원할 수 있습니까? 종종 거대한 주변 음악 파일은 어떻습니까?

여기서는 추적 된 음악 (.xm), ADPCM (.wav) 및 Speex (.spx)의 세 가지 형식을 사용합니다. 주로 핸드 헬드를 사용하고 있기 때문에 이러한 형식은 디코딩하기에 매우 가볍습니다.

엔진이 동적 TTF 구문 분석 및 아틀라스 생성이 가능해야합니까? 텍스처 패킹.

Atlasing은 어려운 문제입니다. 최근 질문 의 답변을 참조 하십시오 . 거의 항상 오프라인으로 할 가치가 있습니다.

또한 문자 별 메타 데이터를 거의 제로로드 코드 베이크 된 구조체로 만들 수 있습니다.

마지막으로, 모드 커뮤니티를 위해이 파이프 라인을 게임으로 정리하고 패키징 할 수 있습니다. 언제든지 더 많은 소스 형식을 추가 할 수 있습니다. 특정 상황에서 콘텐츠 제작 도구와 엔진 간의 격차를 해소하는 데 방해가되지 않습니다. 데이터 베이킹 코드와 스파이더 / 전송 코드를 라이브러리로 리팩토링하여 결국 콘텐츠 제작 도구에서 직접 사용할 수 있기를 바랍니다. 그러나 나는 그것이 나의 첫 번째 목표는 아닙니다. 필연적으로 ... 그것이 궁극적 인 목표가 될 것이며, 그것이 당신의 디자인에 약간의 영향을 미치게하고, 낮은 매달린 과일을 먼저 가지십시오.

업데이트 로 텍스처에 KTX 파일 형식 사용을 고려할 수 있습니다 . 그것은 struct대부분의 GL 사용 사례 (그리고 의견에서 GL을 타겟팅하는 것처럼 들립니다)에 대해 대부분 "읽고 이동" 하는 장점이 있지만 여전히 유연하고 명확합니다.

KTX 헤더 오버 헤드는 대상에 따라 완전히 구운 데이터의 경우 약간 높을 수 있으며 사용 사례에 따라 엔디안 스왑 지원을 포기하고 싶을 수도 있지만 디자인 고려 사항에는 최소한의 가치가 있습니다.

질문은 매우 주관적으로 들리고 대상 고객이 누구인지에 크게 의존합니다.

font / ttf 파싱 질문을 보자. 자체 글꼴을 추가하는 모더를 계획하고 있다면 가능한 한 적은 단계로 가져 오기 프로세스를 만들고 싶을 것입니다. 내부적으로 게임에 많은 글꼴 / 글꼴 크기를 추가하는 경우 아티스트가 약간의 교육만으로 사용할 수있는 다소 정교한 도구가 필요할 수 있습니다. 내부적으로 한 번 수행하려는 경우 적절한 수입 업체를 만드는 데 소요되는 시간은 이전 사례의 도구를 작성하는 데 걸리는 시간보다 적을 수 있습니다.

실제로 다른 모든 것의 규모 문제입니다. 임베디드 도구는 많은 시간을 할애하고 그로 인한 복잡성 / 버그를 줄이고 싶을 때 노력할 가치가 있습니다. 추가하는 한정자 (예 : PSD를 가져 오는 대신 TGA 텍스처 만)를 추가하면 최종 사용자가 더 많은 시간을 소비하게됩니다.

콘텐츠 도구는 일반적으로 기술적으로 덜 기울어집니다 (읽기 : 아티스트). 개인적으로 나는 Unity가 소스 파일 (psd, 3ds, ttf, mp3, jpg, mov 등)을 드래그 할 수있는 Unity 작동 방식을 정말로 좋아하며 자동으로 내부 형식으로 변환합니다. 내부 형식은 대부분 최종 사용자에게 숨겨져 있습니다. 또한 소스 파일 변경을 감지하면 자동 재 변환됩니다. 그러나 그것은 많은 작업입니다.