[패스트캠퍼스 수강 후기] 올인원 패키지 : 유니티 포트폴리오 완성 100% 환급 챌린지 2회차 미션

[패스트캠퍼스 수강 후기] 올인원 패키지 : 유니티 포트폴리오 완성 100% 환급 챌린지 2회차 미션.

실무 개발하면서 알아두면 좋을 것들입니다.

 

+ 풀링
+ 상태머신
+ 사운드시스템
+ 유니티 에셋번들
+ 유니티 셰이더
+ 유니티 최적화
+ 프로파일링
+ 라이브팀에서의 업무와 신규개발팀의 업무 차이.

풀링 : 만들어놓은 것을 재사용하는 방법입니다.

리사용 재사용 리소스 공간.
화면에는 엄청 움직이는 것 같지만 이팩트 개수를 줄이면서 조절하여 맞춘다.
실제 게임하는 사람은 기술을 써서 다량의 몬스터가 동시에 죽을 때 100개인지 60개인지 표시되는 것이 중요하지 않습니다.
풀링 방식으로 리소스를 재활용합니다.

 

 

상태머신

플레이어의 상태를 프로그램에서 스크립트화하여 그때그때 작업하며 기획에 맞게 수정하다보면 유지보수 문제도 심각해지고 작업도 어려워지고 복잡해지고 버그도 많아진다.
그래서 상태머신을 설정합니다.
특정 이벤트에 해당하는 상태로 변경이 발생하고 해당 상태에서 또다른 이벤트에 의해 상태를 변경하는 것입니다.
단점은 아니지만 좀 복잡해질 수 있는 것은 동시의 이벤트에 대해 처리를 하려면 Attack 내의 Sub-State-Machine을 작성하고 또 하위 Sub-State 등을 추가해 나아갈 수 있는데 좀 복잡해질 수 있다.

지만 단점은 아닐 수 있는 부분이 기존 방식대로라면 if-else의 엄청 복잡한 분기 구조를 사용했어야 할텐데 오히려 어려웠을 것이기 때문입니다.

+ State은 확장성과 유지 보수가 중요합니다.
+ Transition은 절대 중복되면 안된다. Idle->Attack 또는 Idle->Jump 등 명확한 상태로 이동되어야 합니다.
+ 상태 이름은 명확해야 한다. Jump01, Jump02이런 형태면 알 수 없다.
+ Condition은 단순화가 중요.
+ Update 동작이 복잡한 State는 분리를 고민해봐야 합니다.  Sub-State를 만드는 것이지요.

 

사운드 시스템

타격감. 게임의 완성도에 영향이 컸지만 요즈음은 인디게임이나 모바일 게임에서는 중요성이 많이 낮아진 상태입니다.
왜냐면 일단 재생이 되는 것이 확인만 되면 추후 클립만 업데이트 하면 되기 때문입니다.
어차피 인기가 있어서 업데이트가 자주 발생하게 된다면 그때 피드백 받아 적용해도 될 것이기 때문입니다.

사운드 유니티툴을 제작하며 3D 입체 사운드를 처리하는 방식도 추후 개발해볼 예정입니다.
특정 위치에 도착시 Box Collision 지역을 만들어서 도착하면 자동으로 사운드를 변경하는 방법.
매번 프로그램에서 여기서 어떤 오디오 재생, 어디서는 어떤 오디오 재생하는 형태가 아니라 오디오 관리툴을 만들어서 UI 상태에서 오디오 클립을 배치하여 코드로 작업하지 않습니다.
캐릭터의 발자국 소리도 모든 상태의 소리를 신발에 넣어두는 것이 아니라 특정 위치 공간에서 오디오 클립을 모두 가지고 있고, 플레이어가 배경에 들어오는 순간 공간에 지정된 플레이어의 신발에 특정 오디오 클립을 연결하여 재생하는 형태로 만듭니다.
물이 있는 공간에 들어갔을 때 플레이어가 걸으면 철퍽철퍽하는 소리가 나는 그런 것들인 것이지요.

 

어셋번들

압축된 리소스 모음 파일이라고 생각하면 됩니다.

복잡하고 알아야 하는 내용들이 많습니다. 사용하기도 쉽지 않습니다. 그래서 어드레서블 에셋이 개발됩니다.

 

어드레서블(Addressables)은 복잡한 라이브 콘텐츠를 전달해야 하는 대규모 제작팀의 요구사항을 보다 효과적으로 지원하기 위한 Unity 에디터 및 런타임 에셋 관리 시스템입니다.
본인들도 어렵다고 인정했다고 하십니다.. ㅎㅎ 맞습니다. 이런 경우 참 많거든요.. 100% 공감이 갑니다.

