오즈라엘

Variation

게임에는 기본적으로 플레이어가 존재하고, 그 플레이어에게 방해가 되는 장애물이 존재합니다. 퍼즐류가 아닌 이상 이러한 장애물은 몹 또는 몬스터의 형태로 나타나게 되고, 게임의 재미를 좌우하는데 결정적인 역할을 하는 존재가 됩니다.

이미지 : 엔젤 스톤

이러한 몹의 종류가 적으면 사용자는 금새 지루해지게 됩니다. 때문에, 개발자는 매우 다양한 모습과 패턴을 갖도록 만들어야 합니다. 예를 들어 좀비 형태의 몹을 만든다 가정했을 때, 모자를 쓴 좀비, 창을 든 좀비, 뚱뚱한 좀비 등등 좀비라는 큰 카테고리 안에서도 다양한 모습의 좀비를 만들어내야 합니다. 이를 흔히 "다양화(variation)시킨다" 라고 표현합니다.

이미지 : PVZ

하지만 이 때 문제는 리소스의 용량 크기입니다. 완전히 각각의 종류마다 완전히 새로운 리소스로 따로 따로 제작하게되면 리소스의 크기가 커질 수 밖에 없게 됩니다.때문에, 이러한 다양화(variation) 작업을 거칠 때 리소스를 최소한으로 사용하는 방법을 사용해야만 합니다.

부품 모듈화

그 방법 중 하나가 각각 파츠별로 모듈화 시키는 방법입니다. 각 파츠별로 부품 모듈을 만들어 놓고 프라모델이나 레고처럼 모듈을 조립하여 다양한 모습을 만들어 내는 것입니다. 예를 들어 로보트를 팔, 다리, 몸통, 총구 등으로 나누어 여러 종류로 제작한 뒤 이를 조립하여 다양한 종류의 로보트를 만들어 내는 것입니다. 보통 로보트나 비행기 등 강체로 이루어진 것 들이 이러한 조립식으로 많이 만들어집니다. 에셋 스토어에서도 마찬가지로 이러한 조립식 에셋들을 많이 찾아볼 수 있습니다. 

이미지 : 에셋스토어

텍스쳐 변경

또 다른 방법으로는 텍스쳐만 바꾸는 방법도 존재합니다. 동일한 메시에 텍스쳐만 바꿔서 다른 모습을 연출해주게 되는 것입니다. 주로 인간형 케릭터에게 의상을 다양화 시킬 때 이러한 방법을 사용합니다.  

이미지 : 에셋스토어

파츠 컬러

이 글에서 소개할 또 다른 방법으로는 파츠 컬러를 변경하는 방법입니다. 앞서 방금 언급한 텍스쳐를 바꾸는 방식이나 메시 모듈들 조립하는 방식과는 달리, 메시와 텍스쳐는 교체하지 않고 하나의 텍스쳐와 하나의 메시만 사용하는 방식입니다. 때문에 앞서 언급한 방식들에 비해서 리소스를 크게 아낄 수 있습니다. 다만, 텍스쳐를 통채로 바꾸는 것이 아니기 때문에 전체적인 패턴과 모양은 그대로 유지하기 때문에 한계가 있습니다. 대신 전체적인 혹은 부분적인 색상을 바꿀 수 있기 때문에 주로 의상의 염색 시스템에서 활용되기도 합니다. 

이미지 : 레이더즈

또한 다양화 작업 말고도 RTS나 MOBA 등 대전 게임에서 팀 구분을 위한 색상으로 활용될 수도 있습니다.

이미지 : 스타크래프트2

이 글에서는 이러한 파츠 컬러 방식을 구현하는 것에 대하여 자세히 설명을 해볼까 합니다. 기본 원리는 간단합니다. 메시의 기본 albedo 색상 외 컬러를 변경할 마스크 영역을 준비합니다. 단순한 파츠 컬러 적용 여부를 나타내는 크레이스케일 값이기만 하면 되기 때문에 albedo 텍스쳐의 알파 채널에 이를 활용하면 됩니다. 물론, 대신 불투명 오브젝트에만 적용이 가능해진다는 제약은 있습니다.

그 예로 다음과 같은 로보트 Kyle에 이를 적용하여 보겠습니다.

이 모델은 불투명으로 만들어져 있어서 실제로는 다음과 같은 albedo 텍스쳐의 RGB만 사용합니다.

이 텍스쳐의 Alpha 채널을 다음과 같이 칠하여 파츠 컬러의 마스킹으로 사용하도록 합니다. 다음 이미지는 GIMP툴에서 보여주는 Alpha 채널의 모습입니다. 검은색이 1을 나타내고 회색의 체크무늬가 0인 영역을 의미합니다.

이 Alpha 채널의 역의 값을 마스킹으로 사용하여 (위 이미지의 회색 체크무늬 영역이 파츠 컬러가 되도록) 적용하는 것이 최종 목표입니다. 샘플 프로젝트를 올려두었습니다. 이 링크를 통해 다운받으셔서 확인해보실 수 있습니다.

쉐이더가 적용 된 마테리얼에서 Parts Color 색상을 변경할 수 있습니다.

이 색상을 바꾸면 이에 따라서 로봇의 파츠 컬러가 변경되어 보여집니다.

이 방식은 원리도 간단하기 때문에 쉐이더 코드도 크게 복잡하지 않습니다. 샘플 프로젝트에 포함 된 LambertUseColorPart.shader를 살표보도록 하겠습니다.

