가끔 보자, 하늘.

게임 다 만들고, google play에 프로젝트 등록하고 로그인을 해봤는데 마지막 로그인에서 계속 fail뜸. 

원인을 찾던 중 로컬에 등록한 keystore의 값을 google play api 관리자에 등록을 안 해서 발생한 문제였음. 

아래 이미지 중 붉은 테두리 안에 keystore에 등록된 sha1 값을 등록해야 함.

(keytool -list -v -keystore "자신이 등록한 keystore 이름" 을 입력하면 sha1 값을 볼 수 있다.)

구글의 App engine은 App Engine Hosting 과 Managed VMs Hosting 두 가지 중 한가지를 선택할 수 있습니다. 

이번에는 이 둘의 차이점과 앞으로 사용할 Managed VMs Hosting에 대해 상세히 정리해 보겠습니다. Managed VMs Hosting은 2015년 7월 현재 베타 서비스 중이며, 이곳에 기록되는 내용은 이후 계속 변화할 수 있음을 참고하세요. ..... 를 줄줄이 쓰려 했으나 사실 공식 페이지에 워낙 잘 나와있어서, 괜히 사족 안달고  간단히 정리합니다. 

둘은 차이점은 https://cloud.google.com/appengine/docs/managed-vms/ 의 중간 정도에 나와있는 표를 보시면 쉽게 이해하실 수 있습니다.

제가 생각하는 가장 큰 장점은 기존에 정해진 Java, Go, Python, PHP가 아닌 다른 언어로 제작된 어플리케이션을 올릴 수 있다는거죠. 끝!! 

이 아니고.. 기존에 쓰려던 글 중 둘의 차이를 설명한 내용만 아래 남겨두었습니다. 굳이 보실 필요는 없지만... 한번 간단히 읽어 보셔도 됩니다. ^^

=============================================================================

이전 세대에서는 게임 서비스를 위해 IDC와 회선을 임대하고 IBM과 같은 회사에서 서버 시스템을 구매하여 IDC에 설치해야 했으며, 규모가 클 경우 이를 관리하기 위한 인력을 IDC 센터 내에 직원을 두어야 했습니다. 유저가 급격히 증가할 경우를 대비해 시스템 공급업체와 협상하여 빠른 시간안에 시스템을 투입하기 위한 계약을 했어야 했죠. 해외에 서비스를 위해서는 더 복잡한 절차가 기다리고 있었습니다. 게다가 서비스를 위한 대부분의 기능을 직접 개발을 해야 했습니다. 보안 업데이트와 같은 중요한 OS 변경 때마다 개발자와 운영자들의 스트레스를 극도로 상승시키곤 했죠.

Google App Engine 은 Platform as a Service입니다. 

이제 우리는 서비스할 기능을 구현하고, Google의 인프라스트럭쳐에 올려 빌드하고 간단히 배포할 수 있습니다. Google Console을 이용해 원격으로 시스템의 상태를 실시간으로 확인할 수 있으며, 유저의 증감에 따라 GAE에 설정한 대로 어플리케이션을 실행하는 서버들이 자동으로 증가,감소가 진행됩니다. GAE의 메인터넌스는 이제 다운없이 진행이 됩니다.(이에 대해서는 이곳을 참고해 보세요. 아.. 나프다 애청하고 있습니다. 더 많은 개발자 분들이 들으시길 바랩니다. ^^)이전과는 비교할 수 없을 정도로 간편해 졌으며, 운영비용을 획기적으로 줄일 수 있게 되었습니다.

이를 통해 로컬의 작은 회사조차도 전세계에 자사의 서비스를 사용할 수 있게 되었습니다.

기존에 GAE를 활용하는 방법을 기술한 훌륭한 서적들과 아티클들이 많이 있지만 굳이 제 블로그에 다시 정리하는 이유는, 제 경험이 미천하여 기록하며 배우고자 함이며, 저와 같은 시도를 하시는 분들께 조금이나마 도움이 되었으면 하는 마음입니다.

