어느 SNG 게임의 최적화 사례_1(FT)

SNG 게임을 만들 당시의 사례로 지금까지 겪었던 최적화 이슈와 게임에 맞는 최적화 방법에 대한 설계가 얼마나 중요한지를 스스로 되짚어 보고자 한다.

 

SNG 라는 게임의 특징(걱정되는 부분)

• 가장 큰 이 장르의 단점은 데이타가 한없이 쌓여간다는 것이다.
•  이게 가장 무서운 부분이다.

많은 생산건물 / 많은 연출을 가지고 이리저리 상호 작용을 해가며 점점 파생되는 더 많은 생산 루트에 대응해야 한다.

건물들 나름대로의 연출도 필요하겠지만 기본적인 이동 및 회전도 생각해야 하고 이밖에 생산건물들 간의 인터렉션 또한 골치거리들이였다. 

 

프로젝트 초기엔 2D로 계획했으나 여러 가지 사정으로 3D로 제작하게 되었고 그로 인해 Unity를 선택하게 되었다.

 

어느 정도 게임을 만들어 나가다 보니 슬슬 발목을 잡는건 최적화 문제였다. (FGT이후)

그때 부터 시작 되는 나의 난관들....

 

프로젝트 초기의 문제점

• 각 건물들 마다 달랐던 생산 방식과 연출
• 필드내 무수히 캐릭터가 등장
• 건물의 이동과 회전
• 3D로 SNG를 만들어본 경험자 없음 : 노하우가 없음

: 노하우가 없다는 것은 선택하는 방법들이 어떤 문제를 일으킬지 알수가 없다는 게 제일 무섭웠다.

아무리 검증을 한다고 해도 들어난 사례들 이외의 것들은 발생하면 대처 방법을 찾는 수 밖에 없다.

 

프로젝트 중반의 문제점

• 게임이 진행 될 수록 떨어지는 프레임 레이트
• 그에 동반된 발열

---

1. 생산 방식과 연출

1차 생산건물 : 밭

다양한 밭의 종류 / 경작시 필요한 캐릭터

수정전

• 종류는 50여종이며 캐릭터(농부)가 농지에서 작물을 재배하는 연출이 들어간다.
• 작물들을 3D로 표현 하며 그림자가 들어간다.
• 농작물은 3단계로 자라나는 표현을 한다.
• 조금씩 흔들리는 애니메이션을 갖는다.
• 건물의 이동및 회전이 가능하다.

문제점

• 50종이 넘는 작물의 컨셉이 다르다.
• 건물 회전시 -Scale을 사용하기 때문에 드로우콜이 깨진다.
  • 드로우 콜이 깨질때 건물이 가지고 있는 모든 오브젝트가 드로우 콜로 터진다.
  • 회전한 건물 뿐 아니라 Queue가 같은 매터리얼들도 같이 드로우 콜이 깨진다.
• 그림자를 Trans를 이용한 매쉬그림자를 사용한다(회전시 -Scale로 콜이 깨짐)
• 스킨드 캐릭터들이 각 건물마다 존재 해서 드로우 콜이 발생한다.

최적화 방법

• 일단 모든 밭에 들어가는 텍스쳐를 합쳐 1개의 메터리얼로 맞추고 Queue을 강제 지정 했다. (아틀라스작업)
• 건물의 회전을 막았다.
  • 결정적 이유는 회전을 해도 이미지에 큰 변화가 없어서 필요성을 느끼지 못했다.
  • 건물 / 캐릭터 / 그림자 의 -Scale을 사용하지 않게 되어 콜이 깨지는걸 막음
• 스킨드 캐릭터를 사용하지 않고 각 관절부위를 오브젝트 화 해서 Bone에 Link로 연결해서 로봇 처럼 만들어 배치 함.
  • 모든 밭이 경작 중 일때도 등장하는 캐릭터로 인한 드로우콜을 1개로 만들었다.
  • 다행스럽게도 화면을 최대로 확대해도 그래픽 컨셉과 각진 디자인이 어울어져 어색하지 않았다. (앗싸)

로봇농부 / 스킨드 매쉬 X

• 농작물의 흔들리는 연출 통일함
  • 단 3개의 연출 중에 랜덤으로 들어가게 하였고 애니메이션을 공유하여 사용
  • 작물이 완성되기 전에는 캐릭터가 나와서 분주히 움직이니 작물자체의 애니는 배제 하고 완성된 작물의 경우 캐릭터가 사라져서 허전할 수 있어 연출을 하게 됨

