Wishfully가 어떻게 Planet of Lana II를 여러 플랫폼에 동시에 출시했는가

Planet of Lana II 는 2018년 예테보리에서 설립된 스웨덴 인디 스튜디오인 Wishfully가 개발한 시네마틱 퍼즐 어드벤처입니다. PC, Xbox, PlayStation에서 해당 경험 제공®그리고 차세대 하드웨어를 포함한 Nintendo Switchᵀᴹ은 상당한 기술적 도전 과제입니다.

우리는 스튜디오의 공동 책임자이자 크리에이티브 디렉터인 Adam Stjärnljus, 수석 프로그래머 Edvard Rutström, 수석 프로그래머 Mattias Wargren과 함께 그들이 코드베이스를 통합하고, 빌드 파이프라인을 확장하며, PC와 콘솔에서 동시에 출시하면서 대부분의 플랫폼에서 60fps에 도달하도록 게임을 최적화한 방법을 분석했습니다.

*Nintendo Switch는 Nintendo의 상표입니다.

개요를 공유해 줄 수 있나요? 라나의 행성 II 그리고 멀티플랫폼 프로젝트로서의 범위는 무엇인가요?

Adam Stjärnljus: 라나의 행성 II 원본을 기반으로 콘텐츠를 대폭 확장하고 범위를 넓혔습니다. Xbox와 PC에서 출시된 후 다른 플랫폼으로 이식한 첫 번째 게임과 달리, 우리는 PC, Xbox One 및 Xbox Series X|S, PlayStation 4 및 PlayStation 5, Nintendo Switch 시스템에서 동시 멀티플랫폼 출시를 위해 속편을 개발했습니다. 2026년 3월 5일에 출시했습니다.

퍼즐과 플랫포밍, 스텔스를 결합한 스토리 중심의 여정을 따라가는 퍼즐 어드벤처 게임으로, 라나와 그녀의 동료 무이를 따라가는 게임입니다. 핵심 게임플레이는 라나와 무이 간의 협력적 상호 작용에 초점을 맞추고 있으며, 내러티브는 첫 번째 게임의 월드와 충돌을 확장합니다.

팀은 동시 멀티플랫폼 실행을 위한 비전을 정의하기 위해 어떤 접근 방식을 취했으며, 어떤 요소들이 플랫폼 라인업을 결정짓는 데 영향을 미쳤나요?

AS: 우리는 멀티플랫폼 우선 마인드셋으로 속편에 접근했으며, 첫 번째 게임의 플랫폼 추상화와 도구를 기반으로 빌드했습니다. 우리의 목표는 개발 과정 내내 성능을 테스트하고 개선할 수 있도록 생산 초기 단계에서 모든 대상 플랫폼에서 지속적인 빌드를 실행하는 것이었으며, 이 작업을 끝까지 미루지 않기로 했습니다.

우리는 원본 릴리스의 성공과 모든 플랫폼에서 동시 실행을 제공하려는 목표를 기반으로 플랫폼 라인업을 선택했습니다. PC, Xbox, PlayStation 및 Nintendo Switch 시스템입니다. 이를 지원하기 위해 모든 대상 플랫폼에서 패리티를 유지하는 것이 여전히 어려운 과제임에도 불구하고 전체 팀이 초기 단계에서 성능 개선에 기여할 수 있도록 기존 도구와 워크플로를 반복적으로 개선했습니다.

기술 아키텍처가 플랫폼별 코드 사일로를 생성하지 않고 효율적인 멀티플랫폼 빌드 및 배포를 어떻게 지원했나요?

Mattias Wargren: 우리는 플랫폼 포크가 없는 단일 Unity 프로젝트를 사용하고 첫 번째 게임의 공유 플랫폼 추상화 레이어에서 빌드하여 플랫폼 단편화를 방지했습니다. 우리는 별도의 코드베이스를 유지하는 대신 컴파일 시간 정의, 조건부 시스템 및 도구를 통해 플랫폼 차이를 처리했습니다.

