전체 글
튜토리얼 · 7 min read

10만 애셋 라이브러리가 당신을 길들이기 전에 그것을 길들이기

스스로 정렬되는 명명 규약, 폴더 대 태그, 썸네일 파이프라인, 중복 정책, 그리고 기회주의적 마이그레이션: 거대한 게임 애셋 라이브러리를 찾기 쉽게 유지하는 실용적 시스템, 그리고 왜 검색 속도가 당신의 레벨이 얼마나 다채로워 보이는지를 결정하는가.

Illustration of an asset thumbnail grid with a search field and tag chips

환경 품질은 아티스트가 1분 미만에 찾을 수 있는 것에 의해 제한됩니다. 수천 애셋을 넘어서면 폴더 규율은 확장을 멈춥니다: 검색 더하기 태그가 넘겨받고, 썸네일이 스캔 속도를 정하고, 중복은 일소가 아니라 정책을 필요로 하고, 마이그레이션은 영웅적이 아니라 기회주의적이어야 합니다. 여기 성장을 견디는 시스템이 있습니다. 베낄 가치가 있는 구체적 규약과, 각각이 규모에서 왜 중요한지와 함께.

도서관의 열람실, 따뜻한 빛 속의 서가 도서관은 책 더미가 아니다: 책 더하기 찾는 시스템이다. 당신의 애셋 컬렉션은 두 번째 부분이 존재해야만 도서관이다; 아니면 매우 비싼 더미다.

어질러진 라이브러리의 진짜 비용

알맞은 바위를 찾는 데 4분이 걸리면 아티스트는 하나 찾은 뒤 그만둔다: 수천의 구매한 팩이 열리지 않은 채, 장면은 같은 스물의 기억된 애셋으로 수렴한다.

피해는 화면에 보입니다: 플레이어가 느끼는 반복, 결코 출시되지 않는 팩에 쓴 돈, 그리고 모든 세트 드레싱 시간에 대한 조용한 세금. 규칙을 더 날카롭게 말하는 방법이 있습니다: 약 1분 안에 찾을 수 없는 애셋은 사실상 존재하지 않는다. 당신은 그것에 값을 치렀고, 저장하고, 백업한다. 그리고 그것은 결코 레벨에 나타나지 않을 것이다. 찾기 쉬움은 살림이 아니다; 당신의 시각적 다양성의 상한이다. 동일한 애셋 예산을 가진 두 스튜디오는, 하나가 자기 애셋을 찾을 수 있고 다른 하나가 못하면, 눈에 띄게 다르게 보이는 게임을 출시한다.

명명: 지루하고, 정렬 가능하고, 모호하지 않게

규약은 평평한 목록에서 유용하게 정렬될 때만 작동한다: 타입 접두사, 카테고리, 머티리얼 또는 종, 크기, 인덱스가 그것이다. 공백 없음, "final_v2_NEW" 없음.

입증된 형태:

SM_Rock_Granite_Large_01        (static mesh)
SM_Rock_Granite_Large_01_LOD1
T_Rock_Granite_D / _N / _R      (textures: diffuse, normal, roughness)
M_Rock_Granite                  (material)
MI_Rock_Granite_Mossy           (material instance)

규모에서 작동하게 하는 규칙: 개념당 한 단어(Rock, Rock/Stone/Boulder를 바꿔 쓰지 말고), 가장 많이 필터되는 필드를 앞에 두어 정렬이 유용하게 묶이게, 인덱스를 0으로 채워(01, 1이 아니게) 102 앞에 정렬되지 않게, 그리고 규약을 모두가 첫날 읽는 한 페이지에 써라. 정확한 스킴은 정확히 하나가 있다는 것보다 훨씬 덜 중요하다: 그리고 오늘, 당신이 어떤 크기이든 시작하는 것이 중요하다. 왜냐면 5만 파일에 이름을 소급 적용하는 것은 아무도 결코 끝내지 못하고 미루기를 모두가 후회하는 프로젝트이니까.

폴더는 한 가지를 말하고; 태그는 나머지를 말한다