27번째 라인에서 albedo 텍스쳐의 값을 읽은 뒤 29번째 라인에서 alpha 채널의 값을 뒤집어줍니다. 이는 작업자의 성향에 따라 파츠 컬러 적용 값을 1로 둘것인가 0으로 둘 것인가에 따라 다릅니다. 머티리얼의 Invert Parts Color Mask 체크 여부에 따라 수행 여부가 달라집니다.

35번째 라인이 이 쉐이더의 핵심 구문입니다. 파츠컬러의 마스킹 값에 따라서 흰색과 지정된 색상 값을 보간합니다. 그후 그 값을 albedo와 곱하여 최종 albedo 값을 결정합니다. 결과적으로, 마스크가 1이면 albedo에 지정 컬러를 곱한 결과가 됩니다. 반대로 마스크가 0이면 원래의 albedo 색상을 그대로 사용합니다.

만일 머티리얼에서 Interpolated Parts Color가 체크되어 있다면 35번째 라인 대신 33번째 라인이 수행됩니다. 이는 albedo값과 지정 색상 값을 바로 보간합니다. 이는 흰색과 보간한 뒤 albedo에 곱해주는 결과와는 미묘한 차이를 가집니다.

다음 로보트의 몸통 이미지는 각각 33번 라인과 35번 라인을 수행 했을 때의 차이를 보여주고 있습니다. 첫 번 째 이미지는 35번 라인이 수행된 모습입니다. albedo와 곱하여 사용한 결과이기 때문에 albedo 자체에 새겨놓은 AO 라이팅이나 얼룩등이 그대로 살아있습니다. 만일 텍스쳐 자체에 라이팅이나 AO등을 새겨놓는 식으로 작업한다면  Interpolated Parts Color가 비활성화 되어야합니다.

이 두 번 째 이미지는 그 반대로 33번 라인이 수행된 모습입니다. albedo와 바로 보간해서 사용하기 때문에 마스크가 1인 영역은 albedo 텍스쳐의 모습을 완전히 없애버립니다. 첫 번 째의 이미지와는 달리 몸통에 페인트가 덧 칠해진 것 같은 느낌입니다. PBS 대응 텍스쳐는 albedo에 AO 및 라이팅이 포함되어서는 안되기 때문에, 만일 PBS 대응으로 작업하는 이미지라면 이 모습이 용이할 수도 있습니다. (예를 들어서 금속 물질 위에 칠해져있는 페인트가 벗겨져 있는 모습이라면) 

한계

이 쉐이더는 알파채널을 이용하여 한번에 한가지 색상만 적용합니다. 웬만한 경우에서는 한 가지 색상만 적용해줘도 크게 무리는 없습니다. 만일 푸품 모듈화 방식과 같이 사용한다면 더 다양한 조합을 만들 수도 있을 것입니다.

하지만 단일 메시만 사용하는 경우라면 단일 색상만 적용 가능 한 것이 조금 답답할 수도 있겠습니다. 그러한 경우에는 albedo 텍스쳐의 alpha 채널을 마스크로 활용하는 것이 아니라, 아예 마스크 텍스쳐를 별도로 제작하면 더욱 다양하게 활용이 가능합니다. 색상을 4가지를 지정하고 마스크 텍스쳐의 r,g,b,a 채널 모두 각각의 마스킹으로 활용하면 4가지 색상을 적용할 수 있습니다. 다만 추가적인 텍스쳐가 사용되므로 약간의 성능 감소는 있을 수 있습니다. 그렇다 하더라도 잘만 조작하면 적은 텍스쳐 메모리만으로도 훨씬 다양한 다양화(variation) 효과를 볼 수 있기 때문에 충분한 가치가 있습니다.

쉐이더 작성이 익숙하신 분이라면 쉐이더를 직접 수정하여 사용하시면 되고, 그렇지 않은 분이시라면 에셋 스토어에서 받아서 사용하시면 됩니다. 이 에셋이 제가 설명드린 것과 비슷한 작동을 수행하는 쉐이더를 사용하고 있습니다. ( 사실, 컬러 4개 지정하는 쉐이더를 올릴 까 했는데, 이 에셋이 유료로 판매되는 것을 보고나니 상도덕(?) 상 그러지를 못하겠네요;;)

이미지 : 에셋스토어

샘플 프로젝트 다운로드 링크 : https://drive.google.com/file/d/0B70AOyGiQJsGY2dEakU4Y2Q4WWs/view?usp=sharing

게임은 어떻게 만드나요?

라는 질문에 뭐라고 대답해야 할까요? 누군가는 어떤 말을 해야할 지 고민을 할 테고, 누군가는 쌍욕부터 할 지도 모르겠습니다. 어찌되었건 이런 질문을 받았을 때 공통적으로 느끼는 감정은 '혼란'일 것입니다. 대답해주려니 막막하고 어디서부터 풀어나가야 할 지 혼란스러워진다는 것입니다. 질문을 받은 사람이 이러한 감정을 느끼는 원인은 간단합니다. 바로 질문 자체가 막연하기 때문이죠.

