관리 메뉴

이야기 공작소

[기사번역] 중간 규모 개발 그룹이 겪을 수 있는 유니티의 의외의 함정이란? 본문

게임/게임 정보, 기사

[기사번역] 중간 규모 개발 그룹이 겪을 수 있는 유니티의 의외의 함정이란?

꿈토끼양 2012.04.23 00:27
원문: http://www.gamebusiness.jp/article.php?id=5914 by 小野憲史(Kenji Ono), 2012/04/18

중간 규모 개발 그룹이 겪을 수 있는 유니티의 의외의 함정이란?
'삼국지 컨퀘스트' 포스트 모템

전 SEGA 프로그래머 이토 슈(伊藤周)

Copyright© IID Inc. 

폭발적인 규모로 세력을 확장하고 있는 덴마크제 게임 엔진 '유니티'. 무료 버전으로 만든 게임을 상업적으로 판매할 수도 있어 일본을 비롯한 아시아권에서 급격히 점유율을 높여 가고 있습니다. 그중에서도 일본에서 특히 관심이 집중되는 분야는 스마트폰 소셜 게임 개발. 하지만 유니티는 원래 인디 개발자용으로 디자인되었기 때문에 중간 규모(10인) 이상의 프로젝트에서는 주의해야 할 점도 있습니다.

한편 북미와 유럽 시장에서는 XBLA나 Steam과 같은 디지털 다운로드 플랫폼이 성장세를 보이고 있고, 인디 게임에서도 대작을 제작하는 추세가 이어져 왔습니다. 이제 이곳에서도 패키지 게임에 필적하는 완성도를 갖춘 게임들이 쏟아지고 있습니다.

일본에서는 대기업이 스마트폰 소셜 게임 개발을 위해, 북미와 유럽에서는 콘솔이나 PC 베이스의 인디 게임 개발을 위해 유니티를 활용해서 중간 규모의 프로젝트를 꾸리는 경우가 늘고 있는 셈입니다. 그러나 거기에는 특유의 함정이 도사리고 있다고 하는데...

세가의 '삼국지 컨퀘스트' 개발에서 메인 프로그래머를 담당하다가 현재는 유니티 테크놀로지스 재팬의 에반젤리스트로 활약 중인 이토 슈(伊藤周) 씨가 세가에서의 개발 사례를 바탕으로 도움이 되는 말씀을 해 주셨습니다. 제목은 '중간 규모 Unity 게임 개발의 포스트 모템: 삼국지 컨퀘스트 SEGA의 사례'입니다.

■EZ GUI는 공동 작업을 고려하지 않았나?

'삼국지 컨퀘스트'는 세가가 운영하는 iOS용 소셜 게임입니다. 플레이어는 삼국 시대의 영웅이 되어 내정과 전투를 반복하며 난세를 통일하는 것이 목표입니다. 게임은 마을을 발전시키고 다른 나라와 전쟁을 벌이는 시뮬레이션 파트와, 일기당천으로 액션을 펼치며 무장 카드를 획득하는 액션 파트를 반복하며 진행합니다.

개발 프로젝트는 2011년 6월부터 2012년 1월까지 총 7개월간 진행되었고, 지금도 운영과 업데이트를 계속하고 있습니다. 액션 파트는 60 FPS의 가변 프레임 레이트로, iPhone 4S에서는 평균 35-40 FPS 정도입니다. 라이트맵과 같은 조명은 쓰지 않고 모두 텍스처를 입혀서 음영을 표현했습니다. 캐릭터의 그림자는 검은 원 모양의 폴리곤을 발밑에 깔아서 표현했는데, 이것 역시 필드에 울퉁불퉁한 부분을 만들지 않았기 때문에 가능했습니다.

반면에 캐릭터 애니메이션에는 심혈을 기울여 총 230종류를 넣었습니다. 액션 파트의 컨셉은 '가급적 필드 상에 많은 적을 표시해서 일기당천의 액션감을 연출할 것'이었기 때문입니다. 플레이어 캐릭터에는 폴리곤이 약 1000개인데에 비해 조무래기 캐릭터들에는 약 300~400개만 사용한 것도, 테스트를 반복하면서 가장 적합한 개수를 찾아 나간 결과라고 합니다.