파일은 하나의 폴더에 살지만 많은 속성을 가진다: 폴더는 소유와 파이프라인(어느 팩, 어느 프로젝트)을 부호화해야 하고, 태그는 당신이 검색할 모든 것(바이옴, 머티리얼, 무드, 크기, 스타일)을 부호화한다.

다차원성을 더 깊은 폴더 트리로 싸우면 아무것도 다시 못 찾는 고전적 Props/Nature/Trees/Dead/Moss/ 묘지를 낳는다: 이끼 낀 죽은 자작나무는 다섯 폴더에 동시에 속하고 하나에만 살 수 있으니, 늘 잘못된 넷에 있기 때문. 작동하는 분할은 검색을 주된 진입로로, 폴더 트리를 단순 배관으로 만든다.

대부분의 환경 작업을 덮는 태그 어휘는 팀이 예상하는 것보다 작다: 바이옴(숲, 사막, 도시…), 머티리얼(나무, 화강암, 녹슨…), 상태(흠 없는, 닳은, 폐허), 크기 등급, 그리고 스타일: 다섯 축, 아마 마흔 개 용어, 한 번 합의되고 강제된다. 규율은 어휘를 닫힌 채로 유지하는 것: 누군가 발명하는 새 동의어마다("풍화된"을 "닳은" 옆에) 두 태그 모두의 가치를 반으로 줄인다. 하나의 검색이 다른 하나를 놓치기 때문.

썸네일이 검색 품질을 결정한다

파일명 목록은 도서관이 아니다: 일관된 썸네일(같은 각도, 중립 조명)은 눈이 분당 수백 후보를 스캔하게 한다. 그것이 세트 드레싱이 실제로 필요로 하는 속도다.

인간 시각은 이름을 파싱하는 것보다 썸네일 격자를 훨씬 빨리 평가한다; 그것을 작동하게 하는 것은 일관성이다. 제시가 동일할 때 애셋의 차이가 보이는 채로 남으니까. 무작위 각도에 무작위 조명으로 찍힌 바위는 자기 형태를 숨긴다; 같은 바위가 표준 4분의 3 뷰에서 중립 빛 아래 그것을 즉시 드러낸다. 배치로 렌더하라: 썸네일 파이프라인은 어떤 큰 프로젝트의 첫 주에 본전을 뽑는다.

썸네일은 또한 바로 규모가 아픈 곳이다: 십만 개를 탐색하려면 가상화, 캐싱, 그리고 따라잡는 동안 에디터를 멈추는 게 아니라 백그라운드에서 렌더하는 파이프라인이 필요하다. 그 엔지니어링 문제가 바로 우리가 Numivo에 백만 애셋에서 매끄럽게 유지되는, 즉각 썸네일과 "어딘가 그 이끼 낀 절벽 조각"을 두 단어 검색으로 바꾸는 선택적 AI 태깅을 갖춘 콘텐츠 브라우저를 만든 이유다. 브라우저 문제와 명명 문제는 다른 층위의 같은 문제다: 둘 다 "내게 뭔가 필요해"와 "나는 그것을 보고 있어" 사이 거리를 접는 것에 관한 것.

수천의 거의 동일한 단위로 된 벽돌 벽 중복 문제를 물리적으로: 수천의 거의 동일한 단위. 기술은 찾을 수 있는 정본 버전 하나를 유지하고 나머지를 조용히 강등하는 것. 벽이 아직 기대고 있는 무언가를 삭제하는 게 아니라.

중복: 하나 유지, 나머지 태그

근접 중복을 보자마자 삭제하지 마라(참조가 깨진다): 정본 버전을 고르고, 나머지를 duplicate로 태그하고, 기본 검색에서 걸러내고, 아무것도 그것들을 참조하지 않게 되면 진짜로 퇴역시켜라.

수명 긴 모든 프로젝트는 겹치는 팩을 쌓는다: 네 공급사의 네 화강암 바위, 손잡이만 다른 세 통. 2단계 정책(지금 강등, 나중에 삭제)은 찾기 쉬움의 승리를 즉시 붕괴 위험 제로로 잡는다: 중복은 검색에서 사라지지만 이미 참조하는 어느 장면을 위해 디스크에 남는다. 참조 스윕을 분기마다 돌려라; 6개월의 무참조는 보통 묘지를 안전하게 통째로 치운다.