제가 뜬금없이 이런 질문을 언급하는 것이 의아하실지도 모르겠습니다. 이런 질문을 하는 사람이 있을까 싶으시겠지만 실제로 인터넷 커뮤니티(특히 뇌입어)에 많이 올라오는 질문 중 하나입니다. 사실 이러한 비(非)개발 커뮤니티는 이런 허접한 질문이 올라올 수도 있다는 생각이 들 수도 있겠습니다. 하지만, 중요한 것은 개발 관련 포럼이나 커뮤니티에도 이러한 수준의 질문이 가끔 목격된 다는 것입니다. 제가 다소 공격적으로 "수준"이라는 표현을 사용했지만, 여기서 말하는 "수준"이라는 것이 별 뜻은 아닙니다. 질문 내용의 기술적인 난이도가 낮아서 수준이 낮다고 표현하는 것이 아닙니다. 기술적인 수준은 낮아도 질문 자체의 수준이 높은 경우는 얼마든지 많습니다. 제가 말하는 "수준이 낮다"고 표현하는 것은 질문 내용에 성의가 없기 때문입니다. 

예를 들어서 누군가 다음과 같은 질문을 올렸다 생각해보겠습니다.

광선검은 어떻게 만드나요?

이 질문이 뭐가 문제인지 의아해하시는 분도 계실지도 모르겠습니다. 하지만, 제가 보기에는 이 질문이 앞서 언급하였던 게임을 어떻게 만드냐에 대한 질문과 다를 바가 없어보입니다. 마찬가지로 막연하고 정보가 부족하기 때문입니다. 이로 인해서 받아들이는 사람 마다 질문의 의도를 각자 다르게 해석하고 각자 다른 초점의 정보를 말해주게 될 것입니다. 

"광선검"이라는 단어를 들으면 어떤 사람은 스타워즈의 라이트세이버를 떠올릴 것이고 어떤 사람은 건담의 빔샤벨을 떠올릴 것입니다. 

어떤 사람은 모바일 타겟으로 파티클로 빔샤벨을 만드는 방법을 안내할 것이고 어떤 사람은 PC 타겟으로 이미지 블룸 효과를 처리하는 방법을 안내할 것 입니다. 어떤 사람은 그래픽 리소스를 제작하는 방법을 안내할 것이고 어떤 사람은 손잡이에서 빔이 나오는 에니메이션 처리를 수행하는 스크립트를 안내할 것입니다. 이처럼 질문부터가 모호하고 정보가 없으면 질문자와 답변자 모두에게 만족으러운 결과를 도출하지 못하게 될 것입니다. 이는 당연한 결과입니다.

하지만, 의외로 이러한 모호한 질문들이 생각보다 많이 발견됩니다. 물론 예를 들어 말씀드린 질문은 극단적인 예일 뿐이고 사실 더 많은 정보를 포함한 질문들이 대부분입니다. 하지만 여전히 적은 정보만으로 모호한 질문을 물어보는 글들이 많이 보이곤 합니다. 비단 유니티 관련 포럼 뿐 아니라 언리얼, 코코스 등 다른 엔진 관련 포럼에도 나타나는 현상들이고 게임 뿐 아니라 개발 관련 된 커뮤니티라면 어디에서든지 존재하는 현상들입니다.

때문에 질문을 올리는 방법에 대한 가이드를 말씀드리고자 합니다. 물론 이 글이 객관적인 것은 아니며 어떤 기관에서 표준으로 인정한 양식도 아닙니다. 단지 제 개인적인 경험과 노하우를 통해 말씀드리는 것이니 절대적인 가이드라기보다는 참고사항으로만 생각해주시면 감사하겠습니다. 

육하원칙

기본적으로, 육하원칙(5W1H)을 생각하시면 됩니다. 누가,언제,어디서,무엇을,어떻게,왜 육하원칙은 초등학교에서  기본적으로 배우는 만큼 기초적이고 중요한 원칙입니다. 대부분의 질문은 이 육하원칙에서 한가지를 도출하는 과정이 될 것입니다. 어떠한 현상이 왜 생기는지를 물어보고자 한다면 나머지 다섯가지인 누가,언제,어디서,무엇을,어떻게에 대한 정보가 제공이 되어야 할 것입니다. 반대로 어떻게 해야하는지를 물어보고자 한다면 나머지 다섯가지인 누가,언제,어디서,무엇을,왜가 제공이 되어야 할 것입니다. 무조건 이 여섯가지 요소를 반드시 지켜야 한다는 것은 아닙니다. 질문에 따라서 모든 요소가 들어갈 필요는 없는 경우도 있습니다. 다만, 가능한 이 원칙에 입각하여 질문을 작성한다면 크게 모호해질 일은 없을 것입니다. 물론, 이 요소들을 명시적인 도표로 만들어서 작성하거나 하라는 것이 아닙니다. 글의 문맥 안에 이러한 요소들이 명시적이나 암묵적으로 포함되기만 하면 됩니다. 사실, 각각의 요소들에 대한 명확한 기준은 없습니다만 각각의 요소에 주로 담기게 되는 내용을 설명드려볼까 합니다.

누가(who)

"누가"는 대부분 질문자 본인이라 생각 할 수도 있습니다만 당연히 질문자가 이름이 뭔지 거주지가 어딘지따위는 중요하지 않습니다. 중요한 것은 직군이 어디인지 지식 수준이 어느정도 인 지 입니다. 그래야 어느정도 레벨까지 설명을 해 줘야 할 지 가늠할 수 있기 때문입니다. 다만 이러한 것은 질문 내용에서 간접적으로 표현 되는 경우가 많아서 명시적으로 언급해주지 않아도 되는 경우도 많습니다. 예를 들어서 NavMesh.Raycast()의 성능에 대해 물어는 글이 있다 치면, 그 질문의 작성자는 일단 프로그래머이일 것이며 네비게이션 메시에 대한 기본 지식은 가지고 있다고 가정해도 무방할 것입니다. 또한, "누가"는 사람에만 국한 되는 것이 아니라 시스템의 객체가 될 수도 있고 오브젝트의 인스턴스가 될 수도 있는 등 다양한 시각으로 반영될 수 있습니다.