또한 장치별로 조정할 수 있는 계층화된 품질 및 세부 수준과 함께 플랫폼별로 에셋을 포함하거나 제외하는 콘텐츠 필터링 도구를 구현했습니다. Unity의 빌트인 설정 외에도 더 큰 제어를 위한 커스텀 품질 시스템을 추가했습니다.

AS: 이 설정을 통해 디자이너와 개발자는 단일 파이프라인에서 모든 것을 통합하면서 대상 기기에 맞게 콘텐츠와 성능을 조정할 수 있었습니다. 이를 통해 빌드를 효율적이고 관리하기 쉽게 유지할 수 있었습니다.

모든 플랫폼에서 배포를 지원하면서 빌드 병목 현상을 피하기 위해 빌드 파이프라인을 어떻게 구조화했나요?

Edvard Rutström: 우리는 빌드 파이프라인을 일찍 우선시하여 개발자 컴퓨터에서 빌드를 유지하고 경합을 피하기 위해 TeamCity와 전용 빌드 에이전트를 사용하는 온프레미스 설정부터 시작했습니다. 프로젝트의 후반 단계에서 더 많은 빌드 에이전트가 있는 퍼블리셔 호스팅 인프라로 전환하여 모든 플랫폼에서 자동화된 야간 빌드를 실행하고 병목 현상을 줄일 수 있었습니다.

또한 모든 플랫폼에서 공용 데모를 지원해야 했는데, 이로 인해 빌드 복잡도가 증가하고 빌드 수가 실질적으로 두 배가 되었습니다. 이를 동일한 저장소 및 프로젝트 내에서 처리하기 위해 빌드 플래그를 사용하여 데모와 전체 게임을 정의하고 빌드 시점에 데모가 아닌 콘텐츠를 제거했습니다. 이 방법은 기술적으로 잘 작동했지만, 특히 QA에서 디버그 및 릴리스 변형을 모두 필요로 하는 상황에서 빌드 볼륨을 관리하는 것이 큰 부담이 되었습니다.

MW: 파이프라인을 이식 가능하도록 설계했습니다. 인프라를 마이그레이션할 때 코드베이스나 빌드 스크립트를 변경할 필요가 없었기 때문에 전환이 원활하게 이루어졌고 개발에 방해가 되지 않았습니다.

여러 플랫폼별 최적화가 병렬로 개발되는 동안 안정성을 보장한 통합 전략은 무엇이었나요?

MW: 공유된 품질 계층과 강력한 확인 도구를 결합하여 안정성을 달성했습니다. Unity 에디터에서 직접 시뮬레이션할 수 있는 플랫폼 인식 품질 모드를 구현하여 디자이너와 아티스트가 프로젝트를 분기하지 않고도 콘텐츠가 다양한 하드웨어에서 어떻게 동작하는지 미리 볼 수 있게 했습니다.

또한 체크포인트를 단계적으로 진행하고 스크린샷을 캡처하며 성능 지표를 오버레이하는 자동화 도구도 구축했습니다. 이를 통해 팀은 변경 사항이 다양한 대상 플랫폼에 미치는 영향을 지속적으로 파악할 수 있었고 코드베이스를 안정적으로 유지하면서 병렬로 반복 작업을 수행할 수 있었습니다.

다양한 플랫폼 빌드를 간소화하고 에셋 중복을 줄이기 위해 에셋 파이프라인을 어떻게 구조화하셨나요?

ER: 콘텐츠 번들링 중심 접근 방식에서 벗어났습니다. 에셋 중복을 피하는 것이 어려웠습니다. 특히 게임 전반에 걸쳐 바이옴 콘텐츠를 재사용했기 때문에 깨끗한 분리가 불가능했기 때문입니다.

대신, 우리는 더욱 제어된 에셋 파이프라인에 의존했습니다. 우리는 FMOD에서 오디오를, 스프라이트 아트리스에서 시각적 요소를 처리했습니다. 다양한 하드웨어 계층에 대해 최적화하기 위해 우리는 에셋 스트리핑과 아트리스 크기 제한에 중점을 두었으며, 이를 통해 추가적인 중복을 도입하지 않고 메모리 사용량을 줄였습니다.