에셋의 위치 지정, 빌드 및 로드와 관련하여 일반적으로 발생하는 몇 가지 문제를 해결하기 위한 프레임워크를 구축하기 위해 어드레서블이 탄생하게 되었습니다.

Meta 파일: 어셋 관련하여 Meta 파일이 엄청 중요합니다. GUID.
처음 어셋을 만드는 PC에서의 Prefab에 대한 GUID가 생성되며 들어가게 되는데 이것이 Meta 파일로 관리되게 됩니다. 그런데 Meta 파일이 공유되지 않으면 다른 PC않으면 또 독립적은 GUID가 발급되기 때문에 문제가 발생하게 됩니다.

 

유니티 셰이더

셰이더는 화면에 출력하는 픽셀의 색을 정해주는 함수라는 뜻을 가지고 있다고 합니다.
셰이더 전에 알아야 하는 내용은 파이프라인과 빛의 원리.

렌더링 파이프 라인의 4단계.
1) 3점으로 이루어진 Vertex로 구성진 오브젝트 받아오기.
2) 정점셰이더: 버텍스들에게 월드변환행렬(월드좌표계)를 곱해주므로써, 원근감 등을 표현.
3) 래스터라이져: 오브젝트를 출력해주는 과정. 3D 오브젝트가 모니터에 보이도록 픽셀이 되는데 이 과정을 래스터화라고 하며 3D 이미지가 2D 이미지가 되는 것입니다.
4) 픽셀셰이더와 프레그먼트 셰이더: 픽셀셰이더가 동작하며 조명과 텍스쳐 등 특수효과를 연산.

유니티 최적화

프로그램 최적화: 100번 돌릴걸 10번 돌려서 해결..
리소스 최적화. 100픽셀 쓸걸 10픽셀로 해결..

왜 중요하냐면

+ 유저에게 쾌적환 플레이 제공이 가능하기 때문입니다.
+ 게임 시간 절약 및 데이터 절약도 가능해집니다.
+ 우리나라 환경에서는 문제가 덜 하긴 하지만 지금도 외국에서는 데이터를 용량별로 유료로 사용하는 곳도 많습니다.
+ 플랫폼 이슈: 용량이 적거나 저사양의 모바일에서도 게임이 가능해지기 때문에 더 많은 유저가 즐길 수 있겠지요.

+ 향후 업데이트를 위해: 최적화된 패치는 용량, 시간 등 많은 이점이 있습니다.

프로파일링

현재 게임이 돌면서 하드웨어 상태를 지켜본다. 전체적인 리소스 사용 흐름량을 확인할 수 있다.
게임을 진행하는 중에 어떤 지점에서 문제가 발생하는지를 확인하기가 쉽다. 어떤 스크립트에서 문제가 발생하는지도 바로 확인이 가능하다.
특정 시점에서 CPU나 메모리 사용량이 늘어나는 구간을 그래프로 확인하여 어떤 스크립트에서 어떤 문제가 있었는지 또는 최적화를 해야하는지 등을 확인할 수 있다.

라이브팀 vs 신규개발팀

어떤 형태의 게임 개발 및 업무가 나에게 맞는 것이 중요할 것 같네요.
나에겐... 신규개발팀(?)처럼 특정 기간내의 특정 프로토타입 게임 개발을 많이 해보는 것이 많은 것들을 해볼 수 있어서 좋을 것 같네요.

추가적으로 유용한 내용들.
+ 스택오버플로우 사이트. ㅎㅎ 너무 유명하죠.. 개발일을 하면 구글 검색하며 진짜 자주 접근하게 되지요.
+ 예시 코드의 위험성. 샘플코드를 포트폴리오로 사용하지 마라.
+ 팀마다 코드 규약: 변수 규약 Camel Case 등..
+ 코드 리뷰의 중요성

+ 형상관리. GitHub, SVN

 

 

여기까지 해보았는데요.. 이건 유니티로 게임만드는 것 자체에 대한 것보다 전반적인 소프트웨어 개발자라면 알아야 하는 내용이라고 하는 것이 맞겠습니다. 정말 유용한 내용이었습니다.

 

 

패스트캠퍼스 - 올인원 패키지 : 유니티 포트폴리오 완성 bit.ly/2R561g0

유니티 게임 포트폴리오 완성 올인원 패키지 Online. | 패스트캠퍼스