작업중 / 작업완료

 

2차 생산건물 : 광산 / 축산관련 농장

 

수정전

• 축산과 광산으로 사이즈는 1차 생산건물 보다 2배
• 연출 방법이 각 건물 마다 다름 (건물 및 캐릭터애니 필요)
• 10여종의 광산과 10여종의 농장 연출에 필요한 캐릭터 (중복가능)
• 건물의 이동 및 회전이 가능하다.

 

문제점

• 각각의 건물마다 연출이 다르다
• 각각의 건물마다 캐릭터가 추가 되고 애니메이션이 필요하다
• 건물 회전시 -Scale을 사용하기 때문에 드로우콜이 깨진다.
  • 드로우 콜이 깨질때 건물이 가지고 있는 모든 오브젝트가 드로우 콜로 터진다.
  • 회전한 건물 뿐 아니라 Queue가 같은 매터리얼들도 같이 드로우 콜이 깨진다.
• 그림자를 Trans를 이용한 매쉬그림자를 사용한다(회전시 -Scale로 콜이 깨짐)

최적화 방법

• 99개 이하의 face로 여러 오브젝트로 만들었다.
• 레벨에 따른 텍스쳐 및 메터리얼 통합 (아틀라스)
• 연출의 특징 파악 및 프로세스화
  
  • 건물 회전시 건물 및 캐릭터를 회전된 버전으로 제작 (Flip버전 / -Scale 사용X)
    • 늘어나는 리소스 : 연출 애니 수 / 건물 매쉬
    • 이유1. 건물을 회전할 때 -Scale 사용을 사용하는 것보다 Flip된 건물이나 캐릭터들 끼리 배칭이 되면 더 이득.
    • 이유2. 같은 건물이라도 중복해서 지을수 있으므로 따로따로 깨지는걸 방지 할수 있음
    • 이유3. 메터리얼을 통합했기 때문에 콜이 깨지면 기하급수적으로 콜이 늘어나는 것을 방지 할수 있음
  • 건물 / 캐릭터 / 그림자 / 애니를 오브젝트 애니로 만듬 (캐릭은 로봇)
  • 각 농장이나 광산에 어울리는 캐릭터를 선정하여 오브젝트 캐릭터(로봇)로 만듬
    • 회전시 게임 로직상 캐릭터 Mesh는 연출이 로딩된 후 호출 때문에 Flip버전 캐릭터는 필요 없었음.
    • Flip 버전 Animation 만듬.
      • 안그러면 본마다 -Scale을 먹게 되서 콜이 엄청 늘어남.

 

3차 생산건물

 

3차 생산건물

수정전

• 연출량이 가장 많고 눈에 가장 많이 띄는 건물들이 많다.
• 유저가 가지고 있는 시민들을 일일히 배치 해야 하고 성장 시켜야 한다.
• 3차 건물은 외부와 내부로 나누며 연출도 다르다.
• 건물의 이동 및 회전이 가능하다.

문제점

• -Scale을 하지 않는다고 해서 이득이 많지 않다.
  • 다른 생산 건물들은 중복해서 건설이 가능하지만 3차 생산은 오리지널 건물이다.
  • 건물 랜더링시 정상적일 때도 1콜이고 -Scale을 할때도 1콜이다.
• 연출이 건물 마다 다르다.
• 건물에 배치된 캐릭터는 유저가 마음대로 정할수 있다.
• -Scale을 이용한 그림자 배치로 다른 생산건물 / 데코 건물들의 그림자까지 콜이 깨질수 있다.
  • 그림자 메터리얼을 1개의 쉐이더에 1개의 메터리얼로 공유하고 있어 다른 건물이나 캐릭에 영향을 줄수 있다

최적화 방법

• 3차 생산건물은 -Scale을 억지로 막지 않았다.
• 1개의 오브젝트로 제작했다.
• 따로 Flip버전의 건물이나 캐릭터, 캐릭터애니메이션이나 건물 애니메이션 역시 만들지 않았다.
  • 이유는 위에서 말한 것 처럼 딱히 이득이 별로 없다.
  • 유저가 캐릭터를 마음대로 배치 할수 있기 때문에 전체 캐릭터들을 건드려야 할수도 있다.
    • 300개 이상의 오브젝트 캐릭터를(로봇)로 만들기에는 쫌 많이 힘들다 라고 판단함
  • 그를 위해서 다른 버전의 건물 /  캐릭터 / 캐릭터 애니 / 건물 애니를 만드는게 더 낭비였다.
  • 1개의 콜을 줄이기 위해 리소스가 너무 많이 들어간다.