언제(when)

"언제"는 몇시 몇분 몇초의 절대적인 시간이 아니라 재현 시퀀스의 타이밍이 되는 경우가 대부분입니다. "버튼을 세번 눌렀을 때" 혹은 "앱이 수행되자마자 항상" 등 재현 시퀀스상의 시간이 될 수도 있습니다. 때문에, "어떻게"와 같이 묶여서 표현 될 수도 있습니다. 

어떻게(how)

그렇다고해서 "언제"와 "어떻게"가 동일하다는 이야기는 아닙니다. "어떻게"는 주로 구현 방법에 대한 설명이 되는 경우가 많습니다. 어떤 기능을 어떻게 구현했냐에 대한 설명이 대부분일 것입니다. 주로 이 부분에 대한 설명이 자세할 수록 좋습니다.

구현을 어떻게 했고 무엇이 문제인 지에 대한 설명은 사실 말로만 설명하기에는 부족한 경우가 많습니다. 이러한 경우에는 보조적인 자료를 사용해주는 것이 좋습니다. 특히 코드에 관한 것을 물어볼 때에는 반드시 소스 코드가 포함되어야 합니다. 무슨 함수를 어떻게 썼다라는 것을 말로만 설명하는 것이 아니라 해당 코드를 반드시 올려주어야 합니다. 더 나아가서 프로젝트를 올려주시면 정확한 판단을 하기가 훨씬 수월해집니다. 포럼 사이트나 게시판마다 파일 업로드 용량 제한이 달라서 프로젝트 파일을 직접 올리지 못하는 경우가 대부분입니다. 구글 드라이브나 드랍박스에 파일을 올린 후 링크를 걸어두시는 식으로 하면 여러 커뮤니티에 질문을 올릴 때 유용합니다. 물론 프로젝트를 올려두었다 하더라도 문의하고자 하는 부분의 핵심 코드는 본문에 포함되어야 합니다.

어디서(where)

"어디서"는 말 그대로 문제가 발생하는 위치입니다. PC나 모바일 등 물리적인 위치가 될 수도 있고, 어느 클래스 어느 함수에서 발생하는 지 등의 논리적인 위치가 될 수도 있습니다. 위치 역시 최대한 자세히 적어주시는 것이 좋습니다. 예를 들어서 모바일 기기에서만 발생하는 문제라면 단순히 "모바일 기기"라는 표현으로 끝내는 것이 아니라 해당 기기의 모델명과 OS 버젼 등은 필수적으로 기입되어야합니다.

무엇을(what)

"무엇을"은 6가지 요소 중 가장 중요한 요소가 될 수도 있습니다. 구현하고자 하는 것이 무엇인 지 혹은 문제가 발생하는 현상이 무엇인 지 등 원하는 것이 정확히 기술되어야 합니다. 

어느날 사장님이 오셔서 이런 말을 했다고 가정해보겠습니다.

보스를 추가하고싶은데 메카닉이면서도 허접해보였으면 좋겠어. 또한 모던하면서도 클래식한 느낌이 나야해

이 말만 툭 던지고 자리로 돌아간다면 사장이고 뭐고 다 때려엎고 싶을 지도 모릅니다. 설명이란 것은 자세하면 자세할 수록 좋습니다. 여기서만큼은 과유불급이란 것은 존재하지 않습니다. 하지만 사실 아무리 말로 잘 표현하더라도 정확한 표현을 하는데에는 한계가 있을 수 있습니다. 백마디의 말 보다는 한장의 이미지가 더 효과적이라는 것을 항상 염두해두시길 바랍니다. 이까 그 사장님이 다시 돌아와서 다음과 같은 이미지를 던져주고 간다면 그나마 화가 조금은 풀릴 지도 모르겠습니다.

왜(why)

"왜"는 불필요한 정보라고 느낄 수도 있겠지만 이 역시 상당히 중요한 정보입니다. 만일 특정 함수의 오류에 대해 문의하는 것이라면 왜 그 함수의 사용 의도가 파악되어야 합니다. 그래야만 의도하는 방향 내에서 해결책을 제시할 수 있습니다. 또한, 용도에 맞지 않는 사용법으로 사용하는 것을 막을 수도 있습니다. 혹은, 더 나은 방법이 제시 될 수도 있습니다. 예를 들자면, 주기적인 타이밍으로 들어가는 도트데미지를 Update() 함수에서 구현하는 방법에 대한 문의를 한다면 코루틴을 사용하는 것으로 제안 할 수도 있을 것입니다.

아웃라인(outline)

육하원칙 외에도 글의 아웃라인을 서론과 본론으로 갖춰주시는게 좋습니다. 글을 자세히 적다보면 글이 길어질 수 밖에 없는데 서론 없이 바로 본론으로 들어가버린다면 질문에 대한 집중력이 떨어질 수 밖에 없습니다. 그렇다고 너무 아웃라인의 형태에 집착하지 않아도 됩니다. 글의 도입부에서 어떤 주제에 대한 질문인지 대략적으로 밝히고 진입하는 정도만 되어도 충분한 아웃라인을 갖추었다고 봐도 무방합니다.

