1. 프로젝트 타이탄: 커뮤니티와 함께 오픈 월드 게임을 만들다 [0]

thumbnail 프로젝트 타이탄은 수천 명의 참여자와 함께 오픈 월드 게임을 만드는 과정을 공개하고 협업하여 완성한 사례이다.

1.1. 프로젝트 타이탄 소개 및 목표 [0]

  1. 프로젝트 타이탄은 모바일 친화적인 오픈 월드 샘플 게임을 만드는 프로젝트이다 [2]
    1. 인간이 할 수 있는 가장 어려운 방식으로 만들고자 했으며, 이는 아트 잼(Art Jam) 형태로 진행되었다 [3]
  2. 프로젝트의 목표는 다음과 같다 [5]
    1. 수천 명의 참가자와 함께 아름다운 세상을 만들고, 그 안에 아름다운 것들을 채워 넣는다 [5]
    2. 완성된 게임을 샘플 프로젝트로 패키징하여 전 세계에 무료로 공유한다 [5]
    3. 대규모 교육 및 영감 제공 [33]
    4. 좋은 개발 사례 공유 [34]
    5. 개선이 필요한 부분 파악 및 언리얼 팀에 전달 [37]

1.2. 에픽 게임즈 테크 콘텐츠 팀 소개 [6]

  1. 테크 콘텐츠 팀은 교육적이고 영감을 주는 콘텐츠를 제작한다 [9]
    1. GDC에서 교육과 영감을 제공하여 사용자들이 더 많은 것을 배우고 스스로 무언가를 만들도록 동기를 부여한다 [11]
    2. 언리얼 엔진 사용자들을 위한 기술 콘텐츠, 특히 샘플 게임 제작이 주된 역할이다 [13]
  2. 주요 제작 샘플 게임 및 프로젝트 [14]
    1. Stack of Bot과 Cropout: 언리얼 엔진 5의 샘플 게임으로, 다운로드하여 분석 가능하며 관련 문서와 비디오 자료가 제공된다 [14]
    2. C 샘플, LRA 같은 언리얼 엔진 템플릿, 콘텐츠, 예제 프로젝트도 지속적으로 업데이트한다 [16]
    3. 이러한 경험들이 다음 프로젝트인 Titan으로 이어졌다 [17]

1.3. 프로젝트 타이탄의 탄생 배경 [18]

  1. 기존 샘플 프로젝트들은 완성도 높은 제품이었지만, 개발 과정에 대한 정보가 부족했다 [18]
    1. 마치 수백 명의 팀원들과 분산된 작업 공간에서 일하는 개발팀의 일원이 되는 것과 같은 경험을 제공하고 싶었다 [19]
    2. AAA 게임 개발 경험이 없는 사람들도 오픈 월드 게임 제작 경험을 제공하고 교육 및 영감을 줄 수 있는 완벽한 방법이라고 생각했다 [23]
    3. 6년 동안 오픈 월드 게임을 만드는 직업을 구할 필요 없이 이러한 경험을 제공할 수 있다 [25]

1.4. 프로젝트 타이탄의 개발 방식 및 아이디어 [26]

  1. 타이탄 아트 잼 아이디어는 다음과 같다 [27]
    1. 애런과 샘이 세상을 만들고, 세바스찬이 캐릭터 카메라와 게임 프레임워크를 담당했다 [28]
    2. 유다가 전체 작업을 실행했지만, 대부분 팀원들의 작업을 보며 절망에 빠지기도 했다 [29]
    3. 아트 스테이션 챌린지를 통해 전 세계 사람들을 초대하여 땅을 채우고 마법 같은 무언가를 만들어내도록 했다 [30]
  2. 완성 후 콘텐츠 배포 계획 [31]
    1. 완성되면 정리하고 배포하여 무료 샘플 게임으로 제공한다 [31]
    2. 에셋도 Fab에 무료로 올려 사람들이 유용하게 사용할 수 있도록 한다 [32]

2. 프로젝트 타이탄 개발 과정: 기술적 도전과 해결 [39]