이어서 이토 씨는 유니티의 장점으로 '화면 출력 엔진이 존재한다', '테스트 환경이 갖추어져 있다', '디자이너와 기획자가 쉽게 사용할 수 있다'의 3가지를 들었습니다. 특히 첫 번째와 두 번째는 강력한 장점으로, 기획에 맞게 돌아가게끔 만들어서 실제로 플레이해 보고, 재미있는지를 검증한 다음 취사선택을 할 수 있었다고 합니다(처음에는 액션 파트가 지금과는 완전히 다른 내용이었다고). 반대로 어려웠던 점으로는 '당시에는 정보가 적었다(지금은 해결)', 'GUI 구현', '엄격한 규칙 설정'을 들었습니다. 두 번째와 세 번째가 바로 중간 규모 개발, 즉 팀으로 개발할 때의 장벽이었던 셈입니다.

앞에서 밝혔듯이 이 작품은 전략 시뮬레이션과 액션 게임이 융합된 타입으로, 내정과 외정 등의 화면과 GUI(메뉴)가 대량으로 존재합니다. 그런데 유니티에서는 처음부터 이런 게임에 대해서는 생각하지 않았는지, 당시에는 강력한 GUI 관리 라이브러리가 존재하지 않았습니다. 그러던 와중에 작년 여름 애셋 스토어에 등장한 것이 'EZ GUI'로, 지금은 유니티에서 본격적인 GUI를 제작하기 위한 표준 라이브러리로 사용되고 있습니다.

하지만 이토 씨는 자신의 경험으로 미루어볼 때 "EZ GUI는 GUI 담당자가 여러 명 있는 팀, 즉 중간 규모 개발을 생각하지 않고 만든 것 같다"고 말했습니다. 유니티에서는 3D 오브젝트의 정보(좌표 데이터, 본 데이터, 텍스처, 스크립트 등)를 '프리팹(prefab)'이라는 개념으로 묶어서 관리하는데, EZ GUI로 공동 작업을 진행하면 이들의 관계가 깨지기 쉽습니다.

EZ GUI를 여러 명이 사용할 때의 전형적인 문제

Copyright© IID Inc. 

