Apple Arcade 장치에서 fps 목표를 달성하기 위한 Sonic Dream Team 최적화

Sonic Dream Team은 Hardlight에서 개발하고 SEGA에서 배급한 플랫폼 게임입니다. 이 게임은 Sonic the Hedgehog 시리즈의 한 편으로, 소닉과 친구들이 악당 닥터 에그맨의 뒤틀린 꿈속을 빠르게 달려 세계 정복을 저지하는 내용입니다.

Apple Arcade는 스튜디오가 모든 지원되는 장치에서 동일한 성능 목표를 달성할 것을 요구하며, 이는 팀이 iPhone 6s Plus에서 iPhone 16까지 모든 장치에서 게임이 멋지게 보이도록 최적화해야 한다는 압박을 가합니다. 여기서 저사양 및 고사양 장치에서 요구되는 프레임 속도를 달성하는 방법을 설명합니다.

Sonic Dream Team: Unity 활용 사례

팀이 저사양 및 고사양 장치에서 요구되는 프레임 속도를 달성하기 위해 어떻게 최적화합니까?

10년 동안 고슴도치와 함께한 Hardlight는 스토리라인을 강화하고, 더 많은 캐릭터를 포함시키며, 액션과 모험 스타일을 고화질 비주얼과 혼합하여 Apple Arcade 게임이 실행될 수 있는 모든 장치에서 멋지게 보이도록 하는 새로운 도전을 원했습니다. 이 목표를 향해 작업하는 동안 팀은 CPU 및 GPU 관련 성능 문제에 직면하여 계속 최적화하도록 이끌었습니다.

결과

중간 및 고성능 장치에서 CPU 프레임 시간을 52ms에서 16ms로 줄였습니다.

iOS에서 빌드 크기를 4GB에서 2GB로 절반으로 줄였습니다.

셰이더 변형 런타임 메모리를 1GB 이상에서 100MB 이하로 줄였습니다.

렌더링 문제 해결하기

성능을 분석하기 위해 팀은 Unity가 제공하는 다양한 분석 도구를 활용했습니다. 특히 Profiler, Frame Debugger 및 Memory Profiler가 있었습니다. 이 도구들은 팀이 30fps 및 60fps를 달성하기 위해 문제의 출처를 더 잘 이해하는 데 도움을 주었습니다.

렌더링은 특히 저사양 기기에서 전체 프레임 시간 예산의 큰 부분을 차지했습니다. 팀은 이 비용을 줄이기 위해 SRP 배칭에 의존했습니다.

“우리는 현대적인 렌더링 접근 방식과 Unity의 지속적인 지원 덕분에 범용 렌더 파이프라인(URP)을 선택했습니다.”라고 Hardlight의 기술 아티스트인 Fraser Hutchison이 말합니다. 팀은 모바일 기기에서 시각적 효과를 극대화하기 위해 SRP 배칭 및 셰이더 그래프와 같은 기능을 우선시했습니다. “SRP 배처는 우리에게 많은 중량을 덜어주었고, 아티스트들이 표준 정적 배칭과 같은 재료 제약에 대해 걱정하지 않도록 유연성을 제공했습니다.”라고 Hutchison이 계속 말합니다. “우리는 주로 불투명 큐에 있는 100-200개의 배치를 평균적으로 사용했습니다. 이는 잘 작동했습니다.”

팀은 반사 프로브를 줄이고 재료 정렬 큐 및 베이크된 조명을 사용하여 배칭 효율성을 높이고 렌더링 비용을 줄였습니다.

레벨의 크기 때문에 렌더링 오버헤드를 줄이기 위해 사용자 정의 계층 볼륨 컬링 시스템을 구현했습니다. “각 레벨은 ‘섬’이라고 부르는 큰 덩어리로 나뉘었고, 플레이어의 위치에 따라 비활성화되거나 활성화되었습니다.”라고 Hutchison이 말합니다. “이것은 또한 해당 섬에 대해 애니메이터와 파티클 효과를 비활성화할 수 있음을 의미했습니다. 전반적으로, 이것은 우리의 요구에 잘 맞는 경량 솔루션이었습니다.”

“팀의 아티스트들은 그들이 만들고 있는 세계의 꿈같은 품질을 높이기 위해 많은 고유 메시 데이터, 셰이더 효과 및 후처리가 포함된 고충실도 그래픽을 원했습니다. URP를 사용하면 후처리와 같은 기능이 내장되어 있어 항상 완전히 사용자 정의 솔루션이 필요하지 않고도 시각적 효과를 빠르게 모의할 수 있습니다.” – Simon Dew, 아트 디렉터, Hardlight

