2014년 10월 9일에 일본에서 출시돼 한달도 채 안돼서 100만 다운로드를 달성한 미스트 워커의 신작 RPG인 TERRA BATTLE은 사카구치 히로노부, 우에마츠 노부오 등 일본 게임 업계의 거물이 참여하면서 주목을 받았으며 게임 자체도 간단한 규칙에 비해 속성의 연관 관계를 제대로 고려하지 않으면 클리어할 수 없어 높은 평가를 받고 있습니다.

 

허나 이 테라 배틀이 유니티를 사용해 개발됐다는 건 별로 알려지지 않았는데요. 여기에선 프로그래머인 오오노 히로시, 유니티 태크놀러지 재팬의 이토 저우, 타카하시 케이지에게 유니티를 사용한 타이틀 개발에 대한 이야기를 들었습니다.

 

 

미스트의 오오노 히로시

 

 

유니티 테크놀러지 재팬의 이토 저우

 

 

유니티 테크놀러지 재팬의 타카하시 케이지

 

 

소규모 개발의 장점은 의사 결정 속도

이토: 사실대로 말하면 유니티를 이용해서 테라 배틀을 개발했다는 건 나중에 안 것인데, 그걸 크게 부각하지 않았네요. 저희들도 유니티 치고는 너무 빠르지 않나? 이렇게 생각했을 정도입니다(웃음).

 

 

오오노:  유니티를 사용했습니다. 딱히 어려운 건 하지 않았습니다(웃음).

 

이토: 멋지네요. 여기에선 그것까지 포함해 유니티를 사용핸 개발에 대해서 오오노씨가 느낀 장점과 단점에 대해 솔직하게 말씀해 주셨음 합니다. 듣기로는 적은 수의 인원으로 개발할 수 있어 의사 결정이 빠르다는 걸 장점으로 꼽으셨다는데요.

 

오오노: 네. 처음에 출시된 버전은 한명의 프로그래머가 개발을 진행했습니다. 지금은 한사람이 늘어 두명이 됐네요.

이토: 그러면 오오노씨 혼자서 거의 다 만든 것이군요. 전체 팀 구성은 어떻게 되나요?

오오노: 각 파트 모두 회사 내부에선 1명씩입니다. 프로그래머, 기획/게임 디자이너, 캐릭터 디자이너, 기타 그래픽 전반(이펙트/UI등)의 디자이너가 됩니다.

타카하시: 서버 프로그램도 오오노씨 혼자서 만드셨나요?

오오노:  그렇습니다. 처음에는 그렇게 할 생각은 없었지만요.

이토: 개인 제작도 아닌데 프로그래머가 한명이란 말은 들어본 적이 없어요.

오오노:  처음엔 오프라인 전용으로 만들었습니다. 그러다가 최근의 트렌드에 맞춰야 한다는 분위기로 바뀌면서 서버를 이용한 온라인 게임이 됐지요. 이때 새로 인력을 추가해야 하나 생각했지만 여러 이유 때문에 결국은 혼자 하게 됐습니다.

이토: 오오노씨는 테라 배틀에서 처음으로 서버 프로그래밍을 하셨군요. 그 전에는 파이널 판타지 시리즈에 참여하셨지요?

 

오오노: 그렇습니다. 전 직장(스퀘어 에닉스)에서는 주로 3D 엔진 개발을 담당했습니다.

이토: 즉 데이터베이스와 프로토콜 통신 등을 다루는 건 정말 처음이었다는 것이군요.

 

 

오오노: 내부 툴에선 만져본 적도 있지만 실제로 출시된 제품에서 작업한 건 이것이 처음입니다.

타카하시: 정말 대단하네요. 그럼 테라 배틀의 개발을 시작한 건 언제이신가요?

오오노: 2013년 6월입니다

타카하시: 그럼 실질적인 개발 기간은 1년 정도군요. 서버 개발까지 포함한 것이니 믿기 힘드네요.

 

오오노: 뭐 여러 문제가 있다 보니 그렇게 됐네요.

이토: 개발은 출시일자에 맞춰 진행한 것인가요, 아니면 개발이 끝나는 대로 출시한 것인가요?

오오노: 원래는 2014년 봄 발매를 목표로 했었습니다. 처음에는 더 가벼운 앱을 생각하고 있었어요. 다만 개발하다보니 점점 욕심을 내서 여러가지를 추가하는 과정에서 2014년 가을(10월 9일)이 된 것입니다.

이토: 그러고보니 출시 후에 큰 버그도 없고 개발을 서둘렀다는 느낌도 없네요.