thumbnail 프로젝트 타이탄은 방대한 오픈 월드 구축을 위한 맞춤형 솔루션 개발, 캐릭터 이동 시스템 도입, 그리고 안정적인 인프라 구축이라는 기술적 과제를 해결하며 진행되었다.

2.1. 월드 구축: 랜드매스 커스터마이징 및 월드 파티션 [39]

  1. 통합 캔버스 구축의 필요성 [41]
    1. 모든 작업물이 서로 연결되고 팀원들이 실시간으로 협업할 수 있도록 거대한 통합 캔버스가 필요했다 [41]
    2. 게임 개발은 단순히 각자 작은 레벨에서 작업하는 방식으로는 불가능하다 [43]
  2. 랜드매스(Landmass)와 월드 파티션(World Partition) 활용 [44]
    1. 언리얼 엔진의 랜드매스는 반복적이고 비파괴적인 방식으로 거대한 풍경 구현을 가능하게 한다 [44]
    2. 특히 원 파일 프로액터(One File Per Actor)와 월드 파티션을 함께 사용하면 매우 세밀한 지형 구현이 가능하다 [45]
    3. 문제점: 랜드매스는 몇 킬로미터 이상 확장하면 제대로 작동하지 않는다 [47]
    4. 해결책: 월드를 1km 단위의 랜드매스 청크로 나누는 맞춤형 솔루션을 개발했다 [48]
      1. 이를 통해 레이어 제한 없이 필요한 만큼 레이어를 사용할 수 있게 되었다 [49]
  3. 맞춤형 랜드매스 도구 개발 [50]
    1. 애런이 이 모든 것을 블루프린트로 개발했으며, 프로젝트 출시 시 함께 제공될 예정이다 [50]
    2. 작동 방식: 월드의 그리드 형태로, 회색 영역은 현재 편집 중인 부분으로 도구가 빠르게 작동한다 [53]
    3. 기능: 여러 개의 스탬프를 만들고 크기 조절, 올리고 내리는 등 다양한 작업을 할 수 있으며, 스탬프들을 조합하여 지오메트리를 만들 수도 있다 [56]
    4. 히트맵 효과: 환경에 표시되는 히트맵은 레이어 수를 보여주며, 최종적으로 600개의 레이어가 생성되었다 [58]
    5. 결과물: 8제곱킬로미터 크기의 거대한 월드가 완성되었으며, 9개의 생물군계가 존재한다 [62]
    6. 협업: 두 명이 4개월 동안 협업하여 월드를 만들었으며, 개선된 부분은 미미했지만 더 큰 규모의 협업에 적합한지 확인할 수 있었다 [66]
    7. 향후 계획: 9개의 바이옴 각각에는 다양한 레이어가 존재하며, 나머지 부분은 참가자들이 채워주기를 바란다 [69]

2.2. 게임플레이 시스템: 주야간 주기 및 캐릭터 이동 [72]

  1. 실시간 주야간 주기 플러그인 [72]
    1. 완벽하게 조절 가능한 실시간 주야간 주기 플러그인을 샘플에 포함시켰다 [72]
    2. 편집 도구에 통합되어 참가자들은 매일 하루 중 시간을 변경하며 작품이 다양한 시간대에 어떻게 보이는지 확인할 수 있다 [73]
    3. 고려 사항: 밤이나 아침에 작품이 이상하게 보이지 않도록 모든 시간대에 보기 좋게 표현하는 것이 중요하다 [74]
  2. 캐릭터 이동 시스템 (MUA) [76]
    1. 언리얼 엔진의 캐릭터 무브먼트 2.0 시스템인 MUA를 도입했다 [76]
    2. 특징: 모듈식 엔진으로, 깔끔하고 향상된 입력 통합, 부드러운 전환 모드, 다양한 커스터마이징 옵션을 제공한다 [77]
    3. 기능: 롤백 기능 지원, 네트워크 호환성이 뛰어나 멀티플레이어 게임에서도 사용 가능하다 [78]
    4. 초기 프로토타입: 완전한 오픈 월드 무브먼트 세트, 가변 걷기 속도, 점프 높이, 그래플링 훅, 글라이더 등을 구현했다 [79]
    5. 워크 슬라이딩(Walk Sliding): 지형과 물의 물리 엔진이 통합되어 지형과 물을 탈 수 있는 모드이다 [81]
    6. 개발 당시 문제점: 개발 당시에는 매우 불안정했지만, 지금은 많이 개선되었다 [84]
    7. 이동 방식의 재미: 이동 방식이 정말 재미있고, 가파른 언덕이 많은 이유는 샘이 걸어서 이동하는 스노보드 게임을 만들고 싶어했기 때문이다 [87]