CPU 프레임 시간 줄이기

모든 iOS 기기에서 일관된 게임 플레이를 보장하기 위해 Hardlight 팀은 물리 주파수를 기본 50Hz 대신 60Hz로 설정했습니다. 그들은 특정 객체의 업데이트 간 예상 시간 단계를 강화하기 위해 FixedUpdate를 사용했습니다.

성능 문제로 인해 프레임 시간이 크게 증가할 때, Unity에서는 원하는 물리 업데이트 속도를 유지하기 위해 단일 프레임 내에서 여러 FixedUpdate 호출이 이루어집니다.

“결국, 시뮬레이션은 모든 필수 업데이트를 제때 처리할 수 없게 되어 프레임 시간이 더욱 길어졌다.”라고 Hardlight의 수석 소프트웨어 엔지니어인 Louis Macan이 말합니다. 같은 물리 시간 단계가 있는 것은 저사양 장치에서 30fps로 게임을 실행하는 동안 프레임당 FixedUpdate 호출의 수를 증가시켰습니다.

iPhone 6s Plus와 같은 구형 장치에서 좋은 프레임 속도를 유지하기 위해 팀은 모든 FixedUpdate를 최적화했습니다. 개별 FixedUpdate 호출을 프로파일링하는 동안, 그들은 FixedUpdate 시간의 대부분이 수백 개의 스크립트 인스턴스에서 발생하는 업데이트 호출에 의해 차지된 것을 주목했습니다. 이 스크립트들이 조기 종료 조건을 통해 빠르게 종료되었음에도 불구하고, FixedUpdate 호출은 여전히 실행되었습니다.

“조건이 충족되지 않으면 FixedUpdate가 아무것도 하지 않는 것처럼 보일지라도, 스크립트에 선언된 모든 Unity 이벤트 함수는 오버헤드를 발생시킵니다.”라고 Macan이 말합니다. “오버헤드는 그 자체로는 작지만, 레벨 생성 중에 추가된 스크립트에 의해 실행된 수천 개의 Update, FixedUpdate 및 Late Update 호출은 큰 영향을 미쳤습니다.”

이를 해결하기 위해 여러 접근 방식을 조합해야 했습니다. 첫째, 스크립트가 자신을 등록할 수 있는 관리자를 추가했으며, 관리자는 필요한 업데이트 주기에 따라 각 객체를 차례로 틱했습니다. 이것은 모든 Unity 이벤트 함수를 제거할 수 있게 하여 CPU에서 시간을 더 이상 소모하지 않게 했습니다. 마지막으로, 플레이어의 물리와 상호작용하지 않는 객체는 Update에서 틱하도록 설정하여 저사양 장치에서 계산 비용을 절반으로 줄였습니다.

게임의 입자 시스템 향상

팀은 또한 장면의 과도한 입자 시스템이 CPU 성능에 영향을 미친다는 것을 발견했습니다. 입자 풀링 시스템의 일환으로, 팀은 ParticleEffectsWrapper 구성 요소를 통해 ParticleSystemRenderer API를 사용하여 입자 시스템을 활성화하거나 비활성화했습니다. 메인 및 작업 스레드에서 500개 이상의 입자 시스템 업데이트가 처리되면서, 이는 약 5.2ms의 CPU 프레임 시간을 소모했습니다.

“Unity의 Visual Effect Graph는 이 프로젝트에서 우리에게 선택 사항이 아니었습니다. 많은 저사양 장치가 그 시스템이 의존하는 GPU 컴퓨트를 지원하지 않기 때문입니다.”라고 Hutchison이 말합니다. “우리가 그것을 사용할 수 있었다면, 우리는 더 나은 컬링 및 인스턴싱 기술의 혜택을 받았을 것입니다.”

Unity의 입자 시스템은 절차적이거나 비절차적일 수 있습니다. 절차적 입자 시스템은 시간을 자유롭게 되감거나 빨리 감을 수 있습니다.

“절차적 방법을 사용하면 Unity는 화면에 보이지 않을 때 입자 시스템과 관련된 모든 처리를 안전하게 제거하고, 다시 보이게 될 때 올바른 상태로 빠르게 전환할 수 있습니다.”라고 Hutchison이 말합니다. “이것은 상당한 성능 향상을 생성할 수 있습니다.” “그러나 이는 입자 효과 생성의 종종 간과되는 부분이며, 효과를 비절차적으로 만드는 것은 매우 쉽습니다.”