오오노: 디버깅은 제대로 했으니까요.

타카하시: 소규모 개발이라 의사 결정이 빠르다는 건, 역시 파이널 판타지 시리즈 같은 대규모 개발과 비교했을 때 그렇다는 건가요?

오오노: 그렇습니다. 큰 프로젝트에서 뭔가 큰 결정을 할 때는 아침부터 미팅을 시작해 끝나면 밤이 되죠. 테라 배틀은 바로 옆에 있는 직원과 이렇게 하자고 정해서 그 자리에서 만드는 것 같았습니다.

 

이토: 처음에는 시행 착오가 많았다고 들었는데요.

오오노: 아뇨. 처음이 아니라 처음부터 끝까지 시행 착오였습니다. 제대로 기준을 정하지 않고 만들어서 그렇죠.

이토: 오오노씨는 디렉터도 겸임하고 있으니 직접 기준을 정해서 스스로 구현하는 식이 되나요?

오오노: 흐름을 보자면 우선 사카구치 히로노부씨가 이렇게 하고 싶다 저렇게 하고 싶다는 요청을 문자로 보냅니다. 그럼 거글 어떻게 구현할까 생각하고 만들어 사카구치씨에게 보내는 식입니다.

이토: 사카구치씨 본인도 유니티에서 테스트 플레이를 했나요?

오오노: 아뇨. 제가 매일 iOS용 빌드를 만들어 사카구치씨에게 보냈습니다.

이토: 바로 프로토타입을 만들어 보낸다는 겁니까? 이건 구식 게임 개발 방법처럼 보이네요.

 

오오노: 네. 제가 스퀘어 에닉스에 입사하기 전에 패밀리 컴퓨터/슈퍼 패미컴 시절에는 그렇게 했다고 합니다.

타카하시: 사카구치씨 정도의 경력이 있으니 원점 회귀가 가능한 것이겠지요. 저희들만 해도 옛날에는 그랬다더라 정도로 이야기할 뿐입니다.

오오노: 스마트폰 게임이 나오면서 소규모 개발로 돌아왔습니다. 개인적으로 한명의 프로그래머라는 건 이번이 처음인지라 불안하기도 했습니다. 지금은 다행이네요.

이토: 실은 테라 배틀에 대한 이야기를 들었을 때 대규모 개발이 아니었을까 생각했습니다.

오오노: 아뇨. 철저하게 소규모로 개발했습니다.

 

 

플래너와 디자이너가 직접 유니티를 이용해 데이터를 관리

 

 

이토: 두번째로 잘한 거라면 기획 담당자나 디자이너가 유니티를 직접 조작하고 실행하는 환경에서 데이터 관리를 수행한 것을 꼽습니다.

오노: 네. 팀원이 제각각 유니티를 사용해서 특수 효과를 만들었습니다.

이토: 그럼 유니티의 파티클 시스템인 슈리켄을 사용했나요?

오오노: 네. 거의 그것만 사용했습니다. 입자를 조합해 재생한것 뿐이네요.

이토: 상업용 게임을 개발할 땐 직접 툴을 만들기도 하는데 그러진 않았군요.

오오노: 솔직히 말하면 그런 것까지 개발할 여력이 없었다고 해야 할 것입니다. 그래서 가능한 범용 툴을 썼습니다.

이토: 기획 담당자도 유니티는 처음이었나요?

오오노: 그렇습니다.

타카하시: 캐릭터의 능력치 조정은 어떤가요. 대형 RPG에선 엑셀 같은 외부 툴로 관리하는 경우가 많은데요.

오오노: 그건 역시 엑셀을 사용했네요.

이토: 엑셀의 데이터를 유니티에서 불러오게 했나요?

오오노: 마지막엔 엑셀의 데이터가 꽤 커진데다 처리도 무거워져서 어떻게 바꿔야 겠다고 생각 중입니다.

이토: 데이터베이스에 일일이 액세스하다보면 응답 속도가 느려지겠지요.

오오노: 그래서 지금은 데이터를 엑셀에서 관리하고, 나중에 조정할 때는 실시간으로 설정 값을 수정해 동작을 확인하고 있습니다.

 

 

이토: 서버 운용에서 데이터베이스를 사용하는 건 어느 부분입니까? 사용자 관리인가요?

오오노: 사용자의 관리와 이벤트 관리에 씁니다. 이미지에도 쓰긴 하네요.

이토: 그럼 수시로 액세스하게 될텐데요.

오오노: 네. 필요에 따라 다운로드하는 식입니다.