2.3. 인프라 구축: 서버, 클라우드, 기술 지원 [88]

  1. 가장 어려웠던 문제: 지형이나 플레이어가 아닌 인프라였다 [88]
    1. 수천 명의 잠재 사용자가 에픽의 퍼포스(Perforce)에 접속하는 것을 감당할 수 없었다 [89]
    2. 서버, 클라우드 공간, 기술 지원이 필요했다 [91]
  2. 협력: 아마존과 퍼포스(Perforce)가 열정적으로 지원했다 [92]
    1. 직원 지원과 클라우드 공간을 기부받아 어려운 일을 해낼 수 있었다 [93]
    2. 퍼포스와 아마존이 없었다면 불가능했을 것이다 [94]

3. 커뮤니티 참여 및 관리: 아트 잼의 성공 요인 [96]

thumbnail
  1. 커뮤니티 참여 독려 및 관리 [96]
    1. 아마존과 퍼포스(Perforce)의 지원: 생명줄과 같았으며, 타이탄의 빠른 인기 상승에 기여했다 [97]
    2. 퍼포스(Perforce) 학습: GDC 이후 10주 동안 퍼포스에 대해 배운 것이 많았다 [100]
    3. 아트 스테이션 챌린지: 레벨 디자인, 환경 아트, 소품, 재료, 캐릭터, VFX 등 다양한 분야에 대한 개별 챌린지를 발표했다 [103]
      1. 사람들은 관심 있는 분야에 참여할 수 있었고, 에픽 마케팅 커뮤니티와 협력하여 최대한 많은 사람들의 참여를 이끌어냈다 [104]
    4. 커뮤니티 관리: 429명이라는 예상보다 많은 인원이 참여하여 커뮤니티 관리에 더욱 심혈을 기울였다 [109]
      1. 디스코드 서버 구축: 공지, 규칙, 크리에이티브 디렉션, 기술 가이드, 바이옴별 채널 등을 마련했다 [112]
      2. 커뮤니티 형성: 디스코드를 통해 분야별, 바이옴별 그룹을 만들고 리더십을 보이는 사람들을 커뮤니티 리더로 선출했다 [117]
  2. 참가자 지원 및 교육 콘텐츠 제공 [118]
    1. 주간 라이브 스트림: GDC 다음 주 금요일부터 시작하여 사람들을 디스코드와 퍼포스 서버로 초대했다 [120]
    2. 크리에이티브 브리프 및 튜토리얼 가이드 제공: 산업화 이전 시대의 마법 세계를 배경으로 하며, 미적으로 스타일리시하고 과장되고 회화적인 느낌을 주는 것을 목표로 했다 [124]
      1. 오래전에 죽은 타이탄들의 시체가 풍경의 일부를 이루고, 다양한 생태계가 존재한다 [127]
    3. 기술 가이드: 머티리얼 아트 가이드, 언리얼 엔진 설치 가이드, 퍼포스 설정 가이드 등 사람들이 바로 시작할 수 있도록 도왔다 [133]
      1. 게임 개발 경험이 없는 사람들을 위해 최대한 빨리 시작할 수 있도록 돕는 것이 중요했다 [135]
    4. 기본 콘텐츠 제공: 기본 콘텐츠, 마스터 자료, 문서 등을 제공하여 탄탄한 출발점을 마련하도록 도왔다 [140]
    5. 전문가 피드백: 전문 지식을 가진 전문가들을 초빙하여 디스코드와 주간 라이브 스트림을 통해 조언과 피드백을 받았다 [143]
      1. 유튜브 캐릭터 아티스트 Fon과 같은 훌륭한 분들과 라이브 비평을 진행했다 [144]
    6. 교육 콘텐츠 제작: 사용자 요구에 맞춰 즉석에서 영상 자료를 제공했으며, Aaron의 기술 가이드와 샘의 디자인 관련 자료 등이 포함되었다 [147]
      1. PCG 사용법과 제작 방법에 대한 자료는 필수적이었다 [149]
      2. 일부 참가자들은 타이탄에 유료 교육 과정보다 더 많은 콘텐츠가 있다고 평가했다 [151]
  3. 프로젝트 규칙 및 관리 [153]
    1. 안전하고 안정적인 프로젝트 환경 제공: 대부분의 참여자에게 안전하고 안정적인 프로젝트 환경을 제공하는 것이 목표였다 [153]
      1. 에셋 방치, 프로젝트 특정 부분 수정, 플러그인 추가, 대규모 커밋 등을 제한했다 [154]
      2. 참가자들에게 서로 협력해 달라고 부탁했으며, 4129명 중 단 한 명만 차단했다 [155]
      3. 의견 충돌 시 Aaron과 샘이 개입하여 성숙하게 해결했다 [157]
    2. 에셋 검증 도구 미사용: 소스 코드 관리 자체가 부담스러워 추가적인 부담을 주고 싶지 않았다 [159]
      1. 결과적으로 서버에 꾸준히 콘텐츠가 유입되어 프로젝트가 활성화되었다 [163]
    3. 참여 현황: 10주 동안 4129명의 챌린지 참여자가 있었고, 1490개의 워크스페이스가 있었다 [165]
      1. 약 600명의 활동적인 사용자가 꾸준히 콘텐츠를 업데이트하고 세계를 구축하는 데 기여했다 [172]
    4. 체크인 현황: 10주 차까지 15,000개의 변경 목록이 있었고, 23만 개의 파일이 체크인되었다 [176]
      1. 콘텐츠의 자유로운 흐름을 확보할 수 있었다 [181]

