[번역] "14일만에 0에서 60프레임 만들기"

원문은 이곳에서 보실수 있습니다.
더 많은 번역 글은 http://unityindepth.tistory.com/에서 보실수 있습니다.

---

"14일만에 0에서 60프레임 만들기" 

Unity3D를 사용하여 우리의 게임을 최적화시키면서 배웠던 것들

부드러운 게임 플레이는 매끄러운 프레임 레이트를 기반으로하는데, 아이폰과 아이패드를 대상으로 60프레임에 이르게하는 것은 우리의 다가오는 액션 게임, Shadow Blade의 중요한 목표였다. (http://shadowblade.deadmage.com)

다음은 우리가 고려해야 했던 것과 성능을 개선시키기위한 게임 내의 변화, 그리고 집중적인 최적화 기간 동안 목표 프레임에 도달하게하는 것들에 대한 요약이다.

기본적인 게임 기능이 잘 작동되고 난 후, 목표로 설정한 게임 성능을 만족시켜야 했다. 우리의 주요 성능 측정 툴은 내장 유니티 프로파일러와 Xcode 프로파일링 툴이였다. 유니티 프로파일러를 사용하여 장치에 실행중인 코드를 프로파일하는 것은 매우 유용한 특징이라는 것을 증명했다.

여기 우리의 요약과, 집중적인 측정, 수정, 재측정에 대해서 배운 것들이 있고, 그 결과 우리의 목표 장비에 고정된 60프레임을 만들 수 있었다.

1 – 가비지 컬렉터라고 불리는 흉포한 괴물과 직접 맞서라.

C/C++ 게임 프로그래밍 배경에 비롯하여, 우리는 가비지 컬렉터의 특정한 행동을 사용하지 않았다. 사용하지 않는 메모리를 당신 대신에 자동으로 깨끗이 하는 것은 일단 매우 멋진 일이지만, 곧 실제로 효과가 서서히 나타나기 시작하고, 쓰지 않는 메모리를 모으는 가비지 컬렉터에 의해 당신은 CPU Load를 보여주는 프로파일러에서 정기적인 급등을 목격할 것이다. 이는 특별히 모바일 장비에서 거대한 이슈로 드러났다. 메모리 할당과 이를 제거하는 것은 최우선순위가 되었고, 여기에 우리가 취했던 몇가지 주요 행동들이 있다:

1. 코드에서 문자열 병합을 제거하라. 이는 가비지 컬렉터가 수거할 수 있는 많은 쓰레기를 남긴다.
2. foreach 반목문을 간단한 "for" 반복문으로 교체해라. "foreach" 반복문에서 한번 돌 때마다 24Byte의 쓰레기 메모리를 생성한다. 10번을 반복하는 간단한 반복문은 납득할 수 없는 GC가 수거 가능한 240byte의 메모리를 남긴다.
   
3. 게임 오브젝트의 태그를 비교하는 방법을 교체해라. if(go.tag == "Enemy")를 사용하는 대신에, 우리는 if(go.CompareTag("Enemy")를 사용했다.
   객체에 tag 프로퍼티를 호출하는 것은 추가적인 메모리를 할당하고 복사하며, 이 같은 비교문이 내부 반복문에 있다면 정말 나쁘게 작용한다.
4. 오브젝트 풀은 훌륭하며, 우리는 게임이 실행되는 동안에, 레벨을 진행하고 있을 때, 어떤 것도 동적으로 할당하지 않기 위해서 동적 게임 오브젝트를 위한 풀을 만들고 사용 했다.
   
5. LINQ 명령어를 사용하지 않았다. 그들은 중간 버퍼를 할당하는 경향이 있는데, 이는 가비지 컬렉터의 음식이다.

2 – High-Level 스크립트와 네이티브 엔진 C++코드간의 커뮤니케이션 오버헤드에 신경써라.

유니티3D를 사용하여 작성된 모든 게임플레이 코드는, 우리의 경우 Mono runtime을 사용하여 처리되는 C#으로된 스크립트 코드였다. 엔진 데이터와 커뮤니케이션하기 위한 모든 요구사항은 High-Level 스크립트 언어가 네이티브 엔진 코드를 호출하는 것이다.  물론 이 자체로도 오버헤드를 가지고 있고, 게임코드에서 이 같은 호출을 줄이는 것은 두번째 우선순위였다.

1. 씬을 돌아다니는 움직이는 객체는 스크립트 코드가 엔진 코드를 호출하도록 요구하는데, 우리는 게임플레이 코드에서 한 프레임 동안 객체의 변형 요구사항을 캐싱했고, 호출 오버헤드를 줄이기 위해 이 요구사항을 엔진에 딱 한번 보냈다. 우리는 객체의 움직임과 회전이 필요한 곳 외에 다른 유사한 곳에서도 이 패턴을 사용하였다.
   
2. 지역적으로, 컴포넌트의 참조를 캐싱하는 것은, 매번 게임 오브젝트의 "GetComponent"를 사용하여 컴포넌트 참조를 가져오는 것을 제거할 수 있다. 이는 위에서 봤던 네이티브 엔진 코드 사용을 줄일 수 있는 또 다른 예이다.

3 – 물리학, 물리학, 물리학 그 이상.

1. 물리 시뮬레이션 시간간격을 가능한 최소한으로 설정해라. 우리의 경우 16밀리세컨트 이하로 설정하지 않았다.
2. 캐릭터 컨트롤러의 Move 명령어를 호출하는 것을 줄여라. 캐릭터 컨트롤러를 움직이는 것은 동시에 발생하며, 매 호출마다 상당한 성능 비용을 불러올 수 있다. 우리가 한 것은 매 프레임마다 움직임 요구 사항을 캐시하였고 이를 그들에게 딱 한번 적용했다.
3. "ControllerColliderHit" 콜백에 의존하지 않게 코드를 수정하라. 이들의 콜백은 매우 빠르게 처리되지 않는다는 것으로 드러났다.
4. 좋지 않는 장비들을 위해 천 물리를 스킨드 메쉬로 교체하라. 천 파라미터는 성능에 있어서 중요한 역할을 하고, 미학적인 부분과 성능사이의 적절한 균형을 찾기 위해 많은 시간을 지불한다.
   
5. 레그돌은 물리 시뮬레이션 루프의 영역이 아니기 때문에 활성화 하지 않았으며, 꼭 필요할 때만 활성화 시켰다.
6. 트리거의 "OnInside"콜백은 신중하게 평가되어야한다. 그리고 우리의 경우, 가능한 이것을 사용하지 않고 로직을 짜기위해 노력했다.
7. 태그 대신에 레이어! 레이어와 태그는 객체에 손쉽게 할당될 수 있고, 특정 객체를 질의하는데 사용될 수 있다. 그러나 충돌 로직에 관해서, 레이어는 적어도 성능에 있어서 확실한 장점을 가진다. 더 빠른 물리 계산과 덜 요구되는 새로운 할당 메모리가 근본적인 이유이다.
8. 메쉬 콜라이더는 절대 해서는 안된다.
9. 레이캐스트와 구 확인(sphere check)같은 충돌 감지 요구 사항을 최소화 하라. 그리고 각각의 확인(Check)로부터 많은 정보를 얻으려고 해라.

4 – AI 코드를 더 빠르게 만들자!

우리는 메인 닌자 영웅을 저지하고, 그와 싸우는 적에 대한 인공지능을 사용한다. 다음의 주제는 AI 성능 이슈에 관해서 다뤄져야 한다.

1. A lot of physical queries are generated from AI logic like visibility checks. The AI update loop could be set to something much lower than the graphics update loop to reduce CPU load.
   시야 확인같이, AI 로직으로 부터 많은 물리적인 질의들이 생성된다. CPU Load를 줄이기위해서 AI 업데이트 루프는 그래픽 업데이트 루프보다 훨씬 더 낮게 설정할 수 있다.(?)

5 – 최고의 성능은 전혀 코드로부터 달성되지 않는다!

아무것도 발생하지 않을 때, 성능은 좋다. 이것은 우리가 지금 필요하지 않는 것에 벗어나게하는 기본적인 철학이었다. 우리의 게임은 횡스크롤 액션게임이고, 그래서 많은 동적 객체들은 씬에서 보이지 않을 때 꺼질 수 있다.

1. 세부 계획된 커스텀 레벨을 사용하여, 멀어질 때 적 AI는 꺼진다.
2. 움직이는 플래폼과 위험요소 그리고 그들의 물리적인 충돌체는 멀어졌을 때 꺼진다.
3. 유니티에 내장된 "animation culling" 시스템은 랜더되지 않는 객체의 애니메이션을 끄는데 사용된다.
4. 같은 비활성화 메커니즘은 모든 단계의 파티클 시스템에 사용된다.

6 – 콜백! 빈 콜백은 어때?

유니티 콜백은 되도록 많이 감소되어야 했다.  심지어 텅 빈 콜백조차 성능에 영향을 줬다. 빈 콜백을 가져야 할 이유는 없다. 하지만 단지 많은 코드 재작성과 리팩토링을 하면서 코드에 빈 콜백들을 남겨두는 경우가 있다.

7 – 도움에 강력한 아티스트.

아티스트들은 언제나 좀 더 프레임 레이트를 올리기 위해 머리를 쥐어짜는 프로그래머를 매혹적으로 도와줄 수 있다.

1. 유니티에서 게임 오브젝트에 대해 머티리얼을 공유하는 것과 그들을 정적(static)으로 만드는 것은 그들이 함께 배치되도록 하고, 그 결과 감소된 드로우 콜은 모바일 성능에 매우 중요하다.
   
2. 텍스쳐 아틀라스는 특별히 UI 요소에 대해 많은 도움을 줬다.
3. 적절한 압축을 한 정사각형(2의 제곱승)은 필수였다.
4. 횡 스크롤은 우리 아티스트가 모든 먼 배경 메쉬를 제거할 수 있게 했고, 대신에 그들을 간단한 2D 평면으로 변환했다.
   
5. 라이트 맵은 매우 소중하다.
6. 우리의 아티스트는 여러 경로사이의 추가적인 정점을 제거했다.
7. 적절한 텍스처 밉 레벨은 다른 해상도를 가진 장비에서 좋은 프레임 레이트를 가지는데 좋은 선택이었다.
8. 매쉬를 합치는 것은 아티스트가 할 수 있는 또 다른 성능 개선 방법이다.
9. 우리의 애니메이터들은 가능한 한 각 캐릭터 사이에 애니메이션을 공유할 수 있도록 노력했다.
10. 파티클에 대한 많은 반복은 미적인 부분과 성능적인 부분의 균형을 찾는 것이 필요했다. emitter의 수를 줄이는 것과 투명도 요구사항을 줄이는 것은 주된 도전중 하나였다. 

8 – 이제, 메모리 사용은 감소 되어야 한다!

많은 메모리를 사용하는 것은 성능에 부정적인 영향을 준다. 우리의 경우에, 메모리 초과로 인해 아이팟에서 많은 충돌을 경험했는데, 이는 매우 중요한 문제 였다. 우리의 게임에서 가장 큰 메모리 고객은 바로 텍스쳐였다.

1. 다른 텍스처 사이즈는 각 장비에 사용되어졌는데, 특별히 UI에 사용된 텍스처와 큰 배경이 바로 그것이었다. Shadow Blade는 유니버셜 빌드를 사용하지만, 시작하는 순간에 장비 사이즈와 해상도가 감지될 때, 각 애셋들은 로드 된다.
2. 우리는 사용하지 않는 애셋은 메모리에 올라가지 않도록 해야 했다. 우리는 프로젝트에서, 오직 프리팹 인스턴스에 의해 참조되는 애셋과, 절대 인스턴스되지 않는 애셋들이 완전하게 메모리에 로드되었는지를 확인해야만 했다.
3. 메쉬로부터 여분의 폴리곤을 제거하는 것은 도움이 되었다.
4. 우리는 몇몇 애셋의 수명관리를 다시 해야했다. 예를 들어, 메인 메뉴 애셋, 마지막 레벨 에셋, 게임 음악에대한 로드/언로드 시간을 수정해야 했다.
   
5. 각 레벨마다 그들의 동적 객체 요구사항에 잘들어맞고, 가장 적은 메모리 사용에 최적화된, 특별한 오브젝트 풀을 가져야 했다. 오브젝트 풀은 유연하고, 개발기간 동안 많은 객체들을 담을 수 있다. 그러나 게임 오브젝트 요구사항이 알려졌을 때, 그들은 구체적이어야 한다.
   
6. 메모리에 압축된 사운드 파일을 유지하는 것이 필요했다.

게임 성능 향상은 길고 도전적인 여행이며, 우리는 이 여행의 작은 부분을 경험하는 즐거운 시간을 가졌다. 게임 개발 커뮤니티에 의해 공우된 방대한 지식과 유니티에서 제공되는 매우 훌륭한 프로파일링 툴은 shaodw Blade의 목표 성능에 도달을 하게 해주었다.

여기에 우리의 게임, Shadow Blade의 트레일러가 있다.

http://youtu.be/tgSXLVAwZJs

Game website: shadowblade.deadmage.com

출처 : http://cafe.naver.com/unityhub/2246