퇴고

사실, 육하원칙이니 글의 아웃라인이니 그런 것 보다는 퇴고가 가장 중요합니다. 글을 길게 썼든 짧게 썼든 글을 최종 업로드 하기 전에 퇴고를 반드시 거쳐주시길 바랍니다. 제3자의 입장으로 글을 다시 한번 읽어가면서 내용이 이해가 가는지를 판단해보십시요. 의외로 자신이 글을 이해가 가지 않게 썼다는 것을 발견 하는 경우가 많을 것입니다.

이렇게까지 많은 것을 고려하면서 질문글을 써야하나 하는 의문을 제기하는 분도 간혹 계십니다. 물론 질문이란 것이 가볍게 던질 수도 있는 것입니다. 다만 자세한 질문을 할 수록 더 나은 답변과 토론이 오갈 수 있을 것이라 생각합니다. 또한, 질문을 적는 사람은 개인이지만 질문은 많은 사람들이 읽습니다. 더 많은 사람들이 더 많은 시간을 투자해서 함께 고민하는 것이기 때문에 질문 글에도 그만큼의 정성이 들어가는 것이 예의라고 생각합니다.

다시 광선검

마지막으로 다시 광선검을 예로 들어보겠습니다. 

광선검은 어떻게 만드나요?

라는 표현은 다음과 같이 바꿀 수 있겠습니다.(실제의 문의 내용이 아니라 제가 가상으로 작성한 글입니다.)

안녕하세요. 광선검의 검흔 효과 구현에 대한 조언좀 구하고자 문의글을 올립니다. 저희가 모바일 액션 RPG를 만들고 있습니다. D&D나 던파같이 사이드뷰인데 배경이 미래다보니 스타워즈 광선검이 무기로 등장합니다. 광선검 자체를 만드는 것은 문제가 없었습니다만 검흔 효과를 만드는데 애를 먹고있습니다.

검광 부분은 막대기 모델에 따라서 검광 텍스쳐 판때기 2개를 X자로 교차되게 간단하게 만들었습니다. 케릭터에게 쥐어줘보니 뭐 그럴싸합니다. 모바일이라 화면도 작은데다가 광선검이 클로즈업되서 보일 일이 없다보니 판때기로 박은게 티가 잘 안납니다. 근데 단순히 이것만 가지고 검을 휘둘러보니 뭔가 어색합니다. 영화에서 보면 검을 휘두르면 삼각형 모양의 블러가 생깁니다. 게임에서 이런게 안생기니 심심한 느낌입니다.

저는 단순 모델러라 이펙트를 잘 모릅니다. 신생팀이라 이펙터도 따로 없구요. 그래서 옆자리 프로그래머랑 같이 에셋스토어 뒤져서 trail 이펙트를 붙여봤는데 영화에서의 느낌은 나지 않네요. 그냥 일반적인 무협 게임의 검기같은 느낌일 뿐 광선검 특유의 느낌이 나지 않습니다. 검흔 자체가 불투명이어야하는데 빨간 화살표처럼 투명 그라데이션이 들어갑니다. 전체적인 헤일로 효과 없이 노란색 화살표처럼 검 진행 방향의 단면이 선명하게 떨어져버리구요. 영화에서는 순간적으로 검의 모양이 부채꼴로 변하는 듯한 느낌이라 이 이펙트와는 전혀 다른 느낌입니다. 

영화에서의 느낌을 내려면 어떤식으로 구현해야할 지 아니면 어떤 에셋을 사용해야 할 지 조언좀 부탁드립니다. 혹시 몰라서 파일을 올려두었습니다. 프로젝트라 광선검 부분만 따로 패키지로 추출한 점 양해 부탁드립니다.

다운로드 링크 : 어쩌고저쩌고

감사합니다 :)

P.S. 먹튀는 악질 행위입니다. 가끔 답변을 받으면 답변만 확인하고 질문들을 삭제하는 분도 계시는데 이러한 행위는 비매너 행위입니다. 커뮤니티는 다른 사람들과 정보와 노하우를 공유하는 공간입니다. 혼자만 알고싶으면 애초에 커뮤니티에 질문을 올리는 것 부터가 모순이라는 점을 말씀드리고 싶습니다.

로보트 이미지 출처 : Stephane Halleux

게임 trail 효과 이미지 출처 : SWTOR

유니티 5.1부터는 unity analytics가 기본적으로 통합되었습니다. 더 이상 플러그인을 사용하지 않아도 됩니다. 오히려 기존 플러그인은 제거하시는 것을 추천합니다. 다만 이로 인해서 사용법이 조금 바뀌었습니다.https://analytics.cloud.unity3d.com > 좌측 메뉴 INTEGRATION > 우측 상단의 5.1 에서 확인 가능합니다.

이 내용을 참고로 바뀐 점을 요약해보자면 다음과 같습니다.

우선, 프로젝트 아이디를 터이상 코드로 적지 않습니다. 대신 플레이어 셋팅에 아이디를 적게 되었습니다. 따라서 UnityAnalytics.StartSDK() 함수가 제거됩니다.

또한, 인터페이스 이름이 변경되었습니다. 기존 UnityAnalytics 에서 UnityEngine.Analytics 으로 변경되었습니다. 따라서 커스텀 이벤트를 사용하고 계신다면 이 부분 코드를 바꿔주셔야합니다.