이토: 그건 에셋 번들을 사용할 겁니다. 이것도 첫 경험이긴 한데 꽤 잘 쓰는 것 같아 감탄했습니다.

오오노: 엄청 고생했는걸요. 개발 중에 유니티의 버전이 3에서 4로 바뀌며 포맷이 달라지는 바람에 읽어올 수 없었습니다.

이토: 그랬지요... 죄송합니다. 

오오노: 앞으로도 그런 일이 있을가 조금 불안합니다. 그리고 버전업이 어디까지 진행될지도 궁금하네요.

 

 

 

유니티의 플러그인을 활용한 개발 노력 절감

 

 
이토: 세번째로 좋은 점이라면 NGUI와 내부 결재 플러그인 등, 검증된 플러그인을 사용해 개발 노력을 줄였다는 걸 꼽을 수 있습니다. NGUI는 UI 툴인데 적극적으로 활용했습니다.

오오노: 그렇습니다.

타카하시: 그밖에 사용한 플러그인이 있나요.

오오노: 그 두가지 뿐이에요.

이토: NGUI는 자신이 사용한 건가요 아니면 UI 디자이너가 쓴 건가요?

오오노: 제가 쓴겁니다.

 
이토: UI 데이터를 받아 오오노씨가 구현하는 식인가요?

오오노: 아니요. 이런 식으로 만들어달라는 이미지를 포토샵으로 그려주면 제가 UI를 만드는 것입니다.

이토: 그렇군요. UI 데이터 자체를 디자이너가 만드는 건 어떤가요?

오오노: 그건 무리라고 생각합니다. 그렇게 쉽지 않네요. 개인적으로는 버전 4에서 도입하는 새로운 UI 툴을 기대했는데, 그게 나오지 않은 채로 테라 배틀이 출시됐습니다.

이토: 그러네요. 벌써 1년이 지났으니.. 죄송합니다.

타카하시: 적 캐릭터가 사라질 때의 효과에 정교한 쉐이더를 쓰는 편인데요.

오오노: 그건 픽셀 쉐이더로 만들었습니다.

타카하시: 그렇게 바깥으로 보이는 건 에셋을 쓰기보다 직접 만드는 게 많지 않을까요?

오오노: 그렇습니다. 별 일은 아니라서 가능한 그렇게 하자는 식입니다만.

타카하시: 모바일 게임에서 낮은 수준의 쉐이더라 해도 직접 만들기는 쉽지 않지요.

오오노: 거꾸로 말하면 그렇게밖에 만들지 못했어요(웃음).

이토: 특수 효과 외에 다른 부분에 쉐이더를 쓴 건 있습니까.

오오노: 아군 유닛을 이미지 2장으로 그린 후 그걸 합성할 때 쉐이더를 일부 사용합니다.

 
타카하시: 그런 용도로도 썼군요. 사실 테라 배틀은 로딩이 빠른데 화질이 높다고 생각했습니다만, 로딩이 빠른 게임의 경우 무리한 압축 데이터를 쓰다가 윤곽선이 거칠어지는 사례도 적지 않습니다.

오오노: 딱히 연구했다고 할 정도는 없지만... 물론 근본적인 리소스의 양을 되도록 줄이자고 생각은 했습니다.

이토: 그럼 메모리의 압박을 받아 어려운 점은 없었나요? 카드 게임처럼 화면에 많은 유닛을 표시하는 형식이라 메모리 점유가 많을 것 같은데요.

오오노: 처음에는 어떻게 하면 메모리 사용량을 줄일 수 있을지 몰랐어요. 하지만 보통은 매뉴얼대로 하면 되더군요. 뭐 참조한 데이터가 남아 있고 사라지지 않는다는 문제는 있었지만요.

이토: 렌더링에서 DrawCall의 수를 제한해야겠다고 생각하진 않았나요?(드로우 콜의 실행 횟수가 늘어나면 성능이 떨어짐)

오오노: 그건 당연히 Atlas(여러 텍스처를 한장으로 정리한 것)을 만들어서 관리했습니다. 특히 UI 쪽에요. 그리고 중간에 스프라이트를 구현해서 사용하기도 했습니다.

이토: 그런가요? 스프라이트는 어디에 사용했습니까?

오오노: UI의 일부에 썼습니다. 전투 중 표시되는 문자는 스프라이트로 그렸습니다. 무기의 아이콘도 마찬가지입니다.

 

 

백엔드 서버에 Google App Engine을 사용했을 때의 장점