이러한 접근 방식은 빌드를 더 단순하게 유지하면서 예측 가능한 로딩 동작과 모든 기기에서 안정적인 메모리 사용을 보장했습니다.

C# Job System 및 Burst 컴파일러를 사용하는 게임플레이 시스템은 멀티플랫폼 빌드 배포를 어떻게 지원하였나요?

ER: 우리는 몇 가지 대상 시스템에서 Unity C# Job System과 Burst 컴파일러를 사용했으며, 주로 화재, 열 및 물을 처리하는 원소 시뮬레이션과 눈 변형 시스템을 사용했습니다.

이러한 시스템은 범위가 잘 정의되고 데이터 중심적이었기 때문에 특별한 처리 없이도 다양한 하드웨어에서 문제 없이 작동했습니다. 우리는 충돌이나 경쟁 조건을 발견하지 못했기 때문에 표준 Job System 모범 사례만으로도 충분했습니다.

빌드 구성과 플랫폼별 최적화에 대한 정보를 제공하기 위해 프로파일링 데이터를 어떻게 사용하셨나요?

MW: 우리는 모든 플랫폼에서 개발 빌드에 대한 프로파일링에 의존하고 자동 스냅샷을 사용하여 레벨별 문제 영역을 식별했습니다. 처음부터 각 플랫폼을 독립적으로 조정하는 대신, 모든 대상 플랫폼에 이익이 되는 개선에 중점을 두고 필요한 경우 특정 핫스팟을 세부 조정했습니다.

ER: 저사양 기준값 전달을 시작으로 CPU 병목 현상을 대상으로 하였으며, 가끔 GPU 병목 현상도 시각적 품질을 유지하는 최적화를 통해 대상으로 삼았습니다. 그 작업은 계속되어 대부분의 대상 플랫폼에서 60fps에 도달하는 데 도움이 되었습니다. 또한 에셋 로딩 및 메모리 풋프린트를 관리하기 위해 메모리 프로파일링을 광범위하게 사용했습니다.

AS: 그것은 지속적인 루프였습니다. 우리는 드로우 콜과 프레임 속도 저하와 같은 문제를 프로파일링하고 식별한 다음 최적화하고 반복했습니다. 시간이 지나면서 이는 디자이너들이 성능 제약 사항을 더 일찍 이해하게 되는 워크플로로 발전했으며, 이는 후반 단계의 재작업을 줄였습니다.

여러 플랫폼에서 효율적으로 배포되고 일관되게 실행되도록 내비게이션 시스템을 어떻게 구성하고 빌드했나요?

MW: 우리는 사전 계산된 데이터와 런타임 유연성을 균형 있게 조합한 정적 및 동적 NavMesh 영역을 사용했습니다. 우리는 품질 구성을 통해 플랫폼별 내비게이션 설정을 조정하여 장치별 정밀도와 성능 비용을 제어하면서 일관된 동작을 유지할 수 있었습니다.

돌이켜보면 무엇을 다르게 하고 싶으며, 동시 다중 플랫폼 실행을 시도하는 팀에게 어떤 조언을 해주겠습니까?

ER: 우리가 바꿀 한 가지는 빌드 파이프라인에서 패치 생성을 자동화하는 것입니다. 수동으로 하는 것은 시간이 많이 걸리고 확장성이 없었습니다.

우리가 얻은 가장 큰 교훈은 처음부터 멀티플랫폼으로 진행하는 것입니다. 모든 대상 플랫폼에서 일찍 빌드하고 테스트하고 최적화를 나중에 미루지 마십시오. 저희는 또한 저장 데이터, 성과, 사용자 처리와 같은 공통 기능을 단일 API 뒤에 래핑하는 플랫폼 추상화 레이어를 개발했습니다. 이를 통해 구현을 격리하고 코드베이스의 나머지 부분에 영향을 미치지 않고 새로운 플랫폼을 지원하기 쉬워졌습니다.

Unity로 제작된 프로젝트에 대해 자세히 알아보려면 다음을 방문하십시오. 자원 페이지.