4. 기술적 문제점 및 해결 과정 [237]

thumbnail

  1. 나나이트(Nanite) 관련 문제점 및 해결 [237]

    1. 문제점: 참가자들이 로우 폴리곤으로 지오메트리를 모델링하는 데 익숙해져 있어, 나나이트의 장점을 활용하지 못하고 계단식 모서리와 곡선 모서리가 혼합된 공간이 만들어졌다 [239]
    2. 권장 사항: 곡선을 추가하고 지오메트리를 더하는 것을 적극 권장한다 [244]
      1. 이는 성능 저하를 초래하지 않으며, 저사양 플랫폼을 위해 LOD를 적용하여 최적화할 수도 있다 [245]
      2. 폴리곤 수를 무제한으로 제공하는 것은 아니지만, 저 폴리곤 구조물을 만든다고 해서 성능 향상에 도움이 되는 것은 아니다 [246]
    3. 반대 문제: 지형의 토폴로지가 최종 모델에 적합하지 않은 경우도 있었다 [248]
      1. 매우 높은 밀도로 생성된 지형의 가장자리에 삼각형이 늘어나는 문제가 발생했다 [253]
    4. 해결 노력: 사람들이 작업을 최적화하고 개선하는 데 도움이 되는 피드백과 콘텐츠를 제작했다 [258]

  2. 성능 문제 및 최적화 [260]

    1. 문제점: 복잡한 오픈 월드 환경은 저절로 잘 돌아가지 않으며, 실행이 어렵거나 느리고 월드 편집에도 시간이 오래 걸렸다 [261]
    2. 핵심 과제: 사람들이 자신의 작업에서 성능을 고려하도록 하는 것이었다 [264]
    3. 스켈레탈 메시 과다 배치: 월드에 NPC를 너무 많이 배치하는 경향이 있었으며, 이는 성능에 심각한 영향을 미쳤다 [266]
      1. 렌더링 최적화, 그룹 로직, 애니메이션 예산, 석탄 거리 등이 부족했다 [269]
      2. 해결 시도: NPC 모카 시스템을 만들었으나 출시가 늦어 널리 사용되지 못했다 [271]
    4. 머티리얼 슬롯 과다 사용: 최대 3개까지 권장했으나, 많은 경우 이를 초과하여 렌더링 관점에서 비효율적이었다 [275]
      1. 현재 이 문제를 해결하기 위해 노력 중이다 [279]

  3. VFX 및 가상 섀도우 매핑 문제 [280]

    1. 유형 지정되지 않은 VFX: VFX 유형 지정을 충분히 알려주지 못해 VFX를 호출하거나 렌더링할 수 없는 문제가 발생했다 [281]
      1. 이로 인해 월드 전체에 거대한 핫스팟이 생성되는 현상이 발생했다 [283]
    2. 가상 섀도우 매핑 (Virtual Shadow Mapping): WPO(World Position Offset) 비활성화 거리를 설정해야 하는데, 언리얼 엔진 기본값이 없어 위치 오프셋이 발생했다 [285]
      1. 나뭇잎이나 기타 요소들이 특정 거리 이상에서는 보이지 않아야 하지만 계속 따라다니는 문제가 있었다 [288]
      2. 진짜 문제: 섀도우 캐시가 무효화되어 파란색 점들이 나타나고 성능에 심각한 영향을 미쳤다 [289]
      3. 해결 노력: 이 문제를 해결하려 했으나 성능 저하가 심해 결과가 고르지 못했다 [292]

  4. 재료 및 캐릭터 제작 관련 문제 [293]

    1. 기본 재료: 필요한 핵심 기능을 갖춘 기본 재료를 제공했으나, 일부 재료에 문제가 있었다 [293]
      1. 문제 사례: 각 돌을 재료의 각 부분으로 매핑하여 복잡한 재료가 생성되었다 [298]
      2. 개선 필요성: 트림 시트를 만드는 것이 더 일반적인 관행이며, 이는 교육해야 할 부분이었다 [299]
    2. 캐릭터 제작의 어려움: 스키닝, 메쉬, 리깅, TN Real 적용 등 여러 단계를 거쳐야 하는 어려운 작업이었다 [201]
      1. 문제점: 많은 캐릭터들이 스컬핑 프로그램에서 너무 늦게 완성되어 피드백을 줄 수 없었다 [310]
      2. 호환성 문제: 일부 훌륭한 캐릭터 작업이 스켈레탈 및 리깅 시스템과 호환되지 않아 삭제하거나 해결해야 했다 [313]
      3. 중복 이름 발생: 모바일 환경에서는 같은 이름을 사용할 수 없는데, 프로젝트 후반부에 동일한 이름의 텍스처가 다수 발생하여 모바일 패키징 과정에서 문제가 되었다 [318]

  5. 월드 구축 및 참여자 관리 문제 [321]

    1. 지형 수정의 어려움: 개발자들이 자신의 비전에 맞춰 지형을 수정하거나 조각하는 데 자신감을 느끼지 못했다 [321]
      1. 지형과 자연스럽게 어우러지는 지오메트리 생성 대신, 바로 소품과 세트 드레싱으로 넘어가는 경향이 있었다 [322]
      2. 순서 문제: 건물이나 나무를 먼저 배치하는 대신, 지형을 먼저 조각하고 배치한 후 건물과 나무를 배치하는 것이 효과적이다 [323]
    2. 신의 시점 작업: 참가자들이 플레이어 시점에서 작업 규모를 고려하지 않고 신의 시점에서 작업하는 데 익숙해져 있었다 [326]
      1. 테스트 부족: 충돌 같은 부분에서 작업을 제대로 테스트하지 않는 경우가 많았다 [329]
      2. 라이브 피드백: Aaron과 샘은 라이브 스트리밍에서 실시간 피드백을 주고받으며 문제를 발견하고 해결했다 [330]

  6. 문서화 및 초기 콘텐츠 부족 문제 [334]

    1. 반응적인 접근: 영상 제작은 생산적이기보다는 반응적인 측면이 강했으며, 실수가 있었고 이는 전적으로 팀의 책임이었다 [338]
    2. 정보 부족: 사람들이 필요한 정보를 충분히 제공받지 못했거나, 기본 지식 수준을 잘못 판단했다 [341]
    3. 조기 출시: GDC 직후, 최대한 많은 사람들을 끌어들이기 위해 필요한 것들을 갖추지 못한 채 조금 일찍 출시했다 [343]
      1. 이로 인해 문서와 기본 콘텐츠 제작 시간이 매우 부족했다 [344]
    4. 필요했던 초기 콘텐츠: 레벨 구조 예시, 레벨 인스턴스 사용법, 팩 레벨 액터, 기본 재료, 캐릭터 재료, FX 예시, 기본 아트 콘텐츠, 기본 PCG 설정 등 [345]
      1. 좋은 PCG 예시를 제공했더라면 PCG 프로세스 때문에 테크니컬 아티스트 위원회를 소집할 필요가 없었을 것이다 [347]
    5. 문서화 부족: 문서 자료는 있었지만 그것만으로는 부족했으며, 가진 것과 사용법을 더 잘 설명해야 했다 [350]
    6. 결론: 필요한 것을 과소평가하고 시기가 좋지 않았던 것이 복합적으로 작용한 결과이며, 다른 세상이었다면 더 많은 콘텐츠를 담아 조금 더 늦게 출시했을 것이다 [353]

  7. 정리 프로세스: 에셋 및 코드 관리 [398]

    1. 프로젝트 패키징 및 정리: 완벽하게 다듬어 깔끔하게 만들기 위해 엄청난 양의 작업이 필요했으며, 용량이 100기가바이트에 달했다 [398]
      1. 에셋 검증 미사용: 사람들이 자신의 작품을 자랑스럽게 보여주길 바랐기 때문에 직접 검증을 진행했다 [404]
    2. 리디렉터 수정: 엔진 충돌을 일으키는 폴더를 식별하고 폴더별로 수정 작업을 진행하여 문제 있는 에셋 위치를 파악하고 작업 속도를 높였다 [415]
      1. 팁: 한 번에 모든 것을 처리하고 커밋하지 말고, 일부를 수정하고 커밋한 다음 다시 수정하는 것이 좋다 [422]
    3. 사이즈 맵 툴 활용: 프로젝트 크기가 왜 이렇게 큰지 파악하는 데 유용했으며, 1.2GB짜리 원본 애니메이션 파일 등 불필요한 에셋을 삭제하거나 최적화했다 [426]
    4. 사용하지 않는 에셋 삭제: 자동 생성 폴더에 있는 방대한 양의 사용하지 않는 지오메트리, 즉 베어 메시들을 정리했다 [439]
    5. 메인 월드 불러오기: 수천 개의 맵 체크 경고와 오류를 확인하며 작업을 시작했고, 대부분 제대로 체크인되지 않아 잘못 삭제된 에셋에 대한 참조 문제였다 [446]
      1. 연쇄 반응: 한 가지를 수정하면 다른 여러 가지가 고장 나는 연쇄 반응이 발생하여 근본 원인을 찾아 다시 시작해야 했다 [450]
    6. 널 메시 참조 문제: 체크인되지 않은 메시나 블루프린트에서 메시가 포함된 블루프린트를 삭제하여 발생하는 널 메시 오류를 해결했다 [454]
    7. 미처리 스켈레탈 메시: NPC 마커를 사용하지 않는 미처리 스켈레탈 메시를 임시로 삭제하거나 교체, 또는 성능에 영향을 주지 않는 곳으로 옮겼다 [459]
    8. 반복 발사 문제: 스킨 M 에셋, 건설 스크립트, PCGS를 반복적으로 발사하는 것이 월드 규모 때문에 변경 사항 적용 시 다운을 유발했다 [462]
      1. PCG 방식으로 변환하여 반복 발사가 필요 없도록 정리했다 [464]
    9. 사용성 개선: 외부 활성 레벨 충돌, 표준 파일 크기를 벗어난 파일, 0 킬로바이트 파일, 외부 액터의 잘못된 부분 등을 찾아 정리했다 [467]
    10. 그룹화 문제: 그룹화를 사용하여 파일을 정리하고 그룹 내에서 체크인하지 않는 경우 발생하는 이상한 경고와 파일 위치 추적 어려움을 해결했다 [477]
      1. 그룹은 유용하지만 최종 제품에는 유지하지 않는 것이 좋다 [480]
    11. 중복 월드 액터 생성: PCG를 사용하다 보면 중복된 월드 액터가 많이 생성되는 경우가 있었으며, 이를 정리했다 [481]
    12. 깨진 재질: 재질 함수나 텍스처 체크인을 잊어버려 발생한 깨진 재질을 찾아 대체품을 찾거나 수정했다 [485]
    13. 블루프린트 사용 문제: 블루프린트에서 컴포넌트 자체 대신 자식 액터를 사용하여 컴포넌트를 포함하는 관행으로 인해 편집 및 수정이 어려웠다 [489]
      1. 자식 액터 컴포넌트를 분리하고 컴포넌트를 직접 블루프린트에 다시 만드는 도구를 개발했다 [501]
    14. 액터 경계 문제: 레벨 인스턴스 공간 밖에 액터가 있어 심각한 액터 경계 문제가 발생했으며, 특히 PCG에서 레벨 인스턴스 공간 밖의 데이터에 의존할 때 자주 발생했다 [510]
    15. 팩 레벨 액터 사용: 일부 사용자들이 소스 레벨을 사용하지 않고 팩 레벨 액터를 기본 클래스로 사용한 경우를 정리했다 [514]
    16. 레벨 인스턴스 문제: 풍경이 인스턴스에 포함되거나, 일반 에셋에 풍경 재질을 사용하는 경우 등 다양한 문제가 발생했으며, 이를 해결하기 위해 노력 중이다 [517]
    17. 깨진 액터 참조: 파일을 제대로 체크인하지 않거나 삭제를 제대로 하지 않아 발생한 깨진 액터 참조를 해결했다 [523]
    18. 4K 텍스처 과다 사용: 텍스처 크기를 줄여 대역폭을 절약하고, 게임 내에서는 동일하게 보이도록 최적화했다 [526]
    19. PCG 오브젝트 동적 생성: 거의 모든 오브젝트가 정적인 것이 아니라 동적으로 생성되어 성능 문제가 발생했으며, 이를 수정하는 데 많은 노력을 기울였다 [533]
    20. 복구 도구: 패키징 중에 오류가 많이 발생하는 경우 '오류 복구' 버튼을 통해 복구 도구를 사용할 수 있다 [536]
    21. 에셋 유효성 검사 도구: 측정값, 생성 스크립트 등 주요 문제들을 찾아 알려주며, 에셋 저장 시 오류를 표시해 준다 [544]
      1. 발견된 정보는 생성 스크립트, 정적으로 설정되지 않은 메시, C 거리 정보 등 유용했다 [555]
    22. 프로젝트 패키징: 에디터 작업보다 까다로웠으며, 특히 모바일 빌드 시 청킹, 에셋 이름 지정 등을 고려해야 했다 [561]
      1. 모바일 패키징 작업을 완료하고 실행 가능하게 만들었다 [564]
    23. HL 빌드 문제: Niagara 시스템의 경계 설정 오류, 방향 벡터 설정 오류, 월드 파티션 에셋 로드 불가 등으로 HL 빌드가 거의 작동하지 않았다 [566]
      1. Bird Flock 문제도 있었으나 추적하기 쉬웠고, 이제 완벽한 HL 빌드를 구현할 수 있게 되었다 [573]
    24. 프로젝트 이전: Standalone DDC에서 연결을 끊고 Epic Games Store에 다시 통합하는 과정에서 남아있는 불필요한 요소들을 제거했다 [576]