이를 피하기 위해 ParticleEffectsWrapper 구성 요소는 카메라 프러스텀에 따라 입자를 제거할 뿐만 아니라, 입자가 절차적으로 표시되더라도 수동으로 설정된 경계가 시스템을 제거할 수 있도록 사용자 정의 렌더 경계를 정의했습니다.

“장면에 많은 수의 입자 시스템이 있을 때 가능한 한 많은 시스템이 절차적이도록 하는 것이 중요해졌고, 그렇지 않은 경우 ParticleEffectsWrapper 구성 요소에서 렌더 경계를 설정했습니다.”라고 Macan이 말합니다. “이것은 불필요한 계산과 드로우 호출을 방지하여 성능을 크게 향상시켰습니다.”

제거와 함께 팀은 효과를 위한 좋은 생성 관행을 우선시했습니다. 그들은 필요한 만큼만 입자 시스템을 사용하고 최대 입자 수를 제한하여 알파 오버드로우와 메모리 할당을 줄였습니다. 그들은 또한 입자 효과의 텍스처 아틀라스 작업에 집중하고 과도한 지속 시간 시간을 피했습니다. 그들은 또한 URP 렌더 설정의 ‘모든 숨겨진 속성 표시’ 토글을 통해 동적 배칭을 활성화했으며, 이 작은 변경이 입자의 드로우 호출을 줄이고 렌더링 속도를 높이는 데 도움이 되었습니다.

GPU 병목 현상 발생

Sonic Dream Team에 대한 비전은 고급 그래픽과 빠른 게임 플레이를 요구했습니다. 사용자 정의를 위해 그들은 화면 공간 환경 오클루전, 사용자 정의 전체 화면 효과 및 화면 공간 데칼과 같은 특정 효과에 대한 렌더 기능을 사용했습니다. 이로 인해 렌더링 지연과 메모리 문제가 발생했습니다.

“개발 중에 캐릭터와 적의 블롭 그림자를 위해 깊이 기반 화면 공간 데칼을 사용할 때 렌더 기능이 불필요한 깊이-노멀 프리패스를 유발한다는 것을 발견했습니다.”라고 Hutchison이 말합니다. “이는 렌더링 시간의 상당 부분이 불필요한 작업에 소요되었고, 노멀 버퍼가 필요하지 않았기 때문에 렌더 타겟 메모리가 증가했습니다. 우리는 이를 해결하기 위해 Unity 팀과 협력했으며, 수정 사항은 엔진 패치 릴리스에 추가되었습니다.”

셰이더 프리워밍도 우려 사항이었으며, 레벨 전반에 걸쳐 CPU/GPU 스파이크가 발생하여 멈춤 현상이 발생했습니다. “Metal에서 셰이더를 효과적으로 프리워밍하려면, 셰이더는 모든 필수 키워드를 포함해야 하며, 렌더링할 각 메시의 특정 정점 레이아웃 그룹을 가져야 합니다. 이는 에디터 전용 캐싱이 불가능하다는 것을 의미했습니다.”라고 Hutchison이 말합니다.

이를 해결하기 위해 Hardlight의 엔지니어들은 로드 시간에 카메라 앞의 모든 객체를 “플래시 렌더링”하는 시스템을 만들었습니다.

“우리의 섬 컬링 기술은 장면의 모든 렌더러 목록에 쉽게 접근할 수 있게 해주었습니다. 이 작업을 장치에서 수행함으로써 플레이어가 레벨에 공식적으로 들어가기 전에 품질 설정에서 모든 올바른 파이프라인 상태 데이터와 키워드를 확보할 수 있었습니다.”라고 Hutchison이 말합니다. “이로 인해 레벨 로드 시간이 약간 증가했지만, 플레이어 경험을 위해서는 그만한 가치가 있었습니다.”

셰이더 프리워밍을 극복한 결과에 만족한 Hutchison은 앞으로 다른 옵션을 모색하고 있습니다. “게임 출시 이후, Unity는 PSO 캐싱 및 GraphicStateCollections을 통한 프리워밍을 출시했으며, 우리는 이를 미래에 사용하고 싶습니다.”

주소 지정으로 메모리 크기 감소

개발 중에 게임은 런타임에서 1.35GB의 메모리를 사용했습니다. iPhone 6s Plus의 물리적 메모리가 2GB에 불과했기 때문에, 이는 운영 체제가 애플리케이션을 종료할 위험을 포함한 문제를 초래할 수 있었습니다.