이토: 4번째 좋은 점으로는 백엔드 서버에 Google App Engine을 채용해 적은 인원으로 개발 운용이 가능한 것인데, 이 엔진도 이번에 처음으로 사용하신 것이죠?

오오노: 사실은 테라 배틀 이전에 발표하지 않은 타이틀이 있는데 그때 사용해 봤습니다.

타카하시: 개인적으로 구글 앱 엔진은 좋아하지만 그걸 게임의 백엔드 서버로 사용하는 경우는 별로 들어보지 못했습니다.

 

오오노: 아마도 다른 분들은 새로 사용법을 배워야 한다는 점 때문에 주저하시는 것 같아요. 저는 데이터베이스의 초보다보니 뭐든지 배워보자는 생각으로 골랐어요. 처음 시작한다면 이게 좋을것 같았거든요.

이토: Google App Engine이 뛰어난 툴이긴 하지요.

타카하시: 운용에는 문제 없었나요?

오오노: 아무 문제도 없었습니다.

타카하시: 이론적으로는 그런데... 서버는 처음이셨다고 하셔서요.

이토: 정말로 실현에 성공하실 줄은 몰랐어요.

오오노: 트랜잭션 처리 중에, 예를 들면 글로벌 카운터(어떤 처리에서도 액세스할 수 있는 카운터용 변수)를 늘릴 때는 조금 신경을 쓸 필요가 있었습니다. 테라 배틀을 서비스한 첫날엔 여러 분들이 리셋을 하다보니 대량의 리퀘스트가 들어오면서 글로벌 카운터가 늘어나 에러가 발생하기도 했습니다. 그리고 그게 다입니다.

이토: 앞으로 친구 기능은 추가 되나요.

오오노: 협력 플레이의 개발을 추진하고 있으니 함께 만들고 있습니다.

이토: 그렇게되면 트랜잭션이 발생하는 부분도 늘어나죠.

오오노: 그러네요. 친구 기능과 협력 플레이에는 다른 서버를 사용하려고 생각합니다.

이토: 정리하면 처음으로 Google App Engine을 써봤지만 꽤 잘 됐다는 말인가요?

오오노: 그렇습니다. 원래 이번에는 적은 수로 개발한다는 것이 대전제였습니다. 그래서 적은 수로 구글 앱 엔진을 사용한 소규모 개발 사례를 본 적이 있어서 이걸 골랐습니다.

 

 

프로그래머 한명의 개발 체제는 다시 하고 싶지 않다

이토: 그럼 유니티를 쓰면서 잘못했던 점에 대해 알려 주세요. 우선 개발 인원이 너무 적었다고 말씀하셨는데, 프로그래머가 한명이라는 건 정말 무모해 보이긴 합니다.

오오노: 프로그래머 뿐만 아니라 게임의 설정 값을 만드는 것도 혼자서 하다보니 전체적으로 인력이 부족했습니다.

이토: 벨런스 조정은 어떻게 했나요?

오오노: 디버깅을 할 때 의견을 받아 조정하기도 했지만 기본적으로는 직접 플레이하고 벨런스를 잡았습니다.

타카하시: 다음번에는 개발 인원을 더 늘리실 생각이신가요? 

오오노: 네.이 체제로 두번 다시 개발하고 싶진 않네요(웃음).

이토: 그래도 프로그래머가 혼자라서 장점이 있다고도 생각하거든요. 그걸 유지하면서 인원을 늘리려면 어떤 체제가 바람직하려나요.

오오노: 적을수록 좋지만 프로그래머가 한명일 필요는 없습니다. 오히려 너무 많으면 미팅만 늘어나니 2,3명이 딱 좋지 않을까 생각합니다.

이토: 유니티에서 여러 프로그래머가 작업을 나눈다면 어떻게 하는 게 좋다고 생각하세요?

오오노: 프로그래머라면 모두가 같은 프로젝트 파일을 다뤄도 괜찮다고 생각합니다. 다만 디자이너가 같은 파일을 사용하면 서로 작업 내용이 충돌할 수도 있으니 권한을 설정할 필요가 있겠지요. 사실 테라 배틀 정도의 규모에서도 이런 일이 일어나더라구요.

이토: 그것은 버전 5 이후에 여려 변경이 있게 되니 기대해 주세요. 

오오노: 처음엔 테라 배틀도 에셋 서버에서 버전 관리를 했는데 권한 설정이 안 되다보니 도중에는 SVN(Subversion)로 바꿨습니다.

이토: 그러면 캐시 서버도 사용하시나요.