서론이 길었네요. 이제 본론으로 들어가겠습니다.

(* 아래 단락의 참고/이미지출처 사이트: https://cloud.google.com/appengine/docs/managed-vms/)

GAE는 2015년 7월 현재, 두 가지 호스팅 옵션을 제공합니다. 하나는 기존의 App Engine Hosting 이며, 2014년경부터 지원하기 시작하여 아직 베타 서비스 중인, Managed VMs Hosting 입니다. 

이 둘의 차이를 아래의 이미지에서 간단히 이해할 수 있습니다.

위 참고 사이트의 중간쯤을 보시면 아래의 표를 보실 수 있는데, 위 그림과 같이 보시면 startup time이 왜 이렇게 차이가 나는지 알 수 있습니다.

Instance startup time을 언급한 이유는 App Engine sandbox와 비교해 이 요소 이외에 단점이 거의 없기 때문입니다.

.

.

.

연재 순서

 1. Node.js로 App Engine 사용하기 - 들어가며... 

 2. Node.js로 App Engine 사용하기 - App Engine Hosting과 Managed VMs Hosting

 3. Node.js로 App Engine 사용하기 - Hello World with Node.js

 4. Node.js로 App Engine 사용하기 - 데이터 다루기

 5. Node.js로 App Engine 사용하기 - 인증

 6. Node.js로 App Engine 사용하기 - 로깅

 7. Node.js로 App Engine 사용하기 - Cloud Pub/Sub 서비스 시용하기

 8. Node.js로 App Engine 사용하기 - Cloud 설정하기

 9. Node.js로 App Engine 사용하기 - 게임 릴리즈 절차 정리

10. Node.js로 App Engine 사용하기 - 마무리 하며...

그럼 다음 글에서 뵙겠습니다. 

현재 구글 앱 엔진은 java, python, go,php 네 가지 언어를 사용한 어플리케이션을 지원합니다.

위 언어 이외의 언어들(nodejs, perl, runy 등등)은 앱 엔진의 runtime 옵션에 custom 이 추가되면서 사용이 가능해졌습니다. (app.yaml의 옵션에서 설정이 가능합니다.)

현재 베타로 운영되고 있으며, 서버는 베타 기간 동안은 오직 북미에서만 운영된다고 합니다. 

가격에 대해서는 사용한 만큼 측정한다고 되어 있는데, 얼마나 써야 유료가 되는지, 유료로 전환할 경우 대략적인 비용이 얼만지는 바로 다음 글에서 측정해 보겠습니다.

이를 위해 Docker를 같이 다룰텐데, Docker에 대해서는 상세히 언급하지는 않을 예정입니다. 

Node.js와 Docker에 대해서는 이미 알고 계시다고 가정하고 진행하겠습니다. Docker는 깊이 있게 다루지 않으니 모르셔도 일단 진행하시면서 익히셔도 되니 참고하세요.

=============================================================================

시작하기 전에 아래 내용에 대한 준비가 필요합니다. 

- gmail 생성

- https://cloud.google.com/appengine/ 에서 무료평가판 신청

- google app engine sdk를 설치. 이는 로컬에서 구글앱엔진의 가상환경을 구축합니다.

- nodejs 설치

=============================================================================

https://cloud.google.com/nodejs/getting-started

https://github.com/GoogleCloudPlatform/nodejs-getting-started

위 두 사이트를 지속적으로 참고하세요. 앞으로 길지 않은 글을 작성하는 동안 위 샘플 프로젝트와 공식 사이트를 많이 참고할 예정입니다.

제 블로그의 글들은 대부분 사전에 알고 있는 지식을 쓰는 경우보다는 스터디나 실제 업무를 진행하면서 부딪히거나 힘들었던 내용들을 실시간으로 올리면서 작성됩니다. 그래서 잘못된 내용이 올라가기도 하고, 글이 완료된 후 퇴고 혹은 내용을 수정하는 경우가 종종 있습니다. 참고해 주세요. ^^;

이 글의 연재 목표는 아래와 같습니다. 

Google App Engine을 활용하여 게임 서버를 구축하는 것이며, 이를 위해 아래 내용들을 직접 제작/설정해 볼 예정입니다. 

- 유저의 게임 진행 데이터 저장 , 리더보드 제공

- 게임 이벤트 로깅

- 클라우드 플렛폼 활용법 

샘플 게임 클라이언트는 html5 Canvas를 사용할 예정이며, 클라이언트에서 사용될 코드들은 javascript로 제작할 예정입니다.

앞으로 연재되는 내용의 순서는 아래와 같습니다. 진행하면서 상황에 따라 변경될 수 있으니 양해 바랍니다. 주 내용은 이곳을 참고하여 따라갈 예정이며, 기존 내용에 제가 테스트를 진행하면서 발생하는 추가 내용들을 기록할 예정입니다. 

연재 순서

 1. Node.js로 App Engine 사용하기 - 들어가며... 

 2. Node.js로 App Engine 사용하기 - App Engine Hosting과 Managed VMs Hosting

 3. Node.js로 App Engine 사용하기 - Hello World with Node.js

 4. Node.js로 App Engine 사용하기 - 데이터 다루기

 5. Node.js로 App Engine 사용하기 - 인증

 6. Node.js로 App Engine 사용하기 - 로깅

 7. Node.js로 App Engine 사용하기 - Cloud Pub/Sub 서비스 시용하기

 8. Node.js로 App Engine 사용하기 - Cloud 설정하기

 9. Node.js로 App Engine 사용하기 - 게임 릴리즈 절차 정리

10. Node.js로 App Engine 사용하기 - 마무리 하며...

그럼 다음 글에서 뵙겠습니다. 

한 가지 핑계를 대고 넘어가야겠다. 어제 로깅 코드를 만들 때 모든 데이터를 event로 처리한 걸 기억하길 바란다. 사실 모든 게임의 로그를 이벤트로만 처리하는 것은 당연히 잘못된 방법이다. 하지만, 이 글은 Google Analytics와 Unity를 연동하는 과정을 설명하는데 목적을 두고 있다. 구글 애널리틱스에 적합하게 로깅하고 리포트를 분석하는 글이 아님을 밝힌다.(절대 몰라서 그런거... 맞음. --)

아마 대부분의 통계툴이 그렇겠지만, 데이터를 샘플링한다. 그래서 모든 데이터를 세세하게 보지는 못한다. 이번 테스트에서는 어제 게임 두 판만 했음. 팔이 아파서..데이터가 적기 때문에 추론하는 방법만 간단히 언급하겠다.

이제 본론 시작!!

데이터 조회는 보고서 속성에 설정한 시간대에 정리가 된다. 1일마다 리포트되며, 필요한 경우 아래 화면에서 변경 가능하다. 

금일 업데이트 되어 어제 테스트 한 내용을 검토해 볼 수 있게 되었다. 어제는 모든 데이터를 event로 처리했으니,  좌측 메뉴에서 "방문 형태" -> "이벤트" -> "인기 이벤트"로 먼저 가보자. 그럼 아래와 같은 결과를 볼 수 있다.

이전에 목표로 잡았던 총 세 가지 지표를 검토해 보자. 

1. 몇번째 스테이지에서 좌절하는가.

 : Category "game" -> Action "gameover" -> Label "last day" 로 설정했던 값을 검토해보자.

(* 순 이벤트 수란 : 한 세션 기준으로 첫 행동만 기록되는 이벤트의 합계. 즉, 어제 나 혼자, 게임을 두번 했는데, 하나의 세션이었으니, 그 중 첫번째 게임의 데이터를 말한다. 이벤트 값은 10. 두번째는 99판까지 갔다능...)

총 두번 플레이 되었으며,  순 이벤트 수 기준으로 이벤트 값은 10. 이를 통해 유저들은 평균 day 5 플레이 한다는 말도 안되는 결과를 알 수 있다. (모수가 많다면 우리 모두 공감할만한 결과를 얻을 수 있다. 지금은 그냥 패스 --a) 

2. Food의 획득, 이동 시 사용하는 량, 좀비에게 타격받아 소비되는 량

 : Category "food" -> Action "loss","get" -> Label "move","attacked","food","soda"  로 설정했던 값을 검토해보자.

Label 기준으로 본 화면이다. move, attacked는 loss, food, soda는 get action의 값이니 참고하자.

게임에서 이동 시 소비되는 food는 1이다. 평균값이 1인걸 확인할 수 있으며, 총 이벤트수는 90%에 육박하고 있는 걸 볼 수 있다. 그에 비해 attacked는 총 3.91%로 미비하다. (좀비가 우쉽나?)  좀비의 무서움을 더 알릴 필요가 있겠다. 

획득은 food가 soda의 획득 비율은 비슷하다. action "get"을 기준으로 food와 soda를 비교해보면 각각 56%와 44%임을 알 수 있었다. (몰랐는데 뭘 먹으나 food 증가량은 10이었네 --a 모양만 다르고 효율은 같았구나.)

3. 각 스테이지 별로 몇 번 정도의 이동으로 클리어 하는가

 : Category "day" -> Action "clear" -> Label "total move"로 설정했던 값을 검토해보자.

 위 분류는 사실 목적에 알맞지 않은 설정이었다. label을 day 1, day 2 등으로 분류하여 각 day별로 이동 횟수를 볼 수 있게 했어야 했다. 혹시 4번째 글에서 소스를 받은 분들은 이 부분을 개선해서 테스트 해보면 더 좋을 듯. 

day 별로 구분되지 않은 건 아쉽지만, 평균 약 20회 이동으로 스테이지를 클리어 하는 결과를 볼 수 있다.

이상. Unity + Google Analytics 연동에 대한 글을 마친다.

블로그 자체를 개인 저장소로 생각하며 글을 올리다보니 실수가 여기저기 보이네.

가끔 와서 보시는 분들께 심심한 사과의 말씀을 ^^a

다들 행복한 하루 하루 되세요. ~ 

GameManager.zip

기반 준비는 다 되었다. 이제 실제 이벤트를 전송하고 그 결과를 어떻게 보는지 살펴보자.

이 전 글에서 공유했던 목표는 아래와 같다. 

1. 몇번째 스테이지에서 주로 좌절하는가

 : Game Over되는 시점의 Day 날짜를 전달하자.

2. Food의 획득, 이동 시 사용하는 량, 좀비에게 타격받아 소비되는 량

 : Food 나 Soda 획득시 획득량 전달

 : 이동할 때마다 1씩 소비됨. 이 정보 전달

 : 좀비에게 공격 당하면 10씩 소비된다. 이 정보 전달.

3. 각 스테이지 별로 몇 번 정도의 이동으로 클리어 하는가.

 : 각 스테이지가 클리어 될 때 총 이동 횟수 전달.

event parameter는 총 4개로 구성되며, string category, string action, string label, int value로 구성된다. 위 세 가지 이벤트를 위해 아래와 같은 분류를 만들자.

Category

"game" - 게임 전체에 대한 대분류

"day"   - 한 턴 끝날 때.

"food"  - 게임의 중요 요소, Food

Action

"clear" - 턴 클리어 시

"gameover" - 게임 종료 시

"get"   - 획득

"loss"  - 손실

Label

"total move" - 한 턴의 총 이동 횟수

"Last Day" - 마지막 day 

"food","soda" - 획득 시 구분되는 요소

"attacked","move" - 손실 시 구분되는 요소

관련된 코드는 첨부된 파일, GameManager.cs, Player.cs를 참고할 것!

테스트 한 실시간 그래프는 아래처럼 볼 수 있다.

Google Analytics에서는 이벤트 기록을 상세 분석하기 위해서는 하루가 지나야 가능하기 때문에 

리포트 상세보기는 내일 이어서 업데이트 할 예정

샘플 제작을 위한 게임 샘플은 2D Roguelike를 사용했다. Android를 기준으로 설명한다. iOS에 대한 내용은 다음 글에서 세팅과 관련된 내용만 다루도록 한다. 그 이외의 내용이 다르진 않으니..

트래킹을 위한 1차 목표는 아래와 같다. 

- 몇번째 스테이지에서 주로 좌절하는가

- Food의 획득, 이동 시 사용하는 량, 좀비에게 타격받아 소비되는 량

- 각 스테이지 별로 몇 번 정도의 이동으로 클리어 하는가.

Google Analytics 설정 절차

1. google 계정을 생성 후(기존 계정 사용 가능) https://www.google.com/analytics/에 로그인한다.

2. 애널리틱스 계정이 없다면 계정을 생성하는 폼이 출력될 것이다. 그곳에 원하는 대표 계정명, 속성명(속성은 프로젝트명과 동일하다고 생각하면 된다.)을 입력하면 아래와 같은 기본 화면을 볼 수 있다. 테스트를 위해 속성명을 "LogTest"로 명명함.

이제 실제 프로젝트를 세팅해보자. 

1. 빈 프로젝트를 만들고, Roguelike, googleanalyticsv3.unitypackage를 생성한 프로젝트에 Import한다.

2. Assets/Plugins/GoogleAnalyticsV3에 GAv3.prefab을 클릭하고, Inspector view의 내용을 채워준다. 

아래 내용만 채우면 테스트가 가능하다.

 Android Tracking Code : 속성의 추적 ID를 입력한다.

 Product Name : 제품명을 입력한다. 여기서는 속성값과 같은 "LogTest"를 입력했다.

 Bundle Identifier : com.YourCompanyName.YourProductName 과 같은 포멧으로 입력하여야 한다.

 Bundle Version : 원하는 대로.. 여기서는 0.1로 입력했다.

나머지는 기본값을 사용하겠다.

3. Project View에서 GameManager.prefab을 찾고, GameManager.cs에 아래 코드를 삽입한다.

public GoogleAnalyticsV3 googleAnalytics;

4. Project View에서 GameManager.prefab을 클릭하고, Google Analytics에 세팅했던 GAv3를 Project View에서 찾아 연결한다.

5. GAv3를 활성화 하기 위해 GameManager.cs에 아래 코드를 삽입하자.

void Awake(){

  .   

  .

  // Start Google Analytics 

  Instantiate(googleAnalytics);

  googleAnalytics.StartSession();

  .   

  .

}

void OnApplicationQuit(){

  googleAnalytics.StopSession();

}  

이제 세팅이 완료되었다. 

위 세팅은 일반적이라고 할 수 없다. "Google Analytics 연동하기 - 1. "의 설명과는 조금 다른데, 이 프로젝트의 중심인 GameManager의 특성 문제이니 참고하기 바란다.

다음은 실제 로그를 남기고, 구글 애널리틱스 리포트에서 결과를 보도록 하자.

(* 퇴고없이 바로 올리는 글입니다. 나중에 데모 진행하면서 스샷과 같이 올리며, 퇴고할 예정입니다.)

신규 에셋빌드 시스템에서 할 수 있는 것을 보여주는 에셋번들5.0 데모

Unity 5.0 beta21 이상의 버전에서 이 데모를 실행해 주세요.

상세설명:

1. TestScenes 폴더 아래에는 3개의 씬이 있다.

1. AssetLoader.unity 에셋 번들로부터 일반적인 에셋을 로딩하는 방법을 볼 수 있습니다. LoadAssets.cs 스크립트를 참고하세요. 

2. SceneLoader.unity는 에셋번들로부터 씬을 로딩하는 방법을 볼 수 있습니다. LoadScenes.cs 스크립트를 참고하세요.

3. VariantLoader.unity는 variant 에셋번들을 로드하는 방법을 볼 수 있습니다. LoadVariants.cs 스크립트를 참고하세요.

가상 에셋들로부터 같은 결과를 얻을 수 있는 AssetBundle variants를 사용합니다. 이 데모에서, 빌드를 합니다.

1. "variant/myassets.hd" AssetBundle 안에 "My Assets HD" 폴더

2. "variant/myassets.sd" AssetBundle 안에 "My Assets SD" 폴더

3. variant AssetBundle에 실제로 종속된 "variants/variant-scene.unity3d" AssetBundle 안에 "variant-scene.unity"

이 폴더들이 정확히 일치하도록 에셋을 만들어야 합니다. 

두개의 다른 AssetBundle안의 그 오브젝트들은  유니티 빌드 pipeline에 의해 인증된 같은 내부 ID들을 가지게 될 겁니다. 그래서 다른 variant 확장명들의 AssetBundles와 임의로 변경이 가능합니다.

이 demo에서는 ㅜㅇ리가 variants라고 부르는 hd와 sd라는 파일 확장명을 사용합니다. 당신은 LoadVariants.cs에서 variant를 변경할 수 있습니다. 

또한 활성화된 variant로 문제없이 AssetBundle을 어떻게 풀어보는지를 보려면 AssetBundleManager.RemapVariantName()를 참고하세요. 

주의 : AssetBundle variant는 Editor simulation에서 정상적으로 확인이 불가능합니다. 

2. 자동으로 종속된 AssetBundles을 다운로드합니다.

새로운 빌드 시스템하에서는, 단일 manifest AssetBundle안에서 종속관계가 있는 AssetBundles간에는 연결이 되어 있습니다. 그래서 실행 시, 모든 종속관계를 알 수 있으며, 기반 url을 통해 자동으로 종속된 AssetBundles를 다운받습니다.

더 상세한 내용은 demo의 AssetBundleManager.LoadDependencies()를 확인해 보세요.

3. AssetBundles 메뉴에는 3개의 메뉴 아이템이 있습니다. 

1. "Simulate AssetBundles"는 에디터에서 AssetBundle simulation을 컨트롤 하는데 사용합니다.

데이터 플레이 모드에서, 빌드없이, AssetBundles을 simulate 할 수 있습니다.

2. "Build AssetBundles"는 BuildPipeline.BuildAssetBundles()를 호출하면 되는데, AssetBundle UI를 설정해서 AssetBundles를 빌드합니다. 상세한 내용은 BuildScript.BuildAssetBundles()를 참고하세요.

3. "Build Player"는 지정한 폴더에 빌드된 AssetBundles를 "Application.streamingAssetsPath"에 복사합니다. BuildScript.BuildPlayer()를 참고하세요.

4. AssetBundleManager 클래스는 AssetBundle과 그에 종속된 것들을 로딩된 내용들을 가지고 있습니다. 이런 내용들이 포함되어 있습니다.

1. Initialize()

AssetBundle manifest object를 초기화 합니다.

2. LoadAssetAsync()

명시된 AssetBundle로부터 명시된 asset과 종속 관계의 모든 핸들을  로드합니다.

3. LoadLevelAsync()

명시된 AssetBundle로부터 명시된 scene와 종속 관계의 모든 핸들을 로드합니다. 

4. LoadDependencies()

명시된 AssetBundle을 위해 종속관계의 모든 AssetBundles을 로드합니다.

5. BaseDownloadingURL

의존 관계에 있는 것들의 자동 다운로딩을 위해 사용되는 base downloading url을 설정합니다.

6. SimulateAssetBundleInEditor

에디터 플레이 모드에서 사용될 AssetBundle을 설정합니다.

7. Variants

활성화할 variant를 설정합니다.

8. RemapVariantName()

활성화된 variant에 따라 올바른 AssetBundle을 풀어냅니다.(?)

5. Assets\ScriptsForAssetBundleSystem folder 아래의 스크립트들은 당신의 프로젝트에 쓸만할 겁니다. 당신의 프로젝트에 자유롭게 사용하시기 바랍니다.