5. 미완성 작업 처리 및 향후 계획 [578]

thumbnail

  1. 미완성 작업 처리 전략 [578]

    1. 우선순위 설정: 명백히 미완성된 작업은 출시할 수 없지만, 거대한 빈 공간이 있는 게임을 출시하고 싶지 않아 우선순위를 정했다 [581]
    2. 히트맵 활용: 각 지역별로 무엇을 유지하고 무엇을 버릴지, 무엇을 다른 곳으로 옮길지 결정한 후 작업을 나누는 과정을 보여준다 [588]
    3. 지역별 작업: 절벽 꼭대기 도시 지역, 사막 지역, 초원 및 열대 지역 등 작업량이 많은 곳을 우선적으로 처리했다 [589]
    4. 디자이너의 역할: 미완성 지역을 완성하는 과정을 담당하며, 에셋 수정 및 재사용을 통해 소품을 배치하고 전반적인 레이아웃 작업을 했다 [595]
      1. 기존 에셋을 활용하여 재사용 가능한 지역을 만들고, 빈 공간에 생명의 흔적을 남기려고 노력했다 [598]
    5. 어촌 마을 사례: 다른 곳으로 가서 바다 위에 떠 있는 마을을 가져와 적절한 소품을 배치하여 사용했으나, 오두막들이 모두 물 위에 떠 있는 것을 수정해야 했다 [601]
      1. 다른 사람의 작업을 대체하기보다 프로젝트에 있는 작업을 그대로 사용하는 것이 좋지만, 애런의 판단에 따라 대체할 방법을 찾아야 할 때도 있었다 [609]
    6. PCG 활용: 비어 있거나 미완성된 부분을 채우기 위해 기존의 고품질 PCG 그래프를 최대한 활용했다 [613]
      1. 황량한 평원에서 숲으로 바뀌고, 그 숲에 오두막 같은 것들을 배치하여 게임 공간처럼 느껴지게 만들었다 [615]
    7. 지형 재질 개선: 지형을 다시 칠해서 재질을 더 잘 통합하고, 다양성을 더하고, 타일링 현상이 눈에 띄지 않도록 했다 [616]
      1. 화산 지역의 재질 개편 중이며, 아론 레드가 재질 작업을 하는 동안 새까맣게 보일 뿐이다 [617]
    8. 북극 지역 처리: 북극 지역의 황량한 곳에 빛나는 나무 같은 것이 있던 곳에 숲을 만들고 절벽을 추가했으며, 모든 지역은 동일한 방식으로 처리될 것이다 [620]

  2. 마무리 작업 및 출시 준비 [625]

    1. 모바일 패키징 문제 해결: 수많은 이름 문제들을 해결하고, 쿠킹 엔진에서 엔진 콘텐츠를 내보내는 것을 중단했다 [626]
    2. 카메라 컨트롤 및 메뉴 업데이트: 세바스찬이 업데이트된 카메라 시스템을 녹화하고 디버깅하고 있으며, 비주얼 로거를 통해 카메라 움직임, 사물과의 교차점, 변환 오류 등을 확인할 수 있다 [629]
      1. 이동 로직이 많이 개선되어 더 이상 호수에서 걸어 나가다가 튕겨 나가는 일은 없을 것이다 [638]
    3. 프로젝트 마무리 단계: 타이탄의 다음 단계는 곧 마무리될 것으로 예상되며, 정말 많은 발전을 이루었다 [643]
    4. 최신 작업 결과물: 팀원들과 내부에서 진행한 작업의 결과물을 모두 포함한 최신 작업 내용을 보여주며, 모든 지역에서 훌륭한 작업이 이루어졌다 [646]
      1. 정글 사원, 개구리 사원 입구, 거대하고 아름다운 곳 등 완성될 거라고 생각지 못했던 곳들이 완성되었다 [652]
    5. 출시 계획: 거의 완성 단계이며 곧 출시될 예정이고, 출시되면 모든 에셋을 Fab에 업로드할 것이다 [659]
      1. 이상적인 세상에서는 앞으로 최대한 잘 업데이트해 나갈 것이다 [661]
    6. 질의응답: 2분 남았으니 질문 있으면 답변해 주겠다 [662]