오오노: 그건 사용하고 있습니다.

 
이토: 그럼 iOS와 안드로이드 버전이 동시에 사용하지요? 

오오노: 그렇습니다. 둘 다 사용하기에 캐시 서버가 없다면 시간을 잡아먹습니다.

이토: 이야기를 되돌려서, 프로그래머의 수가 늘어나면 그건 그거대로 문제가 생긴다구요.

오오노: 그래도 팀원이 10명 정도라면 어떻게 되겠지만 그 이상은 힘들겠지요. 

이토: 테라 배틀은 프로그래머가 한명이라는 것을 장점으로 삼을 수 있었군요.

오오노: 그렇습니다.

이토: 그럼 프로그래머가 한명 더 있었다고 생각한 부분은 어디였습니까?

오오노: 아까 조금 말씀드렸는데 본격적으로 서버를 도입했을 때입니다. 역시 제대로 된 경험이 있는 사람에게 맡기는 게 좋겠지요.

 

 

온라인 운영 게임 개발의 어려운 점을 극복할 수 있었던 요인

 

 

이토: 그 다음으로 잘못한 점으로는 혼자 프로그래밍을 하다보니 주석과 리팩토링 등의 정리에 게을렀다는 점을 꼽으셨어요.

오오노: 제가 알고 있는 것이다보니 방치하게 됐습니다. 그리고 물량이 많다보니 수정할 시간도 없었네요. 그런 상황에서 새로운 프로그래머를 영입하다보니 어려운 상황을 맞이하게 됐습니다.

이토: 소스 코드를 보면서 하나하나 확인하는 느낌입니다.

오오노: 뭐, 새로 들어오신 프로그래머가 우수한 분이라서 아직 문제는 일어나지 않았네요.

이토: 구현 중에는 리팩토링을 생각하진 않으니까요. 

오오노: 전에는 개발 팀이 크다보니 리팩토링을 제대로 했는데요. 혼자 하다보면 아무래도 다른 걸 더 먼저 하다보니 좀처럼 짬이 안나네요(웃음).

이토: 언어도 일본어로 만드려면 지금의 유니티에선 좀 귀찮지요.

오오노: 네. 그래서 기본적으로는 영어로 주석을 답니다. 복잡한 주석만 다른 에디터를 실행해 일본어로 주석을 쓰고 이를 복사해서 붙여넣고 있습니다.

이토: 그건 앞으로 고치겠습니다.

오오노: 다른 에디터 프로그램을 실행하기가 귀찮으니 부탁 좀 드리겠습니다.

이토: 그럼 잘못했던 점 3번째에 대해 이야기하지요. 온라인 운영 게임 개발 경험이 부족해 시행 착오를 반복했다고 하셨는데요.

타카하시: 완성된 테라 배틀을 보면 그렇게 생각되진 않는데요.

오오노: 여러 조언을 받아 개발한 결과 어떻게든 만들었다고 생각합니다.

이토: 팀 내에 온라인 게임 개발의 경험이 있으신 분은 계신가요?

오오노: 한명도 없습니다.

이토: 경험 없이 게임을 만들었다가 실패하는 경우도 있는데 말이죠.

 
오오노: 실제 개발 중에는 그런 것까지 따져봐야 할까 생각이 드는 경우가 많았습니다. 예를 들자면 유료 결재가 있네요. 일일이 서버에 액세스를 해야 하나 생각이 들었습니다. 처음에는 클라이언트에서 하는 게 어떨까 이렇게 생각했는데(웃음).

이토: 설마 그럴리가요(웃음)

오오노: 개발을 처음 시작했을 땐 그랬습니다.

이토: 지금도 그런 문제가 있습니까?

오오노: 대부분의 업계 종사자들이 안고 있는 문제라 생각하는데, 치트가 문제가 됩니다. 예를 들면 유료 결재를 할 때 서버에 가짜 데이터를 보내는 경우도 있습니다.

이토: 테라 배틀에선 어느 정도로 그런 일이 일어났나요? 일본 뿐인가요?

오오노: 세계 각국에서 일어나고 있습니다.

이토: 물론 세계에는 다양한 사람들이 있으니까요. 그러나 그걸 염두에 둔다 해도 테라 배틀은 첫 시도라 믿기 어려울 정도로 잘 해나가는 타이틀입니다. 그건 단지 조언을 받았기에 가능하다고 보진 않는데요.

오오노: 저 자신이 불안하다보니 개인적으로 경험자들에게서 많이 들어본 게 유효했을지도 모르겠습니다.

이토: 책 말고 직접 들었던 것인가요?