이 이외에는 바뀐 부분이 크게 없어서 이 부분만 신경써주시면 무리 없을 듯 합니다.

유니티 배우려는데 무슨 언어로 배워야할까요? C#? 아니면 자바스크립트?

가끔 이러한 질문들을 듣곤 합니다. 일단 이 질문에 대한 대답을 먼저 드리자면 당연 C#입니다. 유니티는 C#과 자바스크립트 두 언어를 지원하기 때문에 유니티 입문 시 이 두 언어 중 무엇으로 사용해야 할 고민이 되곤 합니다. 하지만 고민하실 필요 없이 C#으로 선택하시길 추천드립니다. 

이유는 간단합니다. 많은 사람들이 사용하기 때문이죠. 이는 구글트렌드로 살펴보더라도 극병하게 드러납니다. 물론 구글 트렌드가 객관적이고 정확한 기준 자료가 될 수는 없겠지만, 시간이 지날수록 자바스크립트보다는 C#이 대세로 가고 있음을 확인 하실 수 있습니다.

이미지 : 구글 트렌드

그러다보니 당연히 많은 참고 자료들이 C#으로 되어있습니다. 기능 구현이나 알고리즘 자료들 뿐 아니라 각종 플러그인의 샘플들도 C# 위주로 되어있습니다. 물론 언어의 견고함이라든가 방대한 라이브러리등 더 많은 선택 기준이 있겠지만, 입문하시는 입장에서라면 대세가 C#이라는 이유만으로도 충분하리라 생각합니다.

간혹 SI에서 자바를 다루었거나 웹에서 자바스크립트를 다루었다는 이유로 자바스크립트를 선택하려는 분도 계십니다. 하지만 이는 잘못된 판단입니다. 

여기서 잠깐 질문 하나 하겠습니다. 오리와 오리너구리와 KOF이오리의 공통점은 무엇일까요? 

바로 이름에 오리가 들어가는 것입니다. 그것 말고는 서로간에 전혀 공통점이 없습니다. 자바와 자바스크립트와 유니티자바스크립의간의 관계도 이와 마찬가지입니다. 서로간에 전혀 공통점이 없다고 봐도 무방합니다. 문법이 비슷해보이지만 실제로 파고들어보면 전혀 다른 언어들입니다. 그러므로 그런거 신경쓰지 마시고 그냥 C#으로 사용하시는 것을 추천드립니다.

"모바일 기기의 Tile Based Rendering(타일 기반 렌더링)과 유니티에서의 주의 사항 #1 : TBR의 이해"에서 이어지는 글입니다. 

앞선 글에서 설명드린 바와 같이 모바일에서는 타일 단위로 쪼개서 렌더링하는 방식을 사합니다. 그러다보니 전통적인 렌더링 방식에서와는 조금 다른 주의 사항이 몇 가지 존재합니다. 

알파블렌딩(Alpha Blending) VS 알파테스트(Alpha Test)

전통적으로 데스크톱 게임의 리소스에는 알파블렌딩보다 알파테스트의 사용이 권장되어왔습니다. 불투명한 철망이라든가 찢어진 옷감같은 경우는 불투명하기때문에 비싼 블렌딩 연산을 사용하기보다는 알파테스트를 사용함으로써 픽셀 연산도 절약하자는 의도였습니다. 하지만 모바일의 TBR(Tile Based Rendering, 타일 기반 렌더링)에서는 정반대로 알파테스트보다는 알파블렌딩의 사용이 권장됩니다. 

알파테스트처리를 하기 위해서는 픽셀쉐이더에서 동적분기(if문)가 사용됩니다. 데스크톱에서는 쉐이더의 동적 분기가 고속으로 처리되지만, 모바일에서는 동적 분기 성능이 취약합니다. 때문에 알파테스트는 쉐이더의 성능윽 하락시키는 원인이 됩니다.

게다가, TBDR(Tile Based Deferred Rendering, 타일 기반 지연 렌더링)에서는 픽셀 차폐의 고속 처리를 깨트립니다. 앞서 언급했다시피 TBDR에서는 여러 드로우콜의 버텍스 쉐이더 결과를 모아두었다가 은면 제거(Hidden Surface Removal)를 거친 뒤 실제 보이는 픽셀만 처리합니다. 하지만 이는 알파테스트를 사용하지 않는 완전한 불투명메시일 경우에만 해당됩니다. 알파테스트를 사용하면 버텍스 처리 단계에서는 해당 폴리곤이 차폐 되는지의 여부를 판단할 수 없기때문에 Deferred 처리를 깨트릴 수 밖에 없게됩니다.

유니티에서는 이를 방지하기위해서 완전 불투명 오브젝트들을 모두 렌더링처리한 후에 알파테스트 오브젝트들을 렌더링합니다. 따라서 알파 테스트를 제한적으로만 사용한다면 그렇게 치명적이지는 않습니다. 하지만 애초에 TBDR 칩셋의 구조가 알파테스트 처리에 적합하지 않기 때문에 알파테스트를 사용하지 않는 것이 좋습니다. 그런 이유로, 유니티의 내장 쉐이더 중 Mobile 카테고리에는 알파 테스트 쉐이더가 존재하지 않습니다.