“자산 중복은 큰 장애물이었습니다. 게임에는 3,000개 이상의 중복 자산이 있어 크기가 부풀어 오르고 실행 중에 동일한 자산이 여러 번 로드되는 문제가 발생했습니다.”라고 Macan이 말합니다.

그 당시 Unity Addressable System은 게임 자산의 일부만 관리하고 있었습니다. 이로 인해 자산이 이진 파일과 Addressable Groups 모두에서 참조되는 경우가 발생하여 중복이 발생했습니다.

개발 초기에는 팀이 단일 Addressable Group을 사용하고 이를 별도로 패킹하도록 설정했습니다. 이는 그룹 내 각 자산이 별도의 AssetBundle을 갖는 것을 의미했습니다. 특정 경우에 유용하지만, 이러한 세분화된 접근 방식은 많은 중복 자산을 초래했습니다. 모든 자산이 Addressable인지 확인하고 Addressable Groups에 대한 구조화된 접근 방식을 갖는 것은 iOS에서 빌드 크기를 4GB에서 2GB로 줄였습니다.

셰이더 변형 메모리 감소

셰이더 변형은 게임 제작 전반에 걸쳐 팀의 주요 초점이었으며, 런타임 셰이더 메모리는 1GB를 초과했습니다. 변형의 수가 빌드 시간을 증가시켰습니다. 그들은 다양한 방법을 사용하여 문제를 해결했습니다. 주로 IPreprocessShaders를 통한 셰이더 스트리핑, Unity의 사전 필터링, Unity의 동적 셰이더 로딩, 셰이더 분기를 줄이는 방법이었습니다.

“우리는 모든 셰이더에서 셰이더 키워드를 전역적으로 제거하는 자체 커스텀 IPreprocessShaders 스트리핑 구현을 사용했으며, Unity Asset Store의 셰이더 컨트롤을 통한 로컬 접근 방식을 사용했습니다.”라고 허치슨이 말합니다. “셰이더에서 키워드를 사용할 때 더 의도적으로 접근하는 것도 큰 성과였습니다.”

그들의 셰이더는 Shader Graph를 사용했으며, 이는 본질적으로 Unity에서 미리 정의한 키워드를 포함하고 있으며, 여기에 추가 키워드를 추가하는 것은 기하급수적인 효과를 가져왔습니다. 일부 논리를 동적 분기로 전환하거나 키워드를 완전히 제거하면 총 변형 수가 크게 줄어들었습니다.

“이 모든 방법을 결합하여 런타임 셰이더 변형 메모리를 평균 100MB 이하로 줄였습니다.”라고 허치슨이 말합니다. “우리는 또한 빌드의 모든 자산과 설정에 대한 전반적인 뷰를 제공하는 Unity의 프로젝트 감사자를 사용했습니다. 메모리 프로파일러와 결합하여 사용함으로써, 우리는 개선된 가져오기 프리셋의 혜택을 받은 텍스처와 메시를 식별했습니다. 이로 인해 아트 및 오디오 자산으로 인한 메모리 압력이 더욱 줄어들었습니다.”

성과를 축하하고 미래를 바라보며

10년 이상 동안 Unity와 Hardlight는 스튜디오가 의존하는 공유 기술 레이어를 구축했습니다. “우리는 10년 전에 Unity로 만든 게임을 여전히 지원하고 있습니다.”라고 마칸이 말합니다.

Unity는 수년 동안 많은 것을 추가했으며, 그는 스튜디오가 Unity의 API에 대한 일부 네이티브 코드를 제거하여 유지 관리를 단순화했다고 언급했습니다. “Unity는 저수준 장치 지원의 많은 부분을 처리하므로, 우리는 실제 게임 제작에 집중할 수 있습니다. 기술이 발전함에 따라 Unity가 우리가 따라잡는 데 도움을 줄 것이라고 확신합니다.”라고 그는 외칩니다.

Sonic Dream Team은 여전히 오래된 고슴도치에게 새로운 기술을 가르칠 수 있음을 증명합니다. 그리고 Sonic처럼 Hardlight와 Unity는 강력한 실적과 밝은 미래를 가지고 있습니다.

지금 Unity Pro 다운로드하기

강력한 툴, 지원, 검증된 파트너, 활발한 커뮤니티의 도움을 받아 대형 스튜디오의 출시작과 경쟁하거나 이를 능가하는 수준의 품질을 갖춘 성공적인 게임을 제작해 보세요.