이토 씨는 해결 방법으로 ▽기본적으로 프리팹을 신(scene) 간에 공유하지 말 것 ▽신 머티리얼(scene material)을 공유할 것 ▽신 단위로 빌드 아틀라스(build atlas)할 것 ▽프리팹을 신에 포함시키지 말 것 등의 대책을 들었습니다. 이 트윗(http://togetter.com/li/212609)을 보면 이토 씨가 주변의 조언을 통해 개발 중에 직면했던 문제를 해결해 나가는 과정이 생생하게 정리되어 있습니다.

■진짜 수확은 두 번째부터

여기에서 이야기는 프로그래머가 아닌 사람들이 유니티를 어떻게 활용했는지로 옮겨 갔습니다. 아티스트의 경우 "텍스처 변경이나 GUI 위치 수정 등, 가능한 것부터 차근차근 익숙해지게 했다. 최종적으로는 스크립트 이외의 부분을 모두 맡겼던 것 같다"고 합니다. 한편, 기획자의 경우에는 파라미터를 Excel로 관리하게 했다고 하는데, 이는 이 작품이 소셜 게임인데다 데이터베이스 연동형 게임이라는 것이 영향을 미쳤습니다.

그 밖에 도움이 되었던 것은 'PlayMaker'입니다. 마찬가지로 애셋 스토어에서 판매되는 추가 라이브러리로, 스크립트를 GUI 기반으로 짤 수 있는 도구입니다. 이를 튜토리얼과 GUI 제어에 사용했더니 플레이어가 정해진 순서대로 조작하고 있는지를 간단하게 판정할 수 있었지만, 적 캐릭터의 AI에 사용해 보았더니 너무 무거워서 사용할 수 없었다고 합니다.

이토 씨는 아무리 유니티라고 해도 에디터나 툴 개선은 생산성 향상을 위한 필수 요소라고 합니다. 구체적으로는 신(scene) 분할, 머티리얼(material) 검색, 프리팹(prefab) 분할 등입니다. "유니티가 대처해 주기를 바라기보다는 알아서 개조를 하는 편이 빠릅니다. 가급적 전임자가 있으면 좋구요.(이토 씨)" 특히 아티스트는 문제의 본질을 파악하지 못하고 계속해서 단순한 작업을 반복하는 경향이 있기 때문에 아티스트가 같은 타이밍에 몇 번이나 마우스 클릭을 반복하고 있다면 요주의. 프로그래머가 신속히 알아채고 대처하는 것이 중요하다고 합니다.

PlayMaker는 GUI 기반의 스크립트 에디터

Copyright© IID Inc.

이어서 주제는 충돌(conflict) 문제로 넘어갔습니다. 원래 둘 이상의 개발자가 하나의 신 데이터를 건드리면 반드시 충돌과 마찰이 발생합니다. 해답은 바로 '분할해서 통치하라'. 신 분할, 담당자 분할, 프리팹 분할 등 큰 문제를 미리 구조별로 분해해 놓습니다. 그런 다음 담당자를 확실히 정해 놓고, 누군가가 데이터를 만질 때는 팀 내에 데이터를 건드리겠다는 선언을 하도록 규칙을 정해 두었다고 합니다.

이런 결정은 중간 규모의 팀이기 때문에 가능한 방법일 것입니다. 혼자서 게임을 만든다면 이런 귀찮은 일을 하지 않아도 될 것이고, 100명 이상의 팀에서는 더욱 확실한 진척 관리 시스템이 있어야 할 것입니다. 이번 작품에서도 프로그래머가 액션 시스템을 수정하고, 아티스트가 배경을 수정한 다음 나중에 둘을 붙이는 '전근대적'인 방법을 많이 사용했습니다. 물론 이것은 중간 규모의 팀이기 때문에 가능한 방법. 생각해 보면 일본에서는 이 정도의 규모로 아날로그 스타일의 개발을 하는 것이 오히려 맞을지도 모릅니다.

또한 스마트폰 등 모바일 단말기 특유의 문제로 만성적인 메모리 부족을 들었습니다. 특히 iPod touch가 메모리 부족에 시달리기 쉬우며, 정기적인 체크로 확인하거나 가비지 컬렉션(불필요한 메모리 영역을 자동으로 해제하는 기능) 활용을 추천했습니다.

그 밖에도 프로그래머의 빌드나 테스트를 자동화하기 위한 툴 'Jenkins' 사용을 강력하게 추천했습니다. Jenkins를 사용하기 전에는 프로그래머가 수작업으로 빌드를 하면서 사소한 곳에서 실수를 하는 경우가 잦았는데, 툴을 사용하면서 이러한 문제점이 해소되고 CI(Continuous Integration, 지속적 통합)가 가능해졌다고 합니다. 버튼을 누르는 것만으로 빌드 서버 상에서 iPhone으로 인스톨이 가능한 환경이 갖추어졌고, 이를 통해 한 단계 발전하는 계기가 되었다고 합니다.

- 유니티라고 해서 게임을 간단히 만들어 낼 수 있는 것은 아니다.

- 중간 규모 팀에서 발생하는 작업상의 문제점은 툴을 사용해서 해결
- Jenkins 사용을 강력 추천
Copyright© IID Inc.

"아무리 유니티라고 해도 도입부가 편할 뿐이지 게임을 간단히 만들어 낼 수 있는 것은 아닙니다.(이토 씨)" 물론 첫 작품을 만든 다음 노하우가 쌓였기 때문에 두 번째 이후로는 개발 부담이 줄어들 것으로 이토 씨는 예측합니다. 또한 중간 규모 팀에서 발생할 수 있는 작업상의 문제점은 툴을 적극적으로 개발해서 해결해 나가야 한다는 것, 그리고 Jenkins 사용을 강력히 추천했습니다. "작동하는 버전이 항상 존재한다는 것은 심리적으로 안정감을 줍니다.(이토 씨)" 유니티를 도입한 결과, 개발 팀의 작업 플로우까지 개선해야 했지만(그러지 않으면 유니티를 도입한 의미가 없으므로) 이를 해결한 두 번째 작품부터는 의심할 여지 없이 '수확기'에 접어들 것입니다.

앞서 밝힌 바와 같이 이번 작품 발매 후 세가를 퇴사하고 유니티의 관계자가 된 이토 씨. 강연이 끝난 후에는 "지금까지 외부 유저로서 느낀 점들을 앞으로는 내부에서 해결해 나감으로써 많은 사람들에게 전파해 나가고 싶다"고 포부를 밝혔습니다.


0 Comments
댓글쓰기 폼