게임뿐만 아니라 모든 프로그램은 외부 환경의 변화에 맞춰서 업데이트를 진행합니다. 게임 엔진도 예외는 아니죠. 일반 유저에게는 그 업데이트가 게임 후속작 혹은 차기작이 나오는 것만큼 드라마틱하지 않아서 잘 체감되지는 않지만, 개발자들에겐 그보다 더 큰 변화일 수 있습니다. 때로는 옛날에 쓰던 것들이 호환이 안 되서 개선해야 할 때가 있으니까요.
물론 게임에서 2.0이니 차기 시즌 업데이트하면서 예전에 쓰던 템들이 못 쓰게 될 때가 있긴 합니다. 그나마 게임은 일부 다른 걸로 교환할 수 있는 재화를 주거나, 혹은 업데이트를 자동으로 받은 이후에는 변화에 익숙해지는 것빼고는 번거로운 건 없는 편이죠. 그렇지만 엔진으로 빌드해둔 것은 얄짤없습니다. 팁이 있긴 하지만, 그 팁을 보면서 일일이 자기가 알아서 다 바꿔야 하니까요.
그런 만큼 로드맵이 발표되면 항상 신경이 쓰일 수밖에 없습니다. 유니티 2019.3의 기능에 적응하느라 씨름하고 있는 상황에서 다음 버전인 2020.1이 나오고 있으니까요. 물론 아직은 프리뷰 베타 버전이고, 엔진을 켤 때 다운로드를 스킵해버리면 되긴 합니다. 하지만 유니티 2019.3에 추가된 기능으로 엄청난 혜택을 본 터라 2020.1 그리고 2020 최종 버전에서는 대체 어떻게 바뀔지 궁금할 수밖에 없죠.
게임만들기 기사 모아보기
ㄴ[게임만들기 ①] 1인 게임 개발에 한 번 도전해보았습니다 - 예고 및 기획 단계편
ㄴ[게임만들기 ②] 1인 게임 개발에 한 번 도전해보았습니다 - 캐릭터 디자인편
ㄴ[게임만들기 ③] 1인 게임 개발에 한 번 도전해보았습니다 - 중간 점검 및 기획 수정편
ㄴ[게임만들기 ④] 1인 게임 개발에 한 번 도전해보았습니다 - 배경 및 스테이지 설계편
ㄴ[게임만들기 ⑤] 1인 게임 개발에 한 번 도전해보았습니다 - 적 캐릭터 제작편
ㄴ[게임만들기 ⑥] 1인 게임 개발에 한 번 도전해보았습니다 - 적 만들기 심화편
ㄴ[게임만들기] 1인 게임 개발 도전, 지금도 하고 있나요?
■ 유니티 2020 로드맵에서 필요한 것 추려내기
로드맵은 앞으로의 목표를 제시하고, 이를 어떻게 달성할 것인지 가이드라인을 이야기하는 단계입니다. 즉 어느 한 부분이 아니라 전반적인 분야를 통틀어서 언급하게 되죠. 그러다보니 로드맵 강연을 듣다보면 "나한테 필요한 게 뭐지?"라는 생각이 들 수밖에 없습니다.
유니티 2020 로드맵을 간단하게 정리하면 다음과 같습니다.
■ 신뢰도와 퍼포먼스 향상을 위한 개선
-프리뷰 베타가 3번에서 2번으로 횟수를 줄이고, 각 기간을 늘려서 버전에서 추가되는 기능을 좀 더 안정화시키는 것에 주력.
-DOTS와 새로운 환경 시스템을 기반으로 한 오픈월드 슈터 샘플을 출시할 예정. 그 외에도 네트워크, 워크플로우, 애니메이션 등 모든 분야에서 발전된 모습을 보여줄 것.
-통합된 에디터 패키지 매니지먼트로 프로젝트 관리 및 작업을 한층 더 편리해질 것.
-마이애셋, 필터링 옵션을 개선해서 애셋 관리 및 정리가 쉬워짐. Git 활용도도 높아짐.
-프로파일링과 퍼포먼스 시각화로 최적화가 쉬워질 것. 프로필 분석기와 메모리 프로파일러가 프리뷰로 제공됨.
■ 창조적인 워크플로우
-기존 2D 관련 기능을 개선하는 한편, 2D 렌더러를 추가해 광원과 그림자, 셰이더그래프를 더욱 발전된 형태로 사용할 수 있을 것.
-버스트컴파일러를 1.2에서 1.3으로 개선하면서 네이티브 디버깅, 앨리어싱 컨트롤 등이 추가되며 2020.1에서는 비주얼 스튜디오 인티그레이션 패키지도 추가. 그와 더불어 IL2CPP 실행 퍼포먼스가 증가한다.
-프리펩 모드 및 코드 옵티마이제이션, 씬 템플릿 등 에디터 추가.
-인스펙터 속성 및 하이어라키창의의 애셋의 복사-붙여넣기 기능 개선 및 인스펙터 프리뷰 개선.
-애니메이션 리깅 개선 및 DOTS 도입으로 애니메이션 시스템, 타임라인, 그래프 등등 일괄적으로 개선 예정.
-VFX 그래프 및 셰이더 개선으로 셰이더 로딩 타임을 50%까지 감소, 안정화와 버그픽스.
-유니티 게임 시뮬레이션으로 동시다발적인 밸런스 테스트가 가능하도록 함.
-로우레벨 렌더링, 믹싱 오디오 엔진인 DSP 그래프 및 리코더 추가. 추후 DOTS 도입한 새로운 오디오, 미디어 기능 추가 예정.
-유니버설 렌더링 파이프라인의 버그픽스 및 다중 카메라 지원.
■ 확장 가능한 퀄리티
-HDRP 개선 및 레이트레이싱 프리뷰 제공.
-하이브리드 렌더러를 도입, 전체 프레임 타임에서 기존 대비 5.3배 빠른 퍼포먼스를 보일 것.
-하복 엔진과 협업한 유니티피직스 시험 도입. 지형 콜라이더와 싱글쓰레드 기반의 즉각 반응 시뮬레이션, 하복 피직스 지원 패키지가 프리뷰로 제공됨.
■ 유저에게 도달하기 위한 과정 개선
-게임의 매칭 시간을 줄여주는 기능인 매치메이킹 기능이 CBT로 제공, PC 및 맥, 리눅스 간 크로스 컴파일러 통해서 서버 런타임 처리 시간 축소.
-각 모바일 기기에 대응하는 시뮬레이터 기능 제공.
-XR 개발 시 입력 및 상호작용 구축이 쉽게끔 툴킷 제공, 오큘러스 퀘스트에 불칸이 지원하도록 변경
물론 로드맵인 만큼 앞으로 변경될 부분과 지금 적용된 것이 혼재되어있고, 내용이 원체 방대한 만큼 하나하나 체크하기는 꽤 힘든 작업입니다. 거의 개요만 조금 훑어본 정도인데도 상당한 분량이 나오니까요. 엔진의 전반적인 기능을 어떻게 개선하겠다는 것이 로드맵인 만큼, 이는 어쩔 수 없긴 합니다. 팀으로 움직인다면 엔진을 주로 만지게 되는 인원들이 각자가 주로 하는 분야를 나눠서 보면 되겠지만, 1인 개발자는 그렇지 않은 터라 버겁게 느껴질 수밖에 없죠.
결국 프로젝트에서 바로 도움이 되거나 혹은 영향이 미치는 부분만 따서 우선적으로 체크하게 됩니다. 제 경우는 2D 관련 기능, 특히 2D 렌더러가 어떤 것인지 확인해볼 필요가 있습니다. 오디오 관련 부분이나 VFX, 셰이더 관련 기능도 나중에 후처리 작업에 들어가면 기존에 배웠던 것을 써먹을 수 있는지 없는지 체크해봐야겠지만, 그보다는 기본적인 과정이 뒷받침이 되어야 하니까요.
그리고 2020.1베타가 풀린 만큼, 어떤 기능이 제공되는지 공식 홈페이지에도 공개되어있습니다. 이를 확인해보는 것도 방법이죠. 물론 단순하게 목록만 나열해봐도 상당한 양이긴 합니다.
- 2D 역운동학(IK)/ 기기 시뮬레이터 / 코드 커버리지 / WebGL 게임 공유 / 프로그리드 / 터레인 툴 / UI 빌더 / 유니티 리코더 / 하복 피직스 / 유니티 피직스 / 입력 시스템 / 벡터 그래픽스 / 애니메이션 리깅 / 프로필 분석기
이 역시도 다 체크하면 좋긴 하겠지만, 결국 1인 개발이면 자기가 최우선적으로 써야 할 기능을 우선적으로 봐야 할 겁니다. 마치 시험에 출제되는 부분을 우선 공부하는 것처럼 말이죠. 혹은 조금 더 지나면 유니티 공식 블로그나 유튜브 채널, 혹은 개발자들이 이를 해설해주고는 하니 이를 참고해도 될 거 같긴 합니다. 아무래도 언어의 압박도 있고, 더군다나 우리말로 써있어도 어려운 내용이 영어로 적혀있으니까요.
다만 새로 추가된 기능의 혜택을 많이 본 입장에서 엔진의 새로운 기능은 빨리 익숙해지는 게 낫다는 느낌이 들더군요. 물론 기존에 지원하던 기능을 개선한 것도 있긴 하지만, 어쨌든 그만큼 다양한 변화가 일어났으니 앞으로를 위해서는 체크해야겠죠. 그래서 2020.1베타를 다운로드 받은 뒤, 제 작품에서 직접 활용할 수 있는 게 어떤 것인지 또 기존 버전과 충돌하지 않는지 등을 체크하면서 작업해나가고자 합니다.
■ 기왕 잘못 만들어진 것, 엔진의 새 기능을 테스트하며 다듬어가기
가장 눈여겨봤던 기능은 2D 역운동학, 코드 커버리지, 입력 시스템, 애니메이션 리깅 이 네 가지입니다. 플랫포머를 만들 때 제일 중요한 애니메이션 작업과 코드 체크, 입력 및 조작과 관련된 분야기 때문이죠.
그 중 제일 시급한 건 코드와 관련된 기능이었습니다. 코드가 대체 어떤 문제가 있는지 파악조차 못하고 "안 되나보다"라고 넘어가는 일이 많았거든요. 콘솔창에서 오류가 뜨긴 하지만 그것만으로는 뭐가 문제인지 확실하게 알지 못할 때가 많았죠. 그래서 유나이트 코펜하겐에서 DOTS, 비주얼 스크립팅에 대해서 언급할 때 귀를 쫑긋했던 기억이 납니다.
비주얼 스크립팅이란 라인, 즉 문장으로 되어있는 코드를 시각화해서 코드를 모르는 사람도 알아보기 쉽게끔 하거나 혹은 라이브러리화해서 코드를 짜지 않고도 해당 기능을 활용할 수 있게끔 한 것들을 일컫습니다. 각각 장단점이 있기 때문에 상황에 따라서 맞춰서 쓰면 됩니다. 다만 지금은 미리 짜둔 코드가 있으니 그걸 점검하는 차원에서 이를 활용해보고자 했죠.
기존에 이를 체크하는 가장 쉬운 수단은 디버그 로그나 브레이크를 일일이 거는 식입니다. 그런데 이런 방법으로는 만약에 어느 라인이 아예 작동하지 않아도 별 문제가 없는 상황을 초보가 한 눈에 잡아내기 어렵죠. 프로그래머들은 문제가 없으면 "왜 문제가 없지? 버그가 왜 없지?"라는 의문을 꼬리에 꼬리를 무는 것이 익숙해져있지만, 비프로그래머들은 그런 사고에 익숙해져있지 않기 때문에 눈에 들어오질 않거든요. 사실 디버그 로그를 볼 줄 아는 것만으로도 코딩이 아예 생초보가 아니라는 뜻이기도 하고요.
이번에 추가된 코드 커버리지는 테스트를 실행했을 때, 테스트 통과 여부와 코드의 어느 라인이 실행되는지 정확하게 확인할 수 있게끔 했습니다. 패키지 매니저에서 코드 커버리지를 다운로드 받은 뒤에 코드 커버리지를 활성화시킨 뒤 유니티를 재실행하면 사용할 수 있죠.
사용법은 간단합니다. 레코딩을 시작한 뒤에 플레이를 해보고, 플레이가 끝난 뒤 레코딩을 종료하면 스크립트-리포트 폴더의 인덱스.HTML 형태로 저장됩니다. 그 파일에는 플레이했을 때 어떤 스크립트가 어떻게 작동하고, 어느 라인이 얼마나 호출되고 라인 효율이 얼마나 되는지까지 측정해서 그래프 및 표로 도출됩니다. 다만 코드 커버리지를 활성화하게 되면 엔진이 상당히 무거워지기 때문에 꼭 필요한 때가 아니라면 비활성화시키는 걸 권합니다.
(클릭하면 확대됩니다.)
어쨌거나 그 결과, 대부분의 라인이 제대로 안 쓰이고 있다는 충격적인(?) 결과를 알 수 있었습니다. 심지어 무브스피드, 맥스스피드, 점프포스 이런 지표들이 거의 의미가 없다는 표시가 나오니까 당황스러울 수밖에 없었습니다. 간단히 말하자면 캐릭터가 움직이기 위해서 가해지는 힘들이 전혀 의미가 없다는 뜻이기 때문이죠.
(클릭하면 확대됩니다.)
그거 말고도 따질 게 한두 가지가 아닌데...알면 알수록 너무 무섭습니다. 몰라 이거 그냥 덮을래
(클릭하면 확대됩니다.)
이 부분은 뭔가 착오가 있는 것 같아서 좀 더 오래 플레이하면서 이를 녹화한 뒤에 체크했는데, 다행히 이 지표들은 정상적으로 움직였습니다. 그런데 Awake()조차도 호출이 안 됐는데 왜 다른 것들이 호출이 됐을까요? 생각을 하면 할수록 오싹하고 뭔가 괴기한 느낌이 들긴 합니다만, 그건 엔진 버전이 바뀌면서 일어난 해프닝 정도로 넘어가고자 합니다.
요는 점프에 할당된 코드가 전혀 작동 안하고 있다는 뜻이죠.
(클릭하면 확대됩니다.)
아무튼 중요한 건, 두 경우 모두 다 점프 애니메이션에 할당할 파라미터와 점프 애니메이터가 전혀 작동하지 않고 있다는 점이죠. 그 이유는 콘솔창에 나온 오류를 보면 대강 알 수는 있긴 하지만, 실제로 이렇게 지적해주니까 체감이 오더군요. 다만 예전부터 계속 나오는 파라미터 오류도 잡아주지 않을까 싶었는데, 그 부분에 대해선 별 이야기가 없어서 조금 당혹스럽긴 했습니다.
사실 엔진이 바뀔 때 가장 영향을 크게 받는 것이 스크립트이긴 합니다. 예전에 쓰던 코드가 종종 다른 코드로 대체되거나, 구조에 맞춰서 바꿔줄 필요가 있거든요. 어쨌거나 이 스크립트가 지금 와서 제대로 쓰기엔 좀 애로사항이 많다는 걸 확인사살했으니 미련없이 다른 대안을 찾아볼 수 있다는 것만으로도 소득이라고 하겠습니다
게임 개발하면서 느끼는 건, 한 번 잘못 만들면 아예 처음부터 갈아엎는 게 속이 편하다는 점입니다. 어긋난 걸 다시 되돌리려면 처음부터 봐야 하기 때문이죠. 뿐만 아니라 어느 하나를 고치면 그 하나로만 끝나는 게 아니라 어디서 무언가가 또 문제가 생길지 예측하기 어렵습니다. 다 따로따로 독립적인 게 아니라, 서로 연결이 되어있다보니 그 변화가 연쇄적으로 영향을 미치니까요.
PSD 임포터로 추출한 에셋도 그와 똑같은 의미에서 문제에 봉착했습니다. 사실 피벗이 왜 캐릭터의 중심부가 아닌 칼에 가있는지부터 짐작을 했어야 하는데 말이죠. 리지드바디를 줄 때 칼까지 주는 건 좋은데, 무게중심이 칼 쪽으로 가있어서 캐릭터가 쏠리게 됩니다.
그걸 어떻게 해결해보겠다고 빈 오브젝트를 만들고 캐릭터 애셋을 자식으로 뒀는데, 그 이후에 애니메이터도 뭔가 엉망이 되어버린 느낌입니다. 적어도 스탠딩-걷기 애니메이션은 잘 연결됐는데, 그것마저도 제대로 되고 있질 않기 때문이죠. 결국 새로 애니메이션을 만들 때, IK 기능을 활용해서 좀 더 다양하게 만들어보자는 플랜으로 다시 새로 만들게 됐습니다.
꼭 엔진이 바뀌어서 기존에 쓰던 걸 못쓰게 됐다는 의미는 아니지만, 적어도 엔진이 바뀌게 되면 그간 알고 있던 것과 때로는 충돌을 일으키곤 합니다. 아마도 그 때문에 엔진 개발사들은 엔진 홍보를 할 겸, 개발자들이 빨리 새로운 지식을 받아들이게끔 다양한 행사를 여는 것이겠죠.
지금은 코로나 19 때문에 위축되긴 했지만 유튜브 채널 등을 통해서 계속 업로드가 되고 있고, 온라인 강좌도 무료로 공개되고 있는 만큼 이를 활용해서 공부해둘 필요는 있을 것 같습니다. 그래야 이 사태가 끝난 다음, 대대적인 발표에 뒤쳐지지 않고 따라잡으면서 필요한 것들을 제깍제깍 활용할 수 있을 테니까요.
Ruudi@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