• 그래서 내린 결정은 : 안고가자..
• 다만 그림자는 다른건물들과 같이 메터리얼을 사용하기 때문에 건물의 그림자 부분만 매쉬를 만들어 사용했다
  • 다른 건물들에서 콜이 깨지는 것을 방지 하기 위해서 결정했다.
  • 스크립트를 이용해 Flip시 Flip용 그림자 매쉬를 출력.
• 지금에 와서 이른 결론은 건물 제작시 뒷면을 없애지 않고 직접 로테이트를 하는 방식이 좋지 않았을까 생각한다.
  • 하지만 그 당시에도 도달한 결론이지만 그 사항에 투입할 여력이 없었다. (인원이 적어서)
  • 그래서 정말 어쩔수 없을 상황이 오게 되면 그때 하자고 결정 했다.

 

지형과 Bush

건물이 배치되지 않는 공간에는 Bush가 자리 잡고 있다.

이걸 베어내고 자리를 확보해서 건물들을 지어야 한다. (농장류게임의 기본)

Ground / Bush

최적화 방법

• 지형은 Static으로 고정 / 변경하지 않는 조건
  • 나중에 계절이 들어가게 되면서 눈이 쌓인 겨울 버전의 텍스쳐를 마련했다.
  • 빌드때 아틀라스 텍스쳐를 교환해서 빌드함.
• 아틀라스 작업 : 지형3개 / 바닥패턴 1개 / 부시 1개 
• 물 표현 통일 :  가볍게..가볍게..
• 오브젝트 배치시 -Scale을 사용하지 않기 위해 일일히 검수..

 

 

이외의 최적화 방법

• 건물들의 특성이나 레벨 디자인에 따른 노출 시기 고려하여 무조건 필요한 요소와 커스터마이징 요소를 분리 하였다
• 데코레이션 건물들의 경우
  • 필요하다면 텍스쳐를 아틀라스화 함
  • 필요하지 않다면 굳이 하지 않음
    • 유저들의 데코 설치 성향을 보고 공통화된 기준을 만들어 적용의 유무를 따짐.
    • 패턴 벗어난 유저라 해도 그 유저만 해당하지 않게 됨
    • 중복설치의 가능 여부가 가장 큰 기준
• 99개 이하의 Mesh 단위로 조각냄 (Batching)
  • 아틀라스기법을 사용할거라면 
  • 실질적으로 매쉬는 99개 단위로 나누어서 만들었다. 
  • 아틀라스 화 한 오브젝트나 건물 중에 100개 이상이 매쉬가 존재 한다면 그 단위로 콜이 쪼개진다.
  • 이를 회전 즉  Flip된 버전 까지 같이 Batching 하기 위해 매쉬를 잘게 쪼갰다.
  • 하지만 이 방법은 오브젝트를 로딩하는 수가 많아지게 되어 게임에 영향을 미칠수 있으니 신중한 선택이 필요하다. 콜을 줄일 것인지 오브젝트 로딩을 줄일 것인지. 신중하세요. 이 프로젝트의 경우는 콜을 자체를 줄이는 것이 이득이라고 판단했다. 데이타를 들어내거가 스테이지 마다 리셋을 할수 없기 때문이다.
  • 발열 문제도 있으니 신중하셔야 합니다.
• 생산완료시 펼쳐지는 아이콘의 향연.. (무서워 ㅠ_ㅠ)..
• 상황에 맞는 텍스쳐 아틀라스 작업

 

때에 따라 도를 넘는 UI

• UI / Eff의 아틀라스 작업
  • 각 건물들이 생산완료가 되면 토해내는 아이콘들 해상도도 높고 발생시키는 로직들도 달라서 어쩔수 없이 발생하는 아이콘과 이펙트들을 각 로직과 연출에 맞게 아틀라스 작업을 진행함
  • 하지만 중복 리소스는 어쩔수 없었다. 건들려면 클라이언트들이 해주어야 해서 일정 부분은 포기함.
  • 초반에는 게임오브젝트(캐릭터 포함)의 콜수 보다 아이콘의 콜수가 더 많았다.
    • 이를 부단히 설득해 최적화 작업을 함. (다들 바쁘니 설득이 더 힘들어)
• Road(길) :  만들때는 기존의 패턴으로는 Mesh의 Transform을 건들기도 하고 -Scale을 사용하기 때문에 새로운 패턴을 만들었다.
  •  