오오노: 그렇습니다. 지금은 많은 게임 개발자들이 스마트폰 전용 타이틀 개발을 해본 경험이 있으니까요. 결재가 끝났을 때 주고 받는 데이터도 실제와 같은 형식으로 보내 제대로 확인하는 게 좋다고 들어 큰 문제가 되기 전에 대책을 세울 수 있었습니다.

이토: 지금은 플레이어끼리 경쟁하는 요소가 게임에 없다는 것도 문제가 적은 이유일수도 있겠네요.

오오노: 네. 서버가 단순하다보니 문제가 적다고 생각됩니다.

 

 

보스의 개성적인 행동 패턴은 기획자가 하나하나 만든 것

 

 

이토: 그럼 몇가지 이야기를 들려주세요. 아까 했던 말이기도 한데 기획할 때 따로 사용한 툴은 엑셀 뿐인가요?

오오노: 자바스크립트도 있습니다. 적 캐릭터를 움직이는 AI의 스크립트를 만들 때 썼지요. C#에서는 좀 어려운 작업이었거든요.

이토: 자바스크립트라면 유니티의 유니티 스크립트인가요? 

오오노: 네. 유니티 스크립트입니다. 

이토: AI의 구조를 유니티 스크립트로 만들어 소스 코드에 적용했잖아요. AI를 클라이언트가 아니라 서버에 둘 수도 있다고 보는데.

오오노: 그렇게 하는 게 좋을까 생각하기도 했지만 보안에서 걸리는 점이 있었지요. 그리고 귀찮았습니다(웃음). 다만 유니티는 자바스크립트가 늘어나면 컴파일이 무겁다고도 하지요.

타카하시: 대량의 자바스크립트를 넣은 프로젝트를 본 적이 없어서 뭐라 하기가...

이토: 어쩌면 자바스크립트에 한정된 것이 아니라, static 변수 등에서 테이블이 많으면 무거워질지도 모릅니다.

오오노: 서로 참조하지 않은 독립된 스크립트라서 그럴 일은 없다고 생각합니다만.

이토: 자바스크립트에 국한된 것은 아니고 소스 코드가 많을수록 무거워지기가 쉽습니다. C#라면 빠르겠지요.

타카하시: 그건 좀 체크해 볼 필요가 있네요. C#가 쓰기 어려워 자바스크립트를 쓰는 경우가 많다보니 실제 환경에선 보기 어려운 사례라 생각하는데 어떨까요.

오오노: 그러네요. 실제로는 템플릿화한 코드를 만들어 그걸 조금 손보는 정도였습니다. co-routine을 쓸 때 C#에선 StartCoroutine라고 써야 하는지만 자바스크립트라면 필요하지 않다는 이유 정도였네요. 

이토: AI의 루틴을 스크립트로 작성하면 if문 같은 것도 나오지 싶은데요.

오오노: 그런 부분도 있긴 하지만 기본적으로는 이걸 하고 저걸 해라 이런 순서의 나열입니다. 가끔씩 조건을 보고 행동을 바꾸라는 수준입니다.

이토: 예를 들자면 30%의 확률로 특수 행동을 한다. 이 수준보다는 더 논리적으로 생각하는 AI겠네요.

 

 
오오노: 보스는 더 복잡하게 움직입니다.

이토: 보스는 챕터마다 등장하는데 AI는 전부 따로 만드시나요?

오오노: 네. 챕터마다 따로 만듭니다.

이토: 각각의 특징이 있지요. 예를 들어 세로로 공격할 때에는 세로로 이동, 옆으로 공격할 때는 옆으로 이동하는 보스 같은 식으로 논리적으로 AI을 만들지 않으면 안 됩니다.

오오노: 그걸 모두 다룬다면 데이터가 엄청 커지니까요. 

이토: 포텐셜 맵이 아니라 이렇게 하면 이렇게 움직인다. 이걸 하나하나 만든다면 노가다라고 해야 할까요. 품을 많이 들여야겠다고 생각되네요.

 

 

질서 정연한 개발이 아니라, 수습할 수 없는 방식으로 만든 이유

 

이토: 이야기를 들어보니 테라 배틀의 개발이가 상당히 즉흥적이란 느낌을 받습니다.

오오노: 근성으로 만들었습니다(웃음).

타카하시: 스태프 중 누구에게 사고가 났다면 개발이 중단됩니다.(웃음).

이토: 스타 플레이어라고 하나요? 스킬이 있는 분들이 팀에 모여있는 그런 식...

오오노: 오래된 스타일이지요.