반면에, 알파블렌딩은 데스크톱에 비해서 고속으로 처리가됩니다. 알파블렌딩과정은 출력 내부적으로 대상 버퍼의 읽기/쓰기가 발생합니다. 데스크톱에서는 DRAM에 존재하는 프레임버퍼 전체에 접근해야하기때문에 높은 대역폭을 잡아먹게됩니다. 하지만 TBR에서는 이 처리가 타일 단위로 이루어지고 칩 내부에 존재하는 메모리에서 이루어지므로 고속으로 처리됩니다.

오버드로우

다만 명심해야 할 것은 알파 블렌딩 처리 자체가 빠르다는 것일 뿐이지 오버드로우에서 자유로와진다는 것은 아닙니다. 예를 들어서 넓은 영역의 파티클을 높은 밀도로 뿌리는 것은 여전히 오버드로우 문제를 일으켜서 성능 저하로 직결됩니다. 모바일은 쉐이더 성능이 기종에 따라 천차만별이므로 오버드로우로 인해서 쉐이더 싸이클이 낭비되는 것은 치명적인 문제가 됩니다. 웬만하면 불투명 오브젝트 위주로 리소스를 만들기를 권장합니다. 알파 블렌딩 오브젝트 또는 파티클은 오버드로우를 최대한 피해서 사용하시기를 권장합니다.

로우 폴리곤

너무나 당연한 이야기라 뜬금없어 보일수도 있겠지만 많은 폴리곤을 처리하면 성능이 하락합니다. 게다가, TBDR에서는 많은 폴리곤 처리의 부담이 더욱 큽니다. 앞서 설명드린 버텍스 쉐이더의 결과물들을 담아두는 파라미터 버퍼(Parameter Buffer)의 크기는 당연하게도 무한하지 않습니다. 따라서 이 버퍼가 넘쳐버리면 더 이상의 버텍스 쉐이더 결과물을 받아들이지 못하고 버퍼를 비워줘야합니다. 이 버퍼를 비워주기 위해서는 타일의 픽셀 처리 후 프레임버퍼로 출력하는 사이클을 거쳐야합니다. 때문에, 이론상으로는 TBDR에서는 픽셀의 오버드로우가 발생하지 않아야하지만, 현실적으로는 폴리곤이 많을수록 오버드로우가 발생하게 발생하게 됩니다. 그러므로 오브젝트의 렌더링 퀄리티를 높여야한다면 버텍스를 늘리는 것 보다는 픽셀쪽 연산을 늘리는 것이 오히려 이득일 수도 있습니다.

렌더 텍스쳐(Render Texture)

렌더 텍스쳐를 사용하면 유니티 내부적으로 렌더 타겟(Render Target)을 변경하는 행위를 거치게됩니다. 이러한 렌더타겟을 변경하는 행위는 데스크톱에서도 성능을 잡아먹는 행위가 됩니다. 렌더 타겟을 바꾸기위해서는 CPU가 GPU를 대기하는 과정을 거치게되면서 CPU와 GPU의 병렬 관계가 잠기 깨지는 현상이 발생하기 때문입니다. 

게다가, TBDR에서는 더욱 치명적인 행위가 됩니다. 렌더 타겟을 변경할 시에는 현재 파라미터 버퍼에 쌓여있는 데이터들을 모두 처리해주고 프레임버퍼에 출력합니다. 그 후 다음 렌더 타겟을 위해서 파라미터 버퍼를 비워줍니다. 이런식으로 렌더 타겟을 바꿀 시 deferred 사이클을 추가적으로 처리해줘야 합니다. 때문에 유니티의 카메라에서 타겟 텍스쳐(Target Texture)로 렌더 텍스쳐를 사용하는 경우에는 TBDR의 효율이 떨어지게 됩니다.

이미지 후처리 효과(Image post process Effect)

최근 디바이스들은 컬러 그레이딩이나 블룸 효과 등 이미지 후처리들을 사용할 수 있을 만큼 성능이 좋아졌습니다. 하지만 이러한 이미지 후처리들을 너무 남발해서 사용하면 안되고 필요한 것만 선택적으로 사용해야 합니다. 

우선, 이미지 후처리들은 내부적으로 렌더 타겟을 변경하는 행위를 합니다. 하지만, 더 큰 문제는 대역폭입니다.  물론 픽셀 처리 능력도 관건이지만 대역폭이 더욱 큰 문제가 됩니다. 이미지 후처리들은 현재 렌더링 한 결과를 담고있는 렌더 타겟을 픽셀쉐이더의 입력 텍스쳐로 가져옵니다. 이 때 입력받는 텍스쳐는 칩 내부에 있는 타일이 아니라 공용 메모리에 있는 렌더 타겟을 가져오기때문에 엄청난 대역폭을 잡아먹게 됩니다. (예 : 1080p) 그러므로 이미지 후처리는 신중하게 사용해야 합니다.

카메라 클리어(Clear)

예전의 데스크톱 그래픽카드에서는 한 프레임의 렌더링을 시작하기 전 일부러 화면을 클리어해주지 않고 렌더링을 시작하는 경우도 있었습니다. 하지만 현대의 데스크톱 그래픽카드에서는 반드시 클리어를 해주어야만 하드웨어의 고속 처리를 지원받을 수 있습니다. 이는 모바일 기기의 TBR에서도 마찬가지입니다. 클리어를 수행하여 칩 내부의 버퍼들을 비워줘야만 이후 렌더링 과정을 고속으로 처리할 수 있습니다. 따라서, 유니티의 카메라에서 Clear Flag를 Don’t clear로 두는 것은 데스크톱에서나 모바일에서나 웬만해서는 권장되지 않습니다. 