피해야 할 실패 모드는 중복을 찾은 날 삭제하는 것: 뭔가 늘 당신이 삭제한 것을 참조하고, 레벨이 깨지고, 팀은 청소를 두려워하기를 배운다: 그 후로는 아무도 아무것도 청소하지 않는다. 강등-후-삭제는 청소를 안전하게 유지하고, 안전한 청소가 계속 일어나는 유일한 청소다.

마이그레이션: 혼돈에서 시스템으로

빅뱅 청소를 위해 프로덕션을 결코 멈추지 마라: 오늘부터 새로운 모든 것에 규약을 적용하고, 그다음 오래된 콘텐츠를 기회주의적으로 마이그레이션하라: 레벨이 끌어들이는 것은 무엇이든 지나가는 길에 이름 바뀌고 태그된다.

기회주의적 규칙에는 아름다운 성질이 있다: 중요한 애셋이 먼저 마이그레이션한다, 정의상. 그것들이 쓰이는 것들이니까. 1년 뒤 손대지 않은 무엇이든 콜드 스토리지에 속하지, 검색 결과가 아니며, 애초에 마이그레이션이 필요 없었다. 대신 영웅적 주말 청소를 시도하는 팀은 절반만 이름 바뀐 라이브러리를 낳기 쉽다: 두 극단보다 엄격히 나쁘다. 이제 검색 결과가 두 규약을 섞고 어느 것도 신뢰할 수 없으니까.

훔칠 만한 현장 수치

  • 찾기 쉬움 예산: 1분 미만, 아니면 애셋은 기능적으로 존재하지 않음
  • 환경 작업을 덮는 태그 어휘: ~5축, ~40개의 닫힌 용어
  • 일관된 렌더링에서 썸네일 스캔 속도: 분당 수백
  • 중복 정책: 즉시 강등, ~6개월 무참조 후 삭제
  • 명명: 0으로 채운 인덱스, 개념당 한 단어, 한 페이지 규칙

미니 FAQ

AI 태그가 수동 태깅을 대체할 만큼 좋은가요? 대부분을 대체할 만큼 좋다: 자동 태그가 대부분(주제, 머티리얼, 색)을 지고, 인간이 판단(스타일 적합, 프로젝트 특유 용어)을 더한다. 조합이 각각 단독을 이기므로, AI 태깅은 완전한 대체가 아니라 옵트인 보조 층으로 가장 잘 작동한다.

공유 라이브러리 하나인가, 프로젝트별인가? 공유 소스 라이브러리, 프로젝트별 임포트. 라이브러리는 모든 것을 완전한 태그로 보관한다; 프로젝트는 출시하는 것만 끌어들여 빌드를 날씬하게, 쿡 시간을 짧게 유지한다. 둘을 섞는 것(라이브러리 전체를 참조하는 프로젝트)이 빌드 크기가 부풀어 오르는 방식이다.

바이너리 애셋의 버전 관리는요? 라이브러리는 정원이지 아카이브가 아니다: 소스 파일을 DCC 파이프라인에서 버전 관리하고, 라이브러리를 현재-최선-만으로 유지하라. 검색 결과에 사는 역사적 버전은 이름표를 단 노이즈이고, 모두를 위한 모든 검색을 느리게 한다.

팀이 실제로 규약을 따르게 하려면? 옳은 것을 쉬운 것으로 만들어라: 명명 패턴을 미리 채우는 저장/임포트 템플릿, 규약을 벗어난 파일을 표시하는 린트 단계, 그리고 규약 준수 애셋을 찾을 수 있게, 벗어난 것을 안 보이게 하는 썸네일. 도구로 강제된 규약은 붙는다; 잔소리로 강제된 규약은 안 붙는다.

못생기게 시작하라, 지금 시작하라: 한 페이지 명명 시트, 열 개의 핵심 태그, 일관된 썸네일이 다음 분기에 시작하는 아름다운 분류법을 이긴다. 라이브러리는 정원이다: 끊임없는 작은 김매기, 결코 한 번의 영웅적 청소가 아니라.