이토: 지금까지 대규모로 게임을 만들었던 것과 다르니까 뭔가 갈등을 겪은 것도 있지 않나요? 예를 들면 개발 주기가 빠르다는 게 싫다던가.

오오노:  그렇지 않았습니다.

이토: 이런 개발 스타일이 마음에 드시나봐요.

오오노: 그렇다고 생각합니다. 기획이 계속 바뀌는 것 말이에요.

이토: 원래의 기획은 어떤 것이었나요?

오오노:  기본적인 게임의 규칙은 변하지 않았습니다. 게임의 소재-보스전이나 벨런스 조정에 시간을 잡아먹었습니다. 또 아군 캐릭터 중에 이런 게 없다는 생각이 들어서 그걸 손대기도 했구요.

이토: 말씀대로라면 프로그램을 만들고 구현하고 사카구치씨의 의견을 받아 고치는 식이었다고 할 수 있겠네요. 매일 그렇게 반복했다는 것인가요?

오오노: 그렇습니다. 거의 매일요.

이토: 매일 사카구치씨가 기획을 문서로 보내는 건가요?

 
오오노: 이렇게 하면 좋겠다고 메일이 오면 그걸 다음날까지 형상화하는 일이 반복되더군요.

이토: 그렇군요. 사카구치씨는 다른 인터뷰에서 오오노씨가 뛰어나다고 칭찬했는데요. 그걸 반대로 보면 유니티는 프로그래머 한명으로 뭐든지 할 수 있다고 오해할까봐 무섭네요.

오오노: 저 자신은 재미있었는데요. 힘들 때도 있었지만요. 처음에는 더 간단하게 데이터를 늘려 게임을 확장하자고 생각했는데, 사카구치씨는 더 정신없게 하지 않으면 안 된다고 말하더군요.

이토:  정신없게인가요...

오오노: 자신도 수습할 수 없을 정도로 만들면 결과적으로 재미있을 수 있다고 계속 말했어요.

 

이토: 조정은 하지만 그래도 수습이 안 되는 게 좋다는 건가요.

오오노: 저는 이런 방법으로 연습할까 생각 중이에요. 다만 앞으로 추가해 나갈 데이터도 똑같이 만들어 나가야겠지요.

이토: 온라인 운영 게임이니까요. 오프라인 게임 개발을 했던지라 온라인에는 끝이 없다고 느끼는 경우가 많습니다. 오오노씨도 그 차이를 지금 느끼고 있는 것 아닌가요.

오오노: 느낍니다. 언제 쉴까 이런 생각도 들고(웃음). 그래서 인원을 늘려 교대로 쉴 수 있는 체제를 구축하고 싶습니다.

 

 

개발중인 에디터 화면

 

 

부드러운 터치와 처리에서 실수하지 않는 걸 우선

타카하시: 기본적인 부분이지만 테라 배틀의 최저 동작 스펙은 무엇을 기준으로 하는 것인가요? 그래픽은 꽤 화려한 편이네요.

오오노: 아이폰 4S, 안드로이드도 비슷한 수준으로 잡았습니다. 일단 아이폰 4에서도 돌아가지만 약간 느리네요.

이토: 터치의 촉감은 따로 연구한 점이 있으신가요?

오오노: 네. 손가락의 움직임을 따라올 것. 1초당 60프레임 표시는 필수라고 생각합니다. 조작은 유닛을 빠르게 움직일 때 적에 걸리는 것이 마음에 들지 않는다는 등, 평가가 나쁜 부분도 있지만 이건 구현보다는 스펙의 문제네요.

이토: 유니티는 그렇게 부드러운 동작을 실현하기가 어렵다는 말을 자주 듣는데요.

오오노: 가능하다면 입력과 표시를 다른 스레드에서 했음 좋겠습니다. 그러면 자주 표시를 갱신하지 않아도 되니까요. 일부 기종은 이펙트와 적이 화면에 많을수록 프레임 레이트가 떨어져 터치가 잘 안 되거든요.

이토: 그래도 충분히 예쁜 표시를 실현할 수 있다고 느낍니다. 그 밖에 고생한 점은 있습니까?

오오노: 고생한 점이라면 유니티 객체 구조 프레임에서 객체를 생성하는 작업이 느리다는 겁니다. 그래서 테라 배틀은 기본적으로 모두 하나의 장면에서 처리했습니다. 

이토: 장면 전환을 안 하는군요?

 
타카하시: 실은 버전 4.5에서 그게 빨라졌는데....