MSAA

데스크톱에서는 MSAA가 매우 큰 부담이 됩니다. 역시 마찬가지로 대역폭이 가장 큰 원인입니다. 예를 들어 1080p해상도의 화면을 MSAA 2X로 처리하려면 2160p만큼의 대역폭이 필요해집니다. DRAM으로부터 그만큼의 대역폭을 요구한 다는 것은 매우 큰 부담이 되는것입니다. 하지만 TBR에서는 이 역시 칩 내부의 타일에서 이루어집니다. 16x16 혹은 32x32정도에 불과한 타일로 MSAA처리해주는 것은 그리 부담이 되지 않습니다. 

유니티에서 MSAA를 사용하기위해서는 퀄리티 셋팅에서 Anti Aliasing을 2 혹은 4로 선택해주면 됩니다. 다만 개인적으로는, 매우 높은 DPI를 자랑하는 대부분의 모바일 기기에서 안티 앨리어싱이 굳이 필요할 지는 모르겠습니다 :)

프로파일링

유니티5부터 프레임 디버거(Frame Debugger)가 추가되어서 프레임 별 렌더링 과정을 디버깅해볼 수 있게 되었습니다. 이를 통해서 오브젝트의 렌더링 과정이나 배칭 현황을 손쉽게 확인 해 볼 수 있게 되었습니다.  

이미지 출처 : http://docs.unity3d.com/Manual/FrameDebugger.html

하지만 애석하게도 유니티의 프레임 디버거만으로는 드로우콜 별 GPU 퍼포먼스나 세부 상태를 확인하기는 힘듭니다. 다행히도, 칩셋 벤더마다 렌더링 과정을 세부적으로 프로파일링을 해볼 수 있는 툴을 제공해주고 있습니다. 아드레노 칩셋은 아드레노 프로파일러를 통해서, 말리 칩셋은 말리 프로파일러나 DS-5를 통해서, 아이폰은 XCODE를 통해서 프로파일링을 해볼 수 있습니다.

이미지 출처 : http://www.slideshare.net/ozlael/graphics-opt-ndc

다만 문제가 하나 있습니다. TBR 방식을 사용하는 칩셋은 콜 별 설능을 확인하는데 어려움이 없습니다. 하지만 TBDR 방식을 사용하는 칩셋은 콜 별 성능을 직관적으로 확인하는게 사실상 불가능하다는 것입니다. TBDR은 앞서 언급했다시피, 드로우콜 발생 시 픽셀 쉐이더를 즉시 처리하는 것이 아니라 파라미터 버퍼에 결과를 담아둡니다. 그 후 모든 드로우콜을 마치고 나면 그때서야 실제 렌더링을 수행하기 때문에 콜 별 성능을 실질적으로 확인해 볼 수가 없는 것입니다. 따라서 X-code에서 아이폰의 렌더링을 프로파일링 해보면 성능 관련 숫자가 0으로 나오게 됩니다. 0이 아닌 숫자가 나오는 경우도 있지만 이 역시 신뢰할 수 없는 숫자입니다. 대신 프레임 전체에 걸린 성능을 확인해보거나 콜 당시의 사용 텍스쳐 등 주변 정보로 유추해보는 수 밖에 없습니다. 이처럼 아이폰의 프로파일링은 좀 까다로운 편입니다.

이미지 출처 : http://www.slideshare.net/ozlael/graphics-opt-ndc

화면 변화율

TBR에서는 렌더링을 칩 내부의 타일에다 하는 과정은 대역폭을 먹지 않지만, DRAM 영역에 존재하는 프레임 버퍼에 타일을 출력하는 과정에서는 어느 정도는 대역폭이 필요할 수 밖에 없게됩니다. 이러한 대역폭을 조금이나마 절약하기 위해서 말리에서는 트랜잭션 엘리미네이션(Transaction Elimination)이라는 기술을 사용합니다. 타일 별로, 이전 프레임과 화면 결과가 달라지지 않은 타일의 영역은 프레임버퍼를 갱신하지 않고 이전 프레임의 결과를 재활용 하는 것입니다. 그렇게 하면 칩 내부 메모리에서 시스템 메모리로 복사하는 양이 줄어드는 효과를 갖게됩니다. 아래 예시 이미지의 파란 글자 타일이 바로 그 부분에 해당합니다. 

이미지 출처 : http://community.arm.com/

따라서, 고정 카메라를 사용한다면 스카이박스 등의 배경에는 최대한 변화를 피하는 것도 좋은 방법이 될 수도 있습니다. 현실적으로는 3D 게임에는 이러한 조건에 해당하는 경우가 많지는 않을 것입니다. 하지만 2D 게임에는 적합하는 부분이 많은 것입니다.

마치며

TBR에 관한 내용이랑 TBDR에 관한 내용을 같이 언급하긴 하였습니다. 하지만 대부분은 아이폰이나 안드로이드폰만 타겟으로 설정하고 개발할 것이고, 플랫폼마다 데이터를 별도로 제작하지는 않을 것이라 예상합니다. 따라서 현실적으로는 TBR, TBDR 모두 고려대상으로 삼고 이러한 사항들을 인지하면서 개발하여야 할 것이라 생각합니다.

감사합니다.