• 그래서 그 패턴대로 원화가 나오면 프리펩은 바로 복사해서 넣고 텍스쳐를 바꾸어 이름만 바꾸면 되는 방식으로 프로세스화 했다.
• 이를 토대로 매뉴얼을 제작하고 배포했다.

매뉴얼

• 이팩트 메터리얼 별로 Queue 지정

적극적인 Queue 지정

• Queue를 적극적으로 지정해 사용했다.
  • 그라운드 / 캐릭터 / n차 생산건물 / 데코 건물 / 부시 / 반투명 메터리얼 / 이펙트 메터리얼 등등으로 분류
  • 이는 관리를 측면에서 나중에 발생하는 문제를 보다 직관적으로 찾아 해당 매터리얼이나 이팩트의 문제 해결을 보다 빠르게 하기 위함 이였다. 
  • 처음에 작성은 번거로웠지만 나중에는 일일히 비어있는 랜터큐 찾지 않아도 되어서 보다 수월하게 후반 최적화를 진행할수 있었다.
  • 실제로 건물에 이펙트를 붙이거나 할때 사용한 중복 사용된 메터리얼들이 랜더링 순서에 걸릴 때나 연출에 의해 다른 카메라를 오버드로우 할때 등 발상하는 이상현상을 직관적으로 찾아 낼수 있어 편리 했다.

 

레벨 초반에 가벼운 게임을 만들 것인가 레벨 만렙에서 가벼운 게임을 만들 것인가.

믿는 구석 / 최후의 보루

 

: 만들어 놓고 생각 해보니 게임의 프레임레이트를 어떻게 유지하는 식으로 프로세스를 잡을지 고민이 되었다.

• 게임플레이가 쾌적해야 하는 것은 당연하다. 하지만 만드는 입장에선 특히나 점점 데이타가 쌓여지는 게임의 특성상 후반에 쾌적하지 않은 게임을 만들수밖에 없는 현실에 필요한건 타협이였다.
  • 그래서 남몰래 작업한 것들은 개발 버전을 나만 2개로 관리 했다. (단 목표한 프레임레이트는 유지해야함)
    • 초반부분에 일부러 최적화를 하지 않은 부분을 안은채 프레임레이트를 유지하고자 있는 힘껏 노력했다.
      • 플레이 버전에는 최적화 작업이 이루어진 빌드로 넣어 FPS를 더 올림.(더 쾌적해짐)
    • 개발 버전의 게임화면 Zoom IN/OUT을 1단계 정도 멀리놓은 상태에서 최적화 작업을 진행 했다
      • 참고로 1단계의 줌 조절만으로도 SNG 게임에서는 15 ~ 20% 의 프레임레이트를 올릴수 있었다.
      • 물론 배치한 상황이나 캐릭터의 밀집도에 따라 다르다.
    • 프레임레이트 측정은 Zoom Out 버전을 기준으로 잡았다.
  • 마지막으로 남은 최후의 최적화 방법은 Zoom Out단계를 제발 줄이는 것.
    • 그래서 나는 최후의 보루로 최대 줌아웃을 2번에 걸쳐서 써먹을 수 있는 비장의 카드를 가지고 있었다.
      • 막상 써먹지는 안았다. 아직 괜찬게 돌아가고 있어서... ㅎㅎ

 

돌아보면 참 허덕이면서 맞추어 나갔던 프로젝트 임에는 틀림 없었다.

텍스쳐 사이즈를 극악으로 줄이는 대신 글로벌한 라이팅을 갖기 위해 랜더투 텍스쳐 방식을 모든 분야에 사용해 제작이 번거로웠지만 리소스를 줄일수 있었고, 그래픽 디자이너들에게 왜 이런 방법들을 선택했는지에 대해서 구구절절 사정해야 했지만 어느정도 괘도에 올라오면 실수들을 줄일수 있었다. 하지만 난 자연스럽게 잔소리 많은 사람이 되었고, 디자이너들은 그래도 처음보다는 조금이라도 그래픽파이프라인과 최적화 방법을 터득했을 것이고, 단순하게 디자이너가 아닌 게임 개발자의 한사람으로서의 몫을 하게 될거라는 생각으로 그렇게 했던것 같다.

물론 신입이들이 대부분이라 너무 빠른 조기 교육이였겠지만 그들이 2~3년 지나고 나면 보일테지...

그래서 나는 나쁜 노친네가 되었다.. ㅠ_ㅠ.. 아 슬퍼!!