오오노: 그런가요? 장면 전환을 하지 않기로 정한지라 몰랐던 것일수도 있습니다.

이토: 지금의 만든다면 제대로 자원 관리를 해야 하는데 그건 어땠나요?

오오노: 그건 괜찮았어요. 다만 구조가 좋으나 사용하긴 힘들다는 느낌을 받았습니다. 

이토: 한 장면에서 모든 것을 조달하는 데 뭔가가 도움이 된 게 있을까요?

오오노: 유니티의 사례를 여럿 확인하면서 객체 생성이 느리다는 걸 알았습니다. 그리고 비동기로는 안 된다는 걸 확인했지요. 리소스는 비동기로 가져올 수 있지만 그 때 객체 생성을 하면 갑자기 느려지는 게 싫었어요.

이토: 뭔가 발생했을 때 늦거나 조작이 불편하게 되니까요.

오오노: 로딩 표시를 보여주는 게 싫었거든요. 결국 모든 것을 한 장면에서 처리한다는 지금 형태로 가게 됐습니다.

이토: 만약 기회가 되면 객체 생성이 빨라졌음을 체감해 주셨음 좋겠습니다.

오오노: 좋습니다.

타카하시: 하나 더. 테라 배틀에는 동영상 공유 기능이 있는데 실제 사용율은 어떤가요?

오오노: 그렇게 많이 쓰이는 건 아니지만 그럭저럭 공유가 되네요.

 

 

이토: 그걸 구현하는 것도 사카구치씨의 아이디어인가요?

오오노: 아뇨. 그보다는 프로모션의 일환입니다. 게임을 보급하려면 그런 기능이 있는 게 좋다고 생각해 마지막에 넣었습니다.

이토: 도입에는 시간이 얼마나 걸렸나요? 

오오노: 1주일 정도였다고 생각합니다. 비교적 쉽게 됐습니다.

이토: 덧붙이자면 유니티도 에브리플레이라는 동영상 공유 서비스가 있긴 한데..

오오노: 죄송합니다, 개발이 바쁘다보니 몰랐습니다.

이토: 어쩌면 이쪽이 더 간단했는지도 모르겠네요. 다음 기회에는 꼭 검토 부탁 드립니다.

 

 

앞으로의 전개는 언론에 게재된 사카구치 히로노부의 발언을 보고서야 처음 알게 됨

 

 
타카하시: 테라 배틀은 앞으로 성장할 여지가 큽니다. 예를 들어 협력 플레이나 대전 플레이, 여기에 따른 친구 기능까지. 다운로드 스타터(앱 다운로드 수에 따라 컨텐츠를 늘리는 프로젝트)의 달성 정도에 따라 이러한 요소를 계속 추가해 나가게 되는군요.

오오노: 열심히 하겠습니다. 이거 말고 지금 드릴 말씀이 없네요(웃음).

이토: 다운로드 스타터로 추가되는 요소는 오오노 씨도 알고 있던 것이지요?

오오노: 아니요. 발표된 내용을 보고서야 그렇구나 하고 생각했던 항목이 많습니다. 사카구치씨가  갑자기 말하는 것도 많구요. 그렇게 정해진 이상 앞으로 잘 하는 수밖에 없다고 생각될 따름입니다.

타카하시: 그렇게 앞을 내다보는 건 플레이어 입장에선 재밌으나 개발자 입장에선 힘들겠네요.

오오노: 출시하기 전에는 좋았지만, 이제는 좀 더 잘 생각해 달라고 사카구치씨에게 말하고 있습니다(웃음).

이토: 200만 다운로드를 달성하면 콘솔 버전도 개발한다고 하는데, 금방 달성될 것 같은데요.

오오노:  그런가요? 어쩜 좋죠...

이토: 그렇게 되면 과연 유니티로 계속할 수 있을까 생각하게 되는데요.

오오노: 그러네요. 어쩌면 유니티를 안 쓸수도 있을 겁니다.

이토: 조작도 터치가 아니니까 다시 만들어야 하지요. 이 또한 큰 도전이 될것 같아요. 

타카하시: 사카구치씨는 컨슈머 버전을 MMO로 만들겠다고 말한 바 있습니다.

오오노: 그런가봐요. 저도 사카구치씨의 인터뷰를 읽고 나서야 그런가? 이런 생각이 들었습니다. 아까 했던 말을 다시 하게 되지만 지금으로선 열심히 하겠다는 말 밖에 드릴 게 없습니다.

이토: 좋아요. 앞으로도 유니티를 잘 부탁드립니다. 오늘 정말 감사드립니다.