게임 진단과 측정은 데이터에 기반한 결정으로 여러분의 게임을 성공으로 이끄는 데 있어 정말 중요합니다. 게임 진단 결과가 모든 개발 및 비즈니스에 결정을 내리도록 하는 것을 기대해서도 안 되고 그렇게 되지도 않지만, 앞으로 나아갈 길을 결정할 때는 필수불가결합니다.
언리얼 엔진 4는 여러분이 플레이어들의 데이터를 블루프린트에서부터 c++ 임플멘테이션까지 추적할 수 있는 일체의 환상적인 도구를 제공합니다. 또한 설정하는데 오래 걸리지도 않습니다. 여기의 수 많은 문서들과 모바일용 Apsalar와 Flurry 제공자를 위한 Joe의 이전 포스팅도 있습니다. 코드에 자신감이 있고 어느 정도 수준이라고 생각하는 분이라면 다른 코드 제공자의 소스를 사용하는 것이나 스스로 제작하는 것 모두 작업할 것이 많지 않을 것입니다.
이 포스팅에서는 여러분이 이 과정에서 놓칠 수 있는 설정과 제가 알아낸 꿀팁으로 여러분이 우수한 게임 진단을 할 수 있도록 안내를 해 드릴 것입니다.
설정 업데이트 및 재확인
Flurry와는 다르게 Apsalar에서는 실시간 게임 진단을 지원하지 않습니다. 결과값이 나오려면 보통 하루 정도 걸리게 됩니다. 그렇기 때문에 골머리를 썩지 않으려면 적절한 설정을 하고 재확인 하는 것이 중요합니다.
Apsalar가 실시간 게임 진단 기능이 없다고 해도, 여러분은 이벤트 트래킹 콘솔을 통해서 동작중인지를 확인할 수 있습니다. 앱스토어에서 Identifiers를 다운로드 받고 여러분의 IDFA코드를 발급받으세요.
해당 웹사이트에 등록을 하고 나서, 여러분의 API와 비밀 키를 DefaultEngine.ini에 입력시켜 줍니다. 이 키들이 틀리면 여러분의 데이터는 진단 과정이 멀쩡히 돌아가는 것 처럼 보인 이후라도 추적이 되지 않게 됩니다! 또한 세션을 열고 닫는 것을 확실히 해야 하는데, 어떤 소스 공급자는 세션이 종료될 때 까지 게임 진단 결과를 업로드 하지 않도록 코드를 작성하였을 수도 있고, 이런 경우 프로그램이 세션 종료 전에 종료되게 되면 문제가 발생할 수 있습니다.
여러분이 블루프린트를 이용하시려고 한다면, 기본적인 이벤트로부터 플레이어 데모그래픽까지 진단용으로 20개 이상의 블루프린트 노드들이 있습니다. 여러분이 이 옵션들을 찾을 수 없다면, 에디터에서 해당 제공자의 플러그인을 활성화 하였는지 다시 한 번 확인해 보시기 바랍니다.
마지막으로, 흔하게 저지르는 실수는 진단을 위해서 게임을 모바일로 디플로이 하지 않는 것입니다.대부분의 모바일 게임 진단 도구는 iOS/Android 기기로부터만 데이터를 얻을 것입니다.
우수한 게임 진단 해내기: 멀티캐스트, 팁과 요령들
가끔 어떤 진단 프로그램을 사용해야 할 지 고르기가 어려울 것입니다. 각 프로그램들은 각자의 장점이 있습니다. 언리얼 엔진 4의 멋진 기능 중 하나는 멀티캐스트를 이용해서 여러 프로그램을 사용할 수 있도록 한다는 것입니다. 이 것은 여러분이 여러 가지 프로그램의 장점만을 취합할 수 있다는 이야기가 됩니다. 저는 개인적으로 Flurry가 고정 지표를 잘 다루는 데 비해 Apsalar는 이벤트 트래킹을 더 잘 하는 것이라고 생각합니다. 멀티캐스트는 설정하기 아주 쉽고 굉장히 유익합니다. 여러분은 여기에서 관련 문서를 읽어보실 수 있습니다.
여러분이 c++에서 진단 소스를 추가하고 있으시다면 코드의 가독성을 높이고 쉽게 작성하는 몇 가지 방법이 있습니다. 진단 프로그램에서 참조해 올 때, 길게 늘어지는 것을 방지하기 위해 삼항 연산자(역주 ':?' )를 이용하면 좋을 것입니다..
데이터 수집에 있어 여러분은 그룹으로 여러분의 진단을 실제 ‘LOD’할 수 있습니다. 이 것은 데이터를 수집하고 나면 이벤트를 여러 그룹으로 묶어서 정리할 수 있다는 뜻입니다. 모든 값을 트래킹하는 것은 중요하지 않은데, (그렇게 하고 싶으시겠지만) 왜냐하면 여러분은 흥미는 있어 보이지만 쓸데없는 데이터를 한가득 짊어지게 될 것이기 때문입니다.
Joe Graf는 “여러분이 원하는 방향으로 이벤트를 생성하기 위한 변화를 만들어 낼 수 없다면, 기록을 하는 것은 연구 필요성을 제외하고는 무의미합니다. 어떤 데이터를 트래킹할 것인지에 대해 명확히 알고 있는것이 중요합니다.”라고 말했습니다.
Analytics.RecordEvent(bOverheated ?
TEXT("Game.Player.DiedWhileOverheating") :
TEXT("Game.Player.Died"));
if (AnalyticsLOD == METRICS_UI)
{
저희의 모바일용 언리얼 엔진 프로젝트 Smog Game에서 어떤 데이터를 트래킹할지를 결정할 때에는 미리 정해진 가설들을 세우고 결과 데이터를 이용해서 이를 증명 또는 파해시키는 것이 가장 좋은 방법이라는 것을 알게 되었습니다. 예를 들어 Smog 게임을 플레이 하는 중에 여러분은 두 가지의 파워업 중의 하나를 얻게 된다는 것인데, 점수 두배 아이템 또는 슬로모션 아이템입니다.
런칭을 하기에 앞서 저희는 아이템 선택이 5:5로 갈리는 것을 예상하였습니다. 놀랍게도 결과 데이터는 플레이어들이 슬로우모션 아이템을 점수 두배 아이템보다 두 배나 더 많이 줍지 않는다는 것을 나타냈습니다! 이 결과를 다른 수치 및 질적 데이터와 묶어서 슬로우모션 아이템의 밸런스가 맞지 않는다는 것을 조기에 알아내게 되었습니다.
저희가 만약 게임 진단을 사용하지 않았다면 저희는 게임 밸런스를 잘못된 추측에 의해서 맞췄을 것이고 그 결과로 재미가 없어졌을 것입니다.
저희는 또한 시각적으로 플레이어들이 어떻게 각 이벤트간을 이동하는지를 볼 수 있는 ‘funnels’를 이용한 UI흐름 트래킹을 하였고 테스트 계정과 개발 계정을 분리하여서 수집 데이터에 영향을 주지 않도록(데이터 포인트는 삭제를 할 수 없기 때문입니다.) 하는 것이 좋은 방법이라는 것을 알게 되었습니다. 이 방법은 여러분이 언리얼 프로젝트를 우수하게 진단해 내는 첫 걸음이 될 것입니다.
질문이 있으신 분은 트위터 @josh_caratelli로 멘션을 보내 주시거나 아래 코멘트 섹션에 댓글을 달아 주시기 바랍니다.