DevFest Tokyo 2017
DevFest Tokyo 2017
日時
2017年10月9日 10:00〜17:00
会場
国際交流館(東京都江東区青海2-2-1)
主 催
GDG Tokyo, Shibuya.apk, DroidKaigi, 日本Androidの会, golang.tokyo, html5j, GTUG Girls, Women Who Go, XR 女子部, Droid Girls, Geek Women Japan, GCPUG, TFUG, TangoWG
スライド資料
聴講したセッション資料
- クラウドってなんだろ?クラウドを活かすアプリケーションの設計とは?
- 大半のウェブサービス/アプリは,Firebaseなら簡単で安いですよ
- Go徒然日記
- Goのサーバーサイド実装におけるレイヤ設計とレイヤ内実装について考える
- FirebaseAnalytics + BigQuery + DataStudio
- AWSとGCPのいいとこどりでつくる分析基盤のきほん
他セッション資料
- GCP パネルディスカッション
- FirebaseとReact Nativeでのモバイルアプリの作り方
- GCPではじめるかんたん機械学習
- React Nativeアプリをリリースし続けるために、最初に行う8つの取り組み
- deeplearn.js入門
- TensorFlowで趣味の画像収集サーバーを作る
- Android Things+TensorFlowで作る猫トイレ監視システム
- FlutterでAndroid/iOS両対応のアプリ開発
- BlockChain on Go
- Go1.8 for Google App Engine
- Android Studio 3.0 profiler ハンズオン
- Android Studio 3.0 ハンズオン : LayoutEditor & ConstraintLayout
- Instant Apps or Progressive Web Apps
- Android 1.5 - 8.0 Walk through - Retro/Prospective Android Application Development
- Android1.5~8.0 Walkthrough
クラウドってなんだろ?クラウドを活かすアプリケーションの設計とは?
October 9 Session / 10:40 - 11:20 / 会議室2/ Japanese
GCPUG Tokyo Organizer
メルカリ/ソウゾウ
@sinmetal
https://goo.gl/X54o2S
クラウドってなんだろ?
- データセンター上に存在するハードウェアリソースをAPIを利用して動的にリソースを借りることができる仕組み
- 柔軟に迅速にリソース提供を受けることができる
- 料金はだいたい従量課金制
- 使ったリソースの料金を払う
- スモールスタートに適している
クラウドの利点
- H/Wを調達するイニシャルコストがかからない
- H/Wをリプレースする必要がない
- いつでもマシンリソースの構成を変更できる
クラウドのレイヤー
- SaaS(Software as a Service)
- イメージは「部屋を借りる」
- OS、ハードウェア、ネットワーク、ミドルウェア(DB等)、アプリケーション
- PasS(Platform as a Service)
- イメージは「家を借りること」
- OS、ハードウェア、ネットワーク、ミドルウェア(DB等)
- DBaaS(Database as a Service)
- FaaS(Function as a Service)
- IaaS(Infrastracture as as Service)
- イメージは「部屋を借りること」
- OS、ハードウェア、ネットワーク
クラウドは壊れないのか?
クラウドを活かすには?
リトライ
- 間にネットワークが入れば、エラーは起こる
- 色んなレイヤーでリトライする
- クラウドのサービスにはレプリカが存在するものが多い
- 1つ壊れても、他のものたちが応えてくれる
- アプリケーション側で適切なタイムアウトを設定して、リトライする
冪等性
- リトライ時に複数データを作成してしまわないように冪等性を考える
- アプリケーション側で同じキーを生成して同じ場所に上書きするようにする
- すでに更新されていたら、処理をスキップする
リクリエイト
- 複数インスタンスを用意しておく
- 自分のアプリケーションが0台にならないように
- 起動にかかる時間を短くする
- なるべく早く役割を果たせるように
- 状態はなるべく持たないようにする
- メモリは消し飛ぶので、状態はなるべく外へ
- 役割を小さくして、初期処理を少なく
- クラッシュした時の影響範囲を限定的に
パフォーマンス
非同期処理
- 同期的に処理する必要がない処理は非同期に処理したほうが安くパフォーマンスを上げれる
- 非同期処理はQueueのサービスが便利
- GCPだとCloud Pub/Sub,App Engine Task Queueがある
- Queueを挟むことで、処理の粒度でWorkerを分離できる
- Workerのマシンスペックを変更できる
- Workerの生成タイミングを遅延できる
- Taskの管理をQueueがしてくれる
- 非同期処理、分散処理をする時に気を付けること
コンパクトな環境
- 必要なときに必要なリソースを用意するには
- Container
- Docker
- Borg(Google内部のみ)
- Binary
- Go
- Container
高速なネットワーク
- 分散したタスクの分配や、コンテナの配備のために、高速なネットワーク
めんどうだったら
- GCPのフルマネージドサービスにある程度任せる
- App Engine
- BigQuery
- Cloud Dataflow
Google App Engine
- Web ApplicationのためのPaaS
- 非常に高いスケーラビリティ
- デフォルトでオートスケール
- Versioning
- Task Queue
Google BigQuery
Google BigQueryがなぜはやいのか?
- データを元に分割して大量のHDDに保存している
- クエリ実行時に動的に数千台のインスタンスを起動する
Google Cloud Dataflow
- パイブライン処理をフルマネージドで行うサービス
- バッチ処理、ストリーミング処理、どちらも可能
- Java or Python SDK(Apache Beam)
- BigQueryではやりにくい処理を任せされる
大半のウェブサービス/アプリは,Firebaseなら簡単で安いですよ
October 9 Session / 11:30 - 12:10 / 会議室1/ Japanese
神楽坂やちま yati.ma/qi
https://speakerdeck.com/yatima/apuriha-firebasenarajian-dan-dean-idesuyo
Agenda
- ざっとFirebase全体像
- dbについて
- 概要
- コスト
- よくある誤解、苦手なこと
Firebase
- オールインワン
- 細かい融通は聞かないことも
- PC用webにも使用できる
開発コア系
realtime database
- クライアントと直接
- オフライン対応
- リアルタイム
- ダウンロード 1ドル/GBなど
Hosting
- htmlなど置いておく
- httpsにも対応
- 簡単に戻せる(バージョン管理)
- ダウンロード 0.15ドル/GBなど
Cloud Storage
- 写真、音楽なのでメディア
- ネット状況に応じ一時停止・再開
- ダウンロード 0.12ドル/GB
Could Functuion
- サーバー側の処理をサーバー管理なしで
- サーバーの性能、更新を考えなくて良い
- サーバーの更新を考えなくていい
- 1GHz 24h30dで約20ドルなど
便利機能
Authnetication
- セキュリティなログイン機能
- 他サービスとの連携
- アクセス可否など
- 電話認証のみ 0.06ドル/アカウント
Cloud Messaging
- 通知を飛ばせる
- 優先度、有効期限
- 無料
Dynamic Links
- アプリ内への直リンク
- 特典の提供
- ユーザー同士でのコンテンツ共有
- 無料
Invites
- Dynamic Links上
- メールなどで知人に招待
- 無料
監視系
Analytics
- 多数の広告サービスと連携
- BigQueryとも
- 無料
- web:Google Analytics
Crash Reporting
- エラーの優先順位
- グループ化
- メール通知
- 無料
- web:Stackdriver Error Reporting
Performance Monitoring
- ネット状況も把握できる
- 無料
- web:(Stackdriver Trace)
テスト系
Test Lab for Android
- 既存環境と容易に統合
- テストコードなしでも
- 1or5ドル/聞き/時間
- web:なし
Remote Config
- アプリを更新なしで変更
- 日替わりセール
- ユーザそうにより異なるUI
- 無料
- web:Google Optimize
広告系
App Indexing
AdWords
- 広告を出す側(宣伝)
- 検索広告、ディスプレイ広告、動画広告
- Analyticsで定義した条件宛、も可
AdMob
- 広告を貼る側(収入)
- バナー広告、動画広告、画面遷移遷移時の広告
- コンテンツそっくり広告
realtime database
Firebaseは真の「サーバレス」!
Firebaseは複雑化しにくい!
Cluod Firestore
Cluod Firestore
- おおむねrealtime databaseと同じ
- そこそこクエリ使える
- とても落ちにくい
- realtime databaseの約1/10の値段
「realtime databaseは高価」
- 前述してきたように
- 総合的には安くあがる
「検索使えない」
- 検索がほぼ使えないのは確か
- しかしAlogoliaというサービスと連携できる(公式サンプルもあり)
「フィルタ使えない」
- フィルタは工夫で結構いける
- Firestoreならクエリもあるし
「落とし穴があるはず」1
- 情報はまだ少ないのは確か
- 今後に期待
「落とし穴があるはず」2
- データ量は普通より消費しやすい
- 「時間と空間のトレードオフ」みたいな処理を減るので開発の手間も減る
「すこしずつ切り替えよう」
- 辞めた方がいい
- シンプルにできるという強みが活きない
- むしろ相性の問題で裏目に
- 使う時は一気にするべき
(web)使うならAngular?
- 確かに公式はAngularを推すけど...
- Angularは重厚長大
- Reactは学習コストが
- Vueがちょうどいい
FiVeスタック!
- Firebase + Vue
- 相性もいいし
- Vue単体としても良い
- 学びやすい
- 拡張性など公式で対応
苦手なこと
一部の企業・研究向けアプリ
- 基本的にざっくり感
- クエリも貧弱(Firestoreなら改善)
- 厳密さ重要ものには不向き
FPSや格闘ゲームなど
- 遅延少なめではあるがめちゃくちゃ少ないわけでもない
- 通信遅延が致命的なアクションゲームも不向き
Go徒然日記
October 9 Session / 13:20 - 14:00 / 会議室3/ Japanese
Women WHo Go Tokyo
https://speakerdeck.com/mom0tomo/gotu-ran-ri-ji
1年くらいかけてGoでどんなことをしてきたのか
Agenda
- はじめてのプログラミングGo
- やってみたからのプロダクト導入
- Goでやっていき宣言
はじめてのプログラミングGo
よかったところ
- 公式ドキュメントを読むようになる
- Go Docを見るようになった
- Goで書かれているので読める、勉強になる
- 型を意識してコーディングできる
- OSや低レイヤーを意識できる
- 活発なコミュニティがいくつもある!
難しかったところ
- 習得に時間がかかる
- 出来る人がすごすぎる
- 新しい言語なので、先駆者として導入している企業・エンジニアの皆さんが錚々たる顔ぶれ。
- 身近にロールモデルとする人を見つけにくいかも。
やってみたからのプロダクト導入
こんなことやりました
よかったところ
- デプロイがとにかく楽
- コンパイルが早い
- こう書くのが良い!がはっきりしている言語なので、Issueを受け渡しやすかった。
- 低レビューコスト
- interfaceのおかげでレガシーで謎のデータ構造を目の前にしても扱える安心感
懺悔
- No CI No Life
- buildしてデプロイするまでの仕組み化をやらなかった
- ユーザーいじめ問題
- 一括更新等を行った際に大量のプルリクエストが...悪
- Gopher少ない問題
- 新しく取り組む言語なのだから、もう2名くらいプログラマーを巻き込めばよかった。
Goでやっていき宣言
やっていきたいこと
Goのサーバーサイド実装におけるレイヤ設計とレイヤない実装について考える
October 9 Session / 14:10 - 14:50 / 会議室2/ Japanese
https://www.slideshare.net/pospome/go-80591000
Agenda
- レイヤとは?
- レイヤ設計について
- レイヤ内実装について
なぜレイヤーが必要なのか?
- コードの依存関係を整理できる
- レイヤ間の差し替えを担保することができる
- レイヤ内のパッケージ凝集度を高めることができる
どういうレイヤ設計が適切なのか?
- 世の中には色々あるが、大体どれを採用しても以下は担保される
- モデルはどのレイヤにも依存しない
- にたような責務を持ったレイヤがある
- 各レイヤ間の依存が単一方向依存になる
レイヤ内実装については以下の資料
https://www.slideshare.net/pospome/go-80591000
FirebaseAnalytics + BigQuery + DataStudio
October 9 Session / 15:00 - 15:40 / 会議室2/ Japanese
https://www.slideshare.net/ssuser8463f8/firebaseanalyticsbigquerydatastudio/1
Agenda
- Firebase Analyticsって?
- BigQuery Export
- DataStudio
Firebase Analyticsって
- アプリにFirebaseSDKを導入するだけで、自動的にある程度のデータを収集してくれる
- 自分で収集するイベントを設定することもできる
- データの収集はイベント単位
- 他のサービスとも統合出来る
- BigQuery
- Firebase Crash Reporting
- FCM
- Firebase Remote Config
- Google タグマネージャ
BigQueryの仕組み
- The 12 Components of Google BigQuery
- 重要なコンポーネント
- Dremel(クエリエンジン)
- Colossus(ストレージエンジン)
- Jupiter(ネットワーク)
- Borg(大規模コンテナ・クラスタ管理)
サーバレス・サービスモデル
- 完全なサーバレスモデルである
独自のストレージエンジン
- Colossus
- Capacitor
- カラムナーストレージフォーマット
- データの最適化(並び替えなど)
- テーブルパーティショニング
- Poseidon
Dremelというクエリエンジン
独立したストレージとネットワーク
- Jupiterネットワーク
- Googleが独自に開発したネットワーク(H/W,S/Wともに)
- 1Pb/secの帯域
- ストレージはネットワークで接続
費用について
- クエリ課金
- クエリ毎にりようしたカラムに対するデータ容量で課金
- 月額固定料金
- ストレージ課金
- データ容量に対して課金
- 90日以上変更のないテーブルはデータ容量に対しての課金が半額
- ストリーミングインサート
- バッチでInsertするのではなく、1行ずつ個別にいれるデータ量に対して課金
- https://cloud.google.com/bigquery/pricing?hl=ja#transfer
IAMと認証、監査ログ
- Google CloudのIAMと権限の連携
- DataSet単位での権限付け
- 認証はO-Authとサービスアカウント
- 全ての操作を監査ログで保存し、BigQueryへExportも可能
BigQueryの制限事項
BigQuery Export
- ユーザー単位で行動ログ(JSON)がBigQueryにExportされる
- RealTimeExport(間隔は20分)と1日1回のExportの2つがある
- Blazeの契約が必要
それで何が嬉しいの?
- そもそもそんなデータ作るのめんどい
- 他のデータと行動データをくっつけることが出来る
- 持ってるアプリのデータ
- Adword,DCM,YouTubeのレポートなどなど
DEMO
DataStudioとは
- 簡単にパワポに数値を埋め込むことが出来るツール
- リアルタイムにデータを取得することが出来たり
- BIツールの超簡易版(Tableauみたいな機能はない)
DEMO
- リアルタイムに表示出来る
- 会話しながらお絵かき出来る
- Googleのサンプルを分解出来る
- 無償でお絵かきできる
私たちクラウドのこんなところが好き
October 9 Session / 15:50 - 16:30 / 会議室3/ Japanese
https://speakerdeck.com/chie8842/awstogcpfalseiitokodoridetukurufen-xi-ji-pan-falsekihon
クラウドフル活用で大規模分析基盤を超短期間で構築した事例を共有
今日話す範囲
進め方そのものの話アプリレイヤの話- 基盤レイヤの話 ← ここの話をします
そもそも分析基盤とは?
- データを蓄積・活用するための基盤
- 分析基盤
- 施策への評価
- アドテク
- レコメンド
- 分析基盤
もともとあった分析基盤の課題①
もともとあった分析基盤の課題②
- マスタデータは別のDBにある
- マスタデータと突合して分析したい場合は 別の環境にデータを移す必要がある
- joinしたカラム同士でデータ型が異なる
もともとあった分析基盤の課題③
新しい分析基盤に求められるもの
- 分析者にとって使いやすい
- 追加開発・運用がしやすい
- 列変更等が柔軟にできる
- 複雑なETL処理に柔軟に対応できる
- コスト(イニシャル/ランニング)が現実的である
- スケーラブルである
作った分析基盤
- EC2(fluentd) → Kinesis → S3 → EMR(Spark) → S3 → EC2(embulk) → BigQuery(GCP)
- RDS(MySQL) → EC2(embulk) → BigQuery(GCP)
- BigQueryへデータを集約した
- 分析者、プランナーはtableauを使用してBigQueryへ
- S3 → データレイク
- EMR(Spark) → データ加工ツール
- BigQuery → DWH・DM
データレイク:S3
- 非構造化データの保存
- サービスの動いている環境(AWS)に近い場所にデータを保持するほうが都合がよい
- ネットワーク転送コスト
- 管理しやすさ
- 同じバケット内でもプレフィックスやタグを利用した柔軟なライフサイクルの運用
- Kinesis Firehoseを利用することでかんたんに日時ごとにディレクトリを分けて保存できる
DWH・DM:BigQuery
- 分析者にとって使いやすい
- StandardSQLが利用できる
- UDFやWindow関数も使える
- スプレッドシートやpandas dataframeとの連携
- 後のテーブル設計変更がしやすい
- テーブルへの列追加ができる
- 安定したレイテンシとスループット
- メンテナンスフリー
- 時間課金でなくクエリ課金
- RedShiftやAthenaを使う場合に比べて、AWSからGCPへのデータ転送が発生するが運用コストの削減で相殺できる範囲だった
EMR(Spark):データ加工
- サービス側のログ設計の関係で、以下が必要だった
- 不要なログ出力が全体の9割占めているため、BigQueryへ転送する前にフィルタ処理
- SQLで表現できない飛行増加データに対する複雑なETL処理
- ログが増大してもクラスタ台数をふやすことでスケールできる
- SQLで済ませられるものはBigQuery上で加工
使われる分析基盤構築のコツ
- 早く作っても長くつかえないものを作っても意味がない
- DWHの場合、基盤部分は「作って壊して」が簡単にはすまない
- 基盤部分は慎重に決めた
まとめ
用語説明
- データレイク
- 加工前の生ログを保存する場所
- DWH
- 分析しやすいように加工されたデータを格納するデータベース
- DM(データマート)
- 分析用途に応じて集計後のデータなどを格納するなど、サンドボックス的につかうためのデータベース
- データ加工ツール
- ログを分析しやすい形に整形するツール
- ワークフローエンジン
- 一連のデータ処理のフローを管理するツール
TableauServerにデータソースをパブリッシュする方法について
TableauDeskTop
TableauServer(10.1)にデータソースをパブリッシュする方法(抽出)
- TableauDeskTop(10.1)を開く
- Amazon Redshiftに接続
- 接続を「抽出」にしてデータソースを作成
- シートへ移動してワークブックを保存する(この際にデータ抽出が作成されるみたい...)
- メニューの「サーバー」→「データソースのパブリッシュ」する
TableauServer
スケジュールによる定期実行
- adminユーザーでログインする(一般ユーザーだと新しくスケジュールを作成できないので注意)
- メニューの「スケジュール」→「新しいスケジュール」を作成
- タスクのタイプは「抽出の更新」を選択する
- 頻度等は適宜選択をする
- メニューの「コンテンツ」で対象のプロジェクトを選択する
- タブの「データソース」を選択し、更新したいデータソースを選択する
- タブの「更新スケジュール」を選択し、「新しい抽出の更新」を選択する
- 上記で作成した更新のスケジュールを選択する
CEDEC2017
開催日
- 2017/8/30(水)~2017/9/1(金)
開催場所
- 横浜パシフィコ
目次
- Shadowverseにおける「デッキのトレンド分析」を題材としたデータマイニング技術の活用手法紹介
- クラウド時代の長く効率よく運用するためのゲームサーバとインフラ設計
- 無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化
- 「乖離性ミリオンアーサー」VRリメイクにおけるUIの最適化
- 一周年で爆発した「逆転オセロニア」における、ゲーム分析の貢献事例 〜開発・運営の意思決定を全力でサポートする、DeNAのゲーム分析体制〜
- 遺伝的アルゴリズムによる人工知能を用いたゲームバランス調整
- クラウドの分析システムを活用したアクセスログにもとづくリアルタイム不正ユーザBANシステム
- 分析業務をブーストするBIツール活用術
Shadowverseにおける「デッキのトレンド分析」を題材としたデータマイニング技術の活用手法紹介
開催日
- 2017/8/30(水) 11:20 〜 12:20
開催場所
- 横浜パシフィコ 503
登壇者
- 鈴木 貴都氏(株式会社Cygames)データアナリスト
- 草野 友弘氏(株式会社Cygames)サーバーサイドエンジニア
展開内容
- 使用デッキ流行の推移について
分析手法や直面した問題点、そこから得られた知見についての話を展開
所感
- cygamesでのデータ分析はかなり高度なレベルにいっている印象
- クラスタリング(kmeansとk-medoids)について話されていた
- k-meansは外れ値に弱いという性質
- k-medoidsは外れ値に強いという性質
- 分析手法の特徴をよく理解することが大事である
- ゲームの特性に合った分析手法を選択すること
- 機械学習とか流行っているが、結局のところ、何を変えたらどうなるのかが分からないと意味がない
- クラスタ数とコアとなるカードが時間経過とともに変化していく
ソーシャルゲーム業界で分析対象となるデータ
- KPI
- 売上額、DAUなど業績を評価するための指標
- KPI分析の特徴
- 目的変数が明確
- 分析事例が多い
- 今までソーシャルゲーム業界で分析の中心として語られていた
- 行動ログ
- 対戦情報、アイテム獲得ログなどのゲーム内行動のログなどのゲーム内行動の行動ログ
- 行動ログの特徴
- ログ形式が分析前提でない
- ゲーム知識が最重要
- 分析コストが高い一方、ユーザーのゲーム体験を向上
デッキのトレンド分析
- デッキトレンド分析が重要視されている理由、具体的な分析手法について紹介
「Shadowverse」とは
- スマホおよぼPCで展開される対戦型オンラインTCG
- 対戦における「進化」システムによる戦略性が最大の特徴
- 2017年8月時点でカードの種類は800種類以上存在
- 7種類のクラスが存在し、自分だけのデッキを構築できるのが魅力
デッキトレンド分析
- カードパックの追加 3ヶ月に一度のペースで新弾カードパックとして100枚ほどの新カードを追加している
- ユーザーが飽きないように工夫
- 社内のTCGプランナーがカードバランスの調整
- 強さの調整を事前に検証している
- 既存カードとのシナジーについて検証
- カード開発のポイント
- プロジェクト内部で調整&検証を十分に行った上で実際のプレイ動向を調査し、反映する必要がある
デッキ環境の重要性
- 有利・不利の関係サイクルで遷移するとユーザーの使用するデッキが固定化されにくくなる
- いろんなデッキのユーザーと対戦できることで新鮮味が損なわれず長く楽しめる
- 一方で、幅広いデッキに対して有利なデッキが生まれると、ユーザーが使うデッキが固定されやすくなる
- 同じようなマッチングしか生まれないため飽きを早めてしまう
デッキ環境の推移の推定
- ユーザーはどういうデッキを使用しているのか?
- どのようなタイミングで主流デッキが推移していくのか?
分析の要件定義
- 目的
- カードの開発調整に役立つ、現在のプレイ環境が把握できるような客観的な情報が欲しい
- 使用可能な情報
- 「Shadowverse」における全対戦データ
- アウトプット
- 各デッキグループの「使用率」「勝率」「構成カード」とこれらの推移
分析の流れ
デッキのグループ化
問題となったこと(1)
- 手法の特徴を理解していない
- k-meansが外れ値に弱いという性質があることを理解していなかった
- 平均というパラメータを使うみたい
- 「Shadowverse」では、強いデッキを重視するユーザーの他にも
コンボがきまった時の爽快感など、プレイ感を重視したデッキを使用するユーザーも存在する
これが、k-meansの性質と合わないため正確な結果が得られない - 対策内容
- k-meansと非常に近いが、クラスタの中心点がデータ点そのものになるk-medoidsという手法
- k-medoidsは、外れ値に強い性質をもっている
問題となったこと(2)
- ゲーム特性に合ったチューニングをしていない
- デッキ間の距離について考えていない
- k-medoidsを適用するためにはデータ間の距離を定義する必要あり
- デッキが近い/遠いということがどういうことなのかを説明
デッキ間の測り方
k-medoidsでは、指定がなければユークリッド距離というものが適応される
Shadowverseでは、デッキが等しい状態になるためにカードを1枚追加/削除するという行動が
何回必要かで距離を測る「デッキ編集距離(マンハッタン距離)」を採用している
分析手法選択で大事なこと
- 手法の特徴をよく理解する
- ゲームの特性に合った手法を選択すること
- 手法とその結果を理解し、対象となるゲームにとって結果を解釈しやすい手法を選択することが大事
クラスタ数の決定
- k-meansとk-medoidsに共通する問題点
kをあらかじめしておく必要がある - ゲームの特性・データの特徴に合わせて「kを大きめにとっておき、後から絞り込む」と言う方法を実施
コアカード抽出
- デッキを区別する際には
- コンボの鍵となる(複数・単数)カード
- フィニッシャーとなるカード
- 他のデッキにはふくまれていないカードがそのデッキの特徴を表していると仮定
- カードのレアリティ
- 新しい能力など、デッキ構築において重要な意味を持つ「レジェンド」「ゴールド」の2種類をコアカードとして抽出
- 特徴を代表する点と考えるにはリスクが大きい
- メドイドではなく、メドイドに近い点の平均を取ることに。
クラスタのマージ | 階層クラスタリング
階層クラスタリング
- 距離が近いデッキ = 採用しているコアカードが似ているデッキを一つのクラスタとしたためこの手法を採用
同じコアカードを使用しているという分類を距離によって決めたいため、
ここではクラスタ数を事前に決めないという特徴がある「階層クラスタリング」という手法を採用
クラスタ数決定問題のまとめ
- ゲームの特性を元に独自の手法を開発
- 分析を行う上で重要な特徴量設計を行うためには、分析対象に影響を与えているものは何かを考える
クラスタの推移 | 抽象化
- クラスタ数とコアとなるカードが時間経過とともに変化していく
クラスタの推移 | 解決策 - 1
クラスタの推移 | 解決策 - 2
実際の運用へ向けた今後の課題
- レアリティ以外の特徴量の抽出
- 実際のバトルのプレイデータも分析してよりコアに近いカードの条件を見つける
カード調整に有用な可視化
- TCGプランナーが膨大な情報量を瞬時に把握し、カード調整に活かせる可視化手法
何ターン目に何のカードがプレイされたか、前後に使用されたカードは何かなど
プレイデータの分析が進めば、より精度の高いクラスタリングが可能になる。
まとめ
- データマイニングで大事にしていること
- ユーザーの行動ログを分析すること
サマリー
- 手法の特徴をよく理解しゲーム特性に合った手法を選択
- 多種多様なデッキが存在するため、頑健性が高いk-medoidsを採用
- 手法とその結果を理解し対象となるゲームにとって結果を解釈しやすい手法を選択
- デッキの編集行為とマッチングした距離指標を選択
- 分析を行う上で重要な「特徴量設計」を行うためには分析対象に影響を与えているものは何かを把握する
- ゲーム内での意味づけを利用した上で適切な特徴量を設計
クラウド時代の長く効率よく運用するためのゲームサーバとインフラ設計
開催日
- 2017/8/30(水) 13:20 〜 14:20
開催場所
- 横浜パシフィコ 502
登壇者
- グリー株式会社 堀口真司氏
資料
所感
- GREEでのインフラについての話
- オンプレでの簡単な説明について
- 基本的なLAMP環境とスケーリングの話
- スケール以外の厄介な問題
- Jenkinsはバージョンアップが激しく同じ状態に戻らないとか...
- GREEではゲーム開発はPHPが多いみたい
- HTTP以外のプロトコルの台頭
- サーバー構築は、couldformation等を使用する
- 自動化にはchef、ansibleを使用する
- 設計当初から、AutoScalingを意識してアーキテクチャを考える
クラウド環境での運営タイトル
- 消滅都市2
- ららマジ
- 武器よさらば
- アナザーエデン
- 他多数
インフラとは
- インフラは安定していることがあまり前
- 普段は存在を意識しない
サービス運営型の割合
- ゲームもサービス運営側の割合が増えてきている
存在が気づかれないぐらい何事もないのが当然
- でも色々な問題が起こる
オンプレのころ
- 自分でサーバー機材を買って、データセンターを借りて設置
Data Center
- 供給電力
- 冷却能力
- 効率配置
Rack
- 目的のデータは短距離で
- switch
- web-server
- database
オンプレは巨大で硬いネットワーク
- どこからどこへでもIPレベルで疎通する
- モノリシックな傾向になりやすい
モノリシックなサービスとは
- 全てのサーバが同じ仕事をできるようにすると効率が良い
おさらい
- LAMP環境とスケーリングの話
- リクエストを捌く流れ
アクセスが増えてくると詰まる
- HTTPワーカー
- ワーカー処理は新しいリクエストを処理できない
ワーカーを増やし、並列非同期処理にする
スケーリング(10~)
- スケーリング(100~)
- スケーリング(1000~)
大きくなると変わるところ
- 障害のダメージ
- 全体変更時間の増加
- 独自運用ツールの依存性
厄介な問題
- スケール以外での厄介な問題
負荷以外の障害
- データを保持するサーバーなどが壊れた時
- ディスクの蓄積ダメージ
- 電源、ネットワーク
- スイッチ
- 大規模障害になりやすい
- Jenkinsが壊れた時
- バージョンアップが激しく同じ状態に戻らない
- バッチや集計処理用のサーバー
- 色々なデータやジョブを保持している
ほかにも良くある障害
- ログ等でディスクいっぱいになる
- 容量だけでなくinode枯渇も良くある
- 調査・削除は高負荷になりやすく、対応に時間がかかる
- メモリ逼迫
- 利用者増加や時間経過による曲線系の何か
外部からの攻撃
- DDoSやBOTなど
- ゲームの解析
長期運用のほころび
組織の構成
- インフラ
- エンジニアが多く、他にも会計処理や組織管理など
サービスの特徴ごとにチームを組んで対応している
- エンジニアが多く、他にも会計処理や組織管理など
ゲーム開発者とざっくり調整
- スケジュール共有
- 使用する言語やライブラリ等
- ログの取り方と解析方法
- デプロイ方法
- セキュリティ関連
社内で使用する言語
気になるパフォーマンスと費用の関係
- 全体のバランスを見て費用最適化していくべき
並列処理
非同期処理
- node.js
- イベントドリブン系
- prefork系の逆の特徴
- マルチコアを使いきれない
- コネクションプール
プール系はスケールが難しい
- 秒間1万コネクションに近くなったら考える
- 利用言語の特徴やミドルウェアとの相性をよく考える
よく使われるバックエンド
細かいことはいいので、特徴で選ぶ
- 簡単に扱えるのか
- 性能はお金でなんとかなる
シャディングの扱い
- 垂直・水平シャーディング戦略は相談しよう
- 偶数または奇数で分割
- ワールド分割
キャッシュ系のスケール
- キャシュをスケールアウトさせるときは用途に注意
- スケールは一瞬で終了しないので一貫性が崩れる
- 切り替えで問題が起こるケース
ログの種類
- OSが出すログ
- ミドルウェアが出すログ
- アプリで出すログ
消えて困るものは転送する
- 他サーバーへ転送する
回収・転送する方法
- クローリング
- 実装がシンプルで、プロトコルやフォーマットに依存しない
- 大量のテキストログ解析に超時間がかかる
- クロールが間に合わなかった分は障害に消える
- fluentdを使った転送
- 送り口(受け口)がたくさんあって、分析サービスを使い分けられる
- 送り方も柔軟
- 雑な運用に耐えられる
- 特殊なサービスを利用
- DBにいれておく
- 列を決まられるなら使いやすいかも
- 分割の戦略が大切
- 要件の共有も
デプロイ
- サーバーで動作しているアプリのコードを最新のものと置き換える
- 課題もある
- 無停止でできるのか
- 一貫性のある動作になるか
- ロールバックはできるか
- デプロイ速度は十分か
- 切り替え方法は適切か
- キャッシュの揮発に影響は問題ないか
無停止とは
- サービス全体が止まらないこと
一貫性のある動作とは
- シンボリックリンクの切り替えが主流
ロールバック・テスト環境
- あまりないみたい
- いきなり本番環境にデプロイするのではなく、テスト環境にデプロイしてよく確認してから行うと問題が少ない
デプロイ速度について
- ロードバランサーから解除、更新、登録は時間がかかる
- 一台のサーバーから複数のサーバーに転送していくのは時間がかかる
- 千台クラスになると、中継サーバーに転送してから、さらにデプロイ等で加速
- 一度S3等にアップロードしてから、全サーバーへダウンロード
- 早すぎてもダメ
- Webサーバーに瞬間的に高い負荷がかかり、性能が落ちる
死活監視
- ログにERRやFAIL等の危険な文字列がないかを定期的に検索
リソース監視
- Grafanaというツール
- Prometheusという時系列DBを使用
- CPU利用率やメモリ量
- OSやミドルウェアごとの細かい値
- 同じ役割のサーバーを平均値だけでなく全部表示させることで、一台だけの現象かどうか分かる
クラウドでは
- WebConsoleでサーバーを構築できる
ゲームの設計はどれもだいだいおなじ
- 使うサーバー
- それぞれの用途に特化したサービスがある
ハードウェア関連
- 機材の手配が不要
- 障害は起こるので、対策は必要
- 目的に合わせた組み合わせを選ぶ
- CPU重視、メモリ重視、ディスクは永続的に必要か
DB関連インスタンス
クラウドはソフトウェアで管理できる
- アプリケーションを書くことに集中できる
サーバー構成のデータ化を狙う
仮想化イメージの作成
- Packerというツールを使用してイメージの生成
Dockerを使った管理
- コンテナ技術を駆使してOSまるごとパッケージ化できるツール
需要の増減には自動化で対応
- AutoScaling
- 負荷が高くなったらサーバー増えて、低くなったら減る
- 設計当初からAutoScalingを意識してアーキテクチャを考える
ゲームのアクセス数は急激に変わる
- スケジュールはインフラでは把握しにくく、ゲーム運営側にお任せ
これからの見通し
- GREEの見解について
増えるサービス
運用のソフトウェア化
- 自動化しやすくなった
- 自動化のための開発が必要になってきた
ゲームらしいアプリの増加
まとめ
- 自動化とデータ化を常に考えておきましょう
無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化
開催日
- 2017/8/31(木) 11:20 〜 12:20
開催場所
- 横浜パシフィコ 502
登壇者
- 阪上 直樹氏(株式会社セガゲームス)
- QAエンジニア
自己紹介
- 元々ゲームプログラマ
- アプリ側にも手を入れる
「if DEBUG」内なので製品に1行も入らない
- ゲームプログラムを直接いじれる
- QAエンジニア(Embedded QA)
所感
- ゲームプレイ中の入力をパスリストに変換して、Elasticsearchにデータを格納させて
オートテストでパスを再生しているという知見を得ることができた。 - どこでもログ送信の高速化は1時バッファにためて、まとめて非同期で書き込みを行う事で
実現できたとういう知見を得ることができた。
はじめに
デバックログ分析とは
- 開発期に発生するログ
- Printf出力したものやプレイログ(移動履歴やダメージ量)が含まれる
- ゲームの品質向上
- 面白くしたいというQAと開発者のためのログ分析
なんでログ分析が必要?
- ここのログファイルを検索するのが面倒なので一括で検索できない?
- 強制終了するほどではない警告レベルの問題発生を確認したい
面白くするためのデバッグログ分析
- エラー情報以外にゲームの進行度、経験値などを送信
- kibanaというグラフ化ツールを見つけた
- デバックログ(printf)を検索できるだけでは、データの加工が大変で、分析できることも限られていた
デバックログ(printf)の例
- 人が読むのに適しているが、機械的にデータ処理しにくい構造
ログデータの流れ
- どこでもログ送信(key-value形式のデータ)
- 全て無料
LogSender
- ログファイルを監視して差分をFluentdに送信する常駐アプリを作成
- fluent-logger-csharpをつかったC#製
- ゲーム側はログファイルを書き出すだけにしたかった為
どこでもログ送信
Elasticsearchのデータ構造(龍6の場合)
- カテゴリごと(damage,stage,player_dead,chara)にインデックスを分けている
- インデックスは、1日単位
- カテゴリ別にインデックスも分ける
- stage,scnec,battle,motion ・・・
- カテゴリごとに削除する範囲をわけるため
- タイプを必ず指定
オリジナルのログ分析可視化機能
- ElasticsearchからC#アプリ経由でゲーム実行中にその場で分析可能
- しかし使用されなかった模様
使われない原因
- 「どこでもログ送信」がなかなかアプリ側に実装してもらえない
- データの信頼性が低い
使ってもらうために
- QAエンジニアが直接実装
- ログ分析ツールの起動が面倒
- URLにアクセスするだけですぐに閲覧できるような環境を準備
- データの信頼性の向上
- 自動化のログを活用できないか
Jenkins
- プログラム
- ビルドチェック
- 静的コード解析
- exe更新(Nightly Build)
- Redmineステータス変更
- ゲームに反映
エラー送信
- クラッシュレポート機能
- ゲームやツール実行中に例外発生
- ダンプファイル等をアップロード
- メール送信(ダンプ表示batのURL等)
- バグ報告(Redmineへ登録)
- ログ送信(Fluentdサーバーへ)
- ゲームやツール実行中に例外発生
オートテスト
- 自動プレイテスト
- 夜間の開発環境を活用して条件でゲームを起動してエラーを検出する仕組み
- オートインプット(自動パッド入力)
- ゲームパッド疑似入力以上のことをしない
- ランダム移動(モンキーテスト)
- パス移動(正常系テスト)
オートテストの仕組み
ランダム移動の仕組み
- ゲーム内容にあったガチャ押し
パス移動の仕組み
- ゲームプレイ中の入力をパスリストに変換
- シナリオ切り替え時に直前のシナリオのクリアパスを送信
- Elasticsearch(JSON形式でパスを保存)
- シナリオ切り替え時に一番新しいリビジョンのパスを取得
- オートテストでパスを再生
パスの作成と再生のデモ
- 画面にてデモが行われた
オートテストのパス移動導入の結果
- メインシナリオの全自動クリアを達成
パスも自動生成へ
- プレイするだけでパスを作成できるが、それも面倒なので完全自動生成を目論む
オートテストのエラー検出
- ランダムとパス移動でエラー検出は増加した
- 8102件(約10倍の検出になった)
オートテストの運用結果
- 毎日150ターゲットを稼働
- 24時間稼働PCを41台
- ランダム移動の活用
- パス移動の活用
- 課題
- パス移動でのUI(買い物や選択肢)の突破率の向上
- 各種ミニゲームのクリア
自動化とデバックログ分析の連携
- オートテストを使用して信頼できるログを集める
- 気軽に閲覧できる環境を整える
デバックログ分析活用ワークフロー
メインメモリ使用率
- オートテストの特定条件下カテゴリ別メインメモリ
キャラのVRAM使用率
- オートテストがメインストーリを全て周回しているので全てのシーンを計測可能
オリジナルのログ分析
- 背景のVRAMヒートマップ
コリジョン抜け
- オートテストのランダム移動を活用
オートテストの結果分析
- シナリオクリア結果
ゲームバランス調整フロー
- 桐生が死んだマップ
- 成長ログ
- 各章ごとの経験値を集計
- 死亡回数と蓄積ダメージ
リアルタイムログ分析の活用事例
- プレイヤー死亡回数をリアルタイムで監視
- 想定以上にバトルで死にすぎている時には、すぐにチェック席に行ってヒヤリングする
- 各テストプレイヤーの特性を発見
- アクションゲームが苦手なタイプ
- 敵の攻撃を避けるのがうまい
ログサーバー運用結果
- ログ送信量
- デイリーだと2000万行/日程度
- ログサーバー運用は特に問題なし
- たまにFluentdとElasticsearchの接続が切れたままになる
- ログサーバーのデータ量
- 最終的にログデータは150GBほど
- 速度
- 古いログはあまり分析しないので、それほど重くならなかった
かかった工数
- ログサーバー設置
- 2~3日
- ログ送信とログ分析(Kibana)
- 2~3週間
- ログ分析結果を見やすくする努力
- 2~3か月
課題
- ログ分析ツールの周知&活用
- プログラマを介さず誰でも気軽にログ分析できるようにしたい
- どこでもログ送信の積極的な追加
- どこでもログ送信の高速化
- 1時バッファにためて、まとめて非同期書き込み
- ファイル出力のままだが、毎フレーム送り続けるわけではないので問題ない
まとめ
デバッグログ分析とは
- 自動化の果てに辿り着いたご褒美
- 楽しむことが大事
「乖離性ミリオンアーサー」VRリメイクにおけるUIの最適化
開催日
- 2017/8/31(木) 14:50 〜 15:50
開催場所
- 横浜パシフィコ 502
登壇者
- 串田 夏子(グリー株式会社)ほか2名
所感
- VRコンテンツ制作においての知見を得ることができた。
- 長期間に渡り、繰り返しプレイする前提のコンテンツだと、操作がストレスにならないような工夫は必要である
- 「VRっぽさ」を追究するあまり、「操作の快適性」が犠牲になるのはNG
- VR映えする箇所と、そうでない箇所を見極める
- VR映えしない箇所に、無理矢理VRっぽい操作をねじ込まない
Agenda
- はじめに:「乖離性ミリオンアーサーVRとは」とは?
- Part1:バトルUI変化の過程 -表現とレイアウト-
- Part1.5:UI表示方法のバリエーション
- Part2:長く遊べるUI - 操作の快適性 -
乖離性ミリオンアーサーVRとは
- 乖離性ミリオンアーサVRはモバイルゲームをPC/PS4向けにアレンジしたVRゲーム
- VR化にあたりモデル・エフェクト・UI等、様々な要素をVR向けに再設計している
Part1:バトルUI変化の過程 -表現とレイアウト-
- はじめに
- VRコンテンツで理想的なインターフェースとは?
- 「現実での経験」に基づいた設定にすることでプレイヤーがスムーズに操作を促すことができる
要件1
- ゲーム内のキャラクターになりきって
- 空中に浮かんだカードを選び
- 剣を手に取って攻撃する
要件2
- VR上の手で触れて操作する
- SF映画でよく見られる空中投影型のインターフェース
課題
- 「現実での経験」に基づいた設定
- 実際に経験できない操作感をどうやって再現するか?
バトル紹介
- 手札が並ぶ
- カードを選択する
- ターゲットを選択する
- ターン開始
- 攻撃(カード使用)
開発で課題となった事例
- カードの制御
- 攻撃部位の選択
- ターンの開始
- 情報のレイアウト
カードの制御
- 目の前に浮かせたデッキからカードを手に取り、能力発動!
- 初期バー―ジョン
- 方向をX軸正面に固定、位置はHMDに追従
- 目に見えない「正面方向」が定められている違和感
- キーワード:正面方面
- VR空間は基準となるものを置かない限り正面や後ろ、右端・左端等を示すことができない
- よくある表現として、HMD(プレイヤーの下の位置)の下にあたる一に首から上のないモデルを置くことで、正面方法を示す
- 本作のバトルでは世界観的に基準となるものを置けなかった
- バージョン2
- プレイヤーの見ている向きを「正面」として、カードを追従
- 周囲を見回す妨げになる
- バージョン3
- 敵のいる方向を「正面」として、プレイヤーと敵を結ぶ直線状に配置
- 表現的にも機能的にも良くなったように見えたが...
課題に対するアプローチ
- プレイヤーが一定距離以上動くと初めてカードが動き
- 追従してくる仕組みに
- プレイヤーがカードとの距離を自由にとれるように
攻撃部位の選択
- イメージ
- カードを攻撃したい部位に向けて選択
- トリガーを引いて確定
- 攻撃部位をまっずくポイントして選択
- 標的が小さくて狙いにくい
- 判定範囲を広げた
- 部位同士が近すぎたり、前後関係にあったりして限界が
- 他にも課題が
- そもそも攻撃部位選択モードになったことがわからない
- 部位選択で角度による選択が有効なのは、
課題に対するアプローチ
- カードを「部位に向ける」のではなくコントローラーの「角度」によって部位が切り替わるように
- 直感的に部位を選びやすくなった
注意点
- 部位選択で角度による選択が有効なのは、このゲームの敵の部位が最大3つまでだから
ターンの開始
イメージ
- エクスカリバーを抜いてバトル開始
問題1
- 元々の仕様でカードを1枚も選ばずにパスするという選択肢がある
- 問題2
- 剣とカードがあったら直感的に先に剣を掴んでしまう
課題に関するアプローチ
- パス/攻撃開始を示した剣を置き
- 剣を「握る」ことでターンを開始
- パスの際は本当にパスするか確認を挟む
情報のレイアウト
カードゲームは見せなければいけない情報が多い
- HP
- バフ/デバフアイコン
- 選択しているカード
- 残コスト
- 属相関図
- 敵パラメーター
- カードスキルの詳細 etc
初期レイアウトの課題
- 見やすい位置にUIを置くと視界を遮ってします
- 詩やの端に置くとみえづらい&見ようと視線を動かすと頭と一緒にUIが動いてしまう...
- 最終的には頭部追従UIは全て無しに
課題に関するアプローチ
- VR体験を重視
- 表示するのは最低限にした
表現とレイアウトのまとめ
- 第三者視点から見てかっこいいUIはあくまで「見てかっこいいUI」であって、操作し易いUIとは限らない
- 直感性を重視して調整を行うが大事
- VR空間はイメージするほど情報は置けない
HMDの解像度を考慮すると共に、平面で考え過ぎずにVR空間内で繰り返し確認をすべき
UI表示方法のバリエーション
- 位置固定型
- ワールド配置
- カメラ基準
- オブジェクト付随
- ワールド配置
- ワールドの位置に固定されたUI
- 例)タイトル画面
- カメラ基準
- 出現時のカメラの位置や向きに合わせて表示されるUI
- 例)戦況確認画面
- 任意に表示できるUIを見失わないように工夫が可能
- オブジェクト付随
- 特定のオブジェクトに付随するUI
- 例)敵や味方アーサーのステータスバー
- カメラ追尾型
- カメラの位置のみに追従するUI。プレイヤーが動くとついてくる
- 例)手札
- カメラ張り付き
- カメラの前方に張り付いているUI
- 例)字幕
- 視界を遮らないようにするため、画面中央にものを置けない
- 視界の端をチラ見して瞬時に確認できる情報に有効
サンドイッチ
- カメラと別のオブジェクトの間に挟まるUI
- 例)手札
- UIと対象オブジェクトとの関連付けに便利
フル追尾
- ピッタリとカメラに追従する
- 例)字幕
- ディレイ追尾
- やや遅れてカメラに追従する
- 情報をみようと頭を動かすと、UIが逃げていくので不快
- 例)キャラステータス(旧)
- スナップ追尾
- 追従範囲から一定以上離れたら素早く追いつく(スナップする)
- プレイヤーが自分でUIとの距離を調整できる
- 例)手札
長く遊べるUI - 操作の快適性 -
- 開発初期のプラン
- バトルパートをメインに作成
- モーションコントローラーでの操作に重点を置いていた
- UI設計もモーションコントローラの使用を前提とした作りにしていた
- 課題
- 長時間続けると疲れてします
- モーションコントローラ操作のノベルティ性が過ぎてしまうと、いちいち腕を動かすのが億劫になってくる
- 細かなメニュー操作はかなりつらいことが判明
- ジャンルの性質も関係する
- メニュー操作の比重がとても高い
- メニュー操作が身体的につかれるとなると、ストレスになる
- VRコンテンツにありがちな、10~15分で終わる短い体験なら
臨場感重視の操作はマッチするが、長期間の繰り返しプレイには向かないことも
- 対策
- モーションコントローラ操作タイプの分割
- ゲームパッドの追加
- 操作モードのシームレス切り替え
- モーションコントローラ操作タイプの分割
- ゲームパッドの追加
- 操作モードのシームレス切り替え
- シームレス切り替え
- いつでもシームレスに操作モードの切り替えを行えるように実装
- 全てのUIをモーションコントローラー・ゲームパッド両方で操作可能なレイアウトに設計
- 操作モードの切り替えば「対象コントローラのいずれかのボタンを押す」だけ
- シームレス切り替えの特徴
- ゲームを中断することなく、好きなタイミングで自由に操作モードを変更できる
- UIは常に両方のモードに対応できるデザインになっている必要がある
- いずれかのモードに特化させることができないというデメリットも存在する
- シームレス切り替え
操作の快適性まとめ
- 操作のストレスを減らす
- 長期間に渡り、繰り返しプレイする前提のコンテンツだと、操作がストレスにならないような工夫は必要である
- 「VRっぽさ」を追究するあまり、「操作の快適性」が犠牲になるのはNG
- VR映えする箇所と、そうでない箇所を見極める
- VR映えしない箇所に、無理矢理VRっぽい操作をねじ込まない
一周年で爆発した「逆転オセロニア」における、ゲーム分析の貢献事例 〜開発・運営の意思決定を全力でサポートする、DeNAのゲーム分析体制〜
開催日
- 2017/9/1(金) 11:20 〜 12:20
開催場所
- 横浜パシフィコ 301
登壇者
- 藤江 清隆(株式会社ディー・エヌ・エー)ほか1名
所感
- 『オセロニア』の運営の考え方は、「集客 x 継続率 = DAU」というように
項目を分解し、集客と継続率改善の施策についてどのような取り組みをしているのか分かった - 分析のアウトプットメニューには4つの軸があり、それぞれの視点から分析していることが分かった
- 結局のところ、意思決定する人がアウトプットを活用したいと思える状態にする体制が必要であることが分かった
セッションの流れ
- 「逆転オセロニア」における分析の貢献事例
- 事業に貢献するための分析アウトプット・考え方
逆転オセロニア
- オセロ x TCG(トレーディング・カード・ゲーム)のアプリゲーム
- オセロがベースだからルールがわかりやすい
- 後半に「逆転」が起こるゲームシステム
DAUの振り返る
- 2016年の「年末年始イベント」前後比較
- DAUは5倍になった
ユーザー規模に関する基本知識
- 集客規模 x 継続率 = ユーザー規模(DAU)
継続率に対する運営の考え方
- ユーザーの支持は継続率に現れる
- 「逆転オセロニア」運営の前提
- ユーザーファーストであること
- 全てのユーザーにゲームを長く楽しんでもらいたい
- ゲームの継続をさまたげるような苦痛は早く取り除きたい
- ユーザーファーストであること
継続率で振り返る
- 2016年の「年末年始イベント」前後比較
- 30日後継続率2倍(インストールしてからの継続率)
- 継続率はなかなか上げにく項目
年末年始イベントに行った継続率改善事例
新規ユーザー向け
- ハマる前に離脱を防ぐための初期UX改善
既存ユーザー向け
- 累計ミッションの導入
- イベントの大量実施
課題をシューティングする上で困難な点
- ゲームには様々なユーザーがおり課題も多様
- ユーザー調査(インタビュー)
- 課題の優先度を付けることが難しい場合がある
- ユーザー調査(ゲーム内アンケート)
- 課題の量が多く施策に落ちるまでのスピードが遅くなる
- チームを巻き込んだ仮説検証と意思決定の効率化
継続率改善でユーザー調査を活用する意味
- インタビュー調査
- チームが把握しきれない課題仮説を構築できる
- ゲーム内アンケート調査
- 課題の優先度をマクロに評価できる
- 継続率と項目満足度をグラフ化
仮説検証と意思決定を効率的にするために
- 小さなアウトプットを高頻度で出し続ける
- 途中結果でも展開することでチームを巻き込んで議論を発生、仮設・検証精度を上げる
- 情報を高頻度更新し、チームの共通認識を作る
チーム内で仮説・議論を引き出すための取組み
- 朝会で出た課題はすぶに対応し途中経過を可視化
- Slackを利用してチーム全体を巻き込んだ議論を常に行っている
意思決定者との距離を近づける
- 意思決定スピードを上げるため、アナリストの席はプロデューサー・ディレクターの近くにしている
検証によって明らかになった課題を少しずつ改善
- 徹底的に検証・シューティングをおこなった
まとめ:継続率向上のために意識していたこと
ユーザー調査を活用すること
- 運営チームで拾えない仮説も把握した
- 様々な課題に対して優先度を可視化・評価した
仮説検証の効率化と意思決定の高速化のために
- 高速なアウトプットを行い分析業務の見えるかした
- プロデューサー・ディレクターとの席を近くし、重点課題を集中分析する体制にした
集客を効率化するためには
- どのようなユーザーがどのような起点で遊んでいるかを把握
- その上で、様々な知見を集約し、施策を効率化させる
ユーザーの認知経路分析の事例
- 有名YouTuberの紹介によってユーザー流入
- 集客経路の確認
ユーザー理解と集客施策の知見蓄積例
- 高校に出向いて調査した
- ヒアリングした
- 有名な人ほど集客が見込める
まとめ:集客効率化のためにやったこと
- 様々なチャネルで特性を調査し、ユーザー理解
- ゲーム内アンケートや行動ログの情報を活用
- 高校への出張など、ユーザーの生の声や反応を直接聞いた
- 知見集約を続け、集客効果を改善
- 若年層が見たくなるYouTuber動画の知見を地道に集めた
分析のアウトプットメニュー
- 行動ログ分析
- ゲーム内におけるユーザー行動ログを集計・分析する
- 全ユーザーの事実情報をカバー
- ユーザー全体を捉えることもセグメント切って細かくみることもできる
- ユーザー調査(定量・定性)
- ゲーム内外両面で使う
- オンラインアンケートや実際にユーザーを呼んでのインタビューなどの調査
- 行動ログだけでは把握しきれないユーザーの感情
- 企画段階でも有効
- マーケティング分析(マスプロモ・デジタルマーケ)
- ゲーム外におけるユーザーの分析
- 行動ログで把握できない数字が多いが、推定で組み立てる
- パラメータ・メタゲーム設計
- ユニットやスキル、スタミナや報酬などゲームサイクルが適切に回るパラメータやゲーム構造を設計・実装
- 行動ログ分析と絡めると制度が上がるため、分析が担当
- なぜ上記4つをアウトプットメニューにしているのか?
- 分析や手法が違う
- 各領域にスペシャリストが存在している
ゲーム分析が大事にしている考え方
- 「コミット」
- 担当するゲームを「自分ごと」 化して取り組む
- ゲームを作るチーム一体になる
- 良い分析アウトプット x 意思決定する人がアウトプットを活用したいと思える状態 ⇒ 事業への貢献
まとめ
- 爆発的な成長には新規獲得だけでなく、継続率がポイント
継続率改善には、大量・スピーディーにアウトプットする方向性が有効だった
分析が事業に貢献するためには「コミット」が重要
- 自然にコミットする・したくなる仕組みが大事
遺伝的アルゴリズムによる人工知能を用いたゲームバランス調整
開催日
- 2017/9/1(金) 14:50 〜 15:15
開催場所
- 横浜パシフィコ 304
登壇者
- 眞鍋 和子氏 (株式会社スクウェア・エニックス)QA、ゲームバランス調整
所感
- ゲーム開発においてもイテレーションの効率化や迅速化といったところから、AIの活用が大事
- 時間経過とプレイヤーレベルが増すことで、ゲームのコンテンツが多くないとユーザーを飽きさせてしまう
- プレイヤーAIを作成して、自動でAI自体を再生成できれば効率化が図れる
- AIの思考が可視化できる点も遺伝的アルゴリズムの利点であることが分かった
- 流行の深層学習だと,「実際に何がAIの中で起きているのか」を解析することが非常に難しいと言われているが,遺伝的アルゴリズムならば非常に分かりやすいデータを得られる利点がある
- 遺伝的アルゴリズムではパラメータがたくさんあるため、それを調整するのが難しいというデメリットもある
- AIに画面の意味を理解させるのは難しいため,バトルの結果はすべて数値として得るAPIを用意している
- 遺伝的アルゴリズムでは,突然変異が非常に重要である
- ゲーム中に使われるAIだけでなく,ゲーム開発を支援するAIにも注目が集まるようになるのかも...
Agenda
- ゲーム開発における課題
- プレイヤーAI
- グリムノーツ:
- ゲームの紹介と課題
- プレイヤーAIの利用方法
- プレイヤーAIの利用結果と考察
- まとめ
ゲーム開発における課題
- 開発イテレーションの短期化
- QAコストに着目
背景
- 短期間でアップデートが繰り返される
- 多くのQAテスターが必要
- QAコストの増加
- プレイヤーAI導入を提案
プレイヤーAI
- プレイヤーAIの代わりとなるAI
- 入力:プレイヤーが知れる情報と同等
- 出力:プレイヤーが取れる行動と同等
- ゲームを自動プレイ
- コンテンツを攻略させてみる
- 一定時間経過後のプレイヤーの状況を見る
- 自動生成が望ましい(重要)
- 新しいゲーム要素た追加された時、自動で再作成
- 短期間のアップデートに対応する為
既存の研究:プレイヤーAI
- City conquest
- FF RecordKeeper
- RPG
- 遺伝的アルゴリズム、ニューラルネットワーク、強化学習
- バトルの難易度評価
既存の研究:自動プレイ
- テスト自動化ツール
グリムノーツ
グリムノーツの課題
- たくさんのヒーローや装備
- 毎月、新しいヒーローや装備が追加
- 既存のものとの組み合わせ数が膨大
- バランスブレイカーがないか、要事前確認
- でも調べきれない
↓
- でも調べきれない
- プレイヤAIにバトルをさせる
グリムノーツのプレイヤーAI
- AIが目指すゴール:
- 与えられた要素の中から、指定されたバトルに対し、最適な組み合わを探す
- 主人公
- リーダー
- ヒーロー
- アクセサリー
- 衣装
- 武器
- スキルコア
- 与えられた要素の中から、指定されたバトルに対し、最適な組み合わを探す
- バトル
- ダメージ計算式は実ゲームと同じものを使用
- いくつかの要素を省略
- 短時間で実行可能
- 評価
- バトルの内容がどれだけよかったかを示す指標
- 勝利時:バトル時間の短さ
- 敗北時:与ダメージの多さ
と定義
- AIの改善
- 遺伝的アルゴリズム
- 装備の組み合わせの最適化
- パーティ編成を遺伝子とする
- ゲームの詳細知識は不用
- 新しい属性の追加
- 新しいスキルの追加
- 大幅な装備パラメータの変更
- 遺伝的アルゴリズム
遺伝的アルゴリズムとは
- 良い個体同士の遺伝子を掛け合わせて、新しい個体を生み出す手法
- 遺伝子の交換を行う
- 突然変異は消滅していく
なぜ遺伝的アルゴリズムか
- メリット1:
- 成長過程の観察が可能
- AIの施行の可視化
- メリット2:
- 幅広い強さを持った、プレイヤーAIの生成が可能
- 実際のゲームをプレイするのは、強いプレイヤーだけではない
- デメリット:
- アルゴリズムのパラメータ調整の難しさ
グリムノーツのプレイヤーAI
- AIとゲームの間の繋ぎ
- APIを設置した
プレイヤーAIの成長結果例
- 1つのプロットが1つの個体と考える
- 横軸は世代、縦軸は戦闘時間
- 突然変異による局所解脱出する場合もある
装備の使用頻度の統計
- 価値の高い主人公・ヒーロー・装備の発見
- コストとの比較
- 単体でしか強いものを発見することができなかったのでアソシエーション分析を行った
アソシエーション分析
- 価値の高い主人公・ヒーロー・装備の組み合わせの発見
- コストとの比較
課題
- モデル化されたシュミレーションでは情報が一部欠損
- XXXのこの結果は、シュミレーションだからか?実際のバトルでもそうなのか?
- 実プレイの高速化
- クラウド利用
- 高速シュミレーションモード
- 描画や物理のみ切り離す等の機構
- データ分析
- 客観的な視点によるゲームバランスの数値化
- 個体同士の「距離」などを使用したクラスタリング、価値の算出など
まとめ
プレイヤーAIによるゲームバランス調整
グリムノーツにてプレイヤーAIを獲得
- ゲーム詳細知識なしで、ゲームシステムに対応
- 価値の高い要素を自動で発見
QAコスト削減への期待
実プレイでのAIの成長が次のゴール
- データ分析の改善
クラウドの分析システムを活用したアクセスログにもとづくリアルタイム不正ユーザBANシステム
開催日
- 2017/9/1(金) 17:00 〜 17:25
開催場所
- 横浜パシフィコ 304
登壇者
- 藤田 貴大氏 (グリー株式会社)
所感
Agenda
不正アクセス
- 恐らくアカウント売却するため
- 最近のゲームは、リリース後にガチャを引けたり
リリース記念のログインボーナスがある - おなじIPアドレスから普段の数倍のアクセス
- けっこうまめにログインボーナスを取りに来る
- ありえないAPIアクセス
不正アクセスの影響
- とにかくサーバー側がつらい
- Webサーバーの負荷
- ゲーム進行に影響を与えないためにはサーバー台数をピークにあわせないといけない
- いつくるかわからないので増減させられない
- データ量の増加
- 課金系は、簡単にデータを削除できない
- お問い合わせ対応など
- 継続的な費用増加につながる
- 課金系は、簡単にデータを削除できない
不正アクセスへの対応
- 複数の角度から対応
- 個別、バッチなど
- ただし、1週間くらい短時間に急に来たものは見守るしかなかった
リアルタイムに不正ユーザーをBANするシステムを作る
実装をどうするか
- 目標
- せいぜい分単位の範囲で処理できること
- 既存部分に手を入れずに実装すること
- BANの判断をするために
- いくつかのAPIのログを突き合せたい
- ストリーム処理でやってみる
- 個々のAPIで判断するならLambdaという手もあった
ストリーム処理の実装
- Products
- Service
Kinesis Analytics
- GamelinそのものがAWSで稼働している
- 管理負荷をあげたくない
- サーバー構築
- スケーリング
- 障害対応
苦労した点
ローカルで実行できない
- Kinesis AnalyticsはCloseなプロダクトのためローカルに実行環境を準備できない
- Kinesis Analyticsのコード更新は分単位の時間がかかる
- 入力にKinesis Streamが必要
- 出力にKinesis StreamかFirehoseが出力に必要
- 完全な状態を見る為には出力を見るしかない(Firehoseからs3に出力されたものなど)
クエリを更新すると結果が2重に出てくる
- クエリを更新すると、恐らく内部で処理系が
新処理系立ち上げ → 旧処理系シャットダウンの順番で行われている(推測)
周辺環境が整っていない
- オーケストレーションツールが対応していない
- CloudFormation未対応
- Terraform未対応
- Webコンソールが完全ではない
- Kinesis Analyticsの出力は4つ設定できる
- Webコンソールでは1つしか表示がない
入力は発生順に来ない
- ストリーム処理の一般的な事情
- Kinesis Analyticsのウインドウについて理解することで解決
ウインドウという概念が難しかった
- 複数の入力をJOINする
- 時間の範囲を区切る必要がある
- タンブリングウインドウ
- スライディングウインドウ
タンブリングウインドウ
- ROWTIME(データの挿入時刻)でGROUP BY
- オーバーラップしない
- ウインドウ内であれば集計関数などはだいたいRDBっぽく動く
- 一定期間ごとの平均値を出す、など
スライディングウインドウ
- ウインドウはオーバーラップしながらスライドしてゆく
- 一定時間遡ったところまでのデータを使うという理解を自分の中でして
入力の順番についても解決できた
OVER句
- 範囲を指定する
- 処理が実行されたときに遡るデータの範囲
- 10秒前まで
OVER (RANGE INTERVAL '10' SECOND PRECEDING)
- 5列前まで
OVER (ROWS '5' PRECEDING)
まとめ
- 不正ユーザーにより、サーバーリソースが消費され費用負担が増加
- 不正ユーザーをできるだけ早くBANするためリアルタイム分析システムを活用したBANシステムを実装することに
- 周辺環境が整っていなかったり、ストリーム処理独特のSQLに手間取ったりしたが、運用開始できるところまで進めされた
分析業務をブーストするBIツール活用術
開催日
- 2017/9/1(金) 17:50 〜 18:15
開催場所
- 横浜パシフィコ 304
登壇者
- 竹村 伸太郎 (株式会社バンダイナムコスタジオ)
所感
- BIツールを選定する際は、様々な要素から選定する必要があると感じた
- セキュリティ、インフラの変化に強い、費用面、分業化、このような観点からの評価も必要
- サービスの価値が上がれば、求めらるものが変わる
Agenda
- BIツールって何?
- BIツール導入に至る経緯
- ツール選定基準と採用理由
- BIツール導入による具体的なメリット
BIツールとは
- 主に2つの目的をかなえるために、BIツールが使用される
- データを誰かに伝えたい(76%)
- データから何かを発見したい(57%)
BIツールの今
- BIツール市場は、近年競争が激化
- 結果、導入の敷居が下がっている
- 費用や運用コストが懸念材料なら、この機会に見直しを
BIツール導入に至る経緯(1)
- 内製のデータ解析基盤「GRECO」として開発スタート
- ログ仕様を固め、数10種類のタイトルに対し、共通する
指標を、単一のWebサービス上で共有。ここまでは成功。
- ログ仕様を固め、数10種類のタイトルに対し、共通する
BIツール導入に至る経緯(2)
- やがて内製の限界に直面
- タイトルごとに異なる固有の指標については、集計から見せ方まで要求項目が違う
- 1つのWebサービスに集約するには無理があった
- 状況を打破するために、代替ツールの選定を実施
評価対象としたツール
- ほぼ主観的な記述により以下を選定
ツールの比較(機能面)
ツールの比較(予算面)
- 下記設定による、費用シュミレーション
- レポート編集者は5名、ブラウザ上の閲覧者20名想定
- 原則1ユーザーにつき1ライセンス、US$1=\109換算で、
1年分のライセンス費用(2017年8月ベース)を試算
ツール選定の落とし穴
- 「モノ」「カネ」といった視点からは評価しやすい
- しかし、扱うのは機密情報。そこだけに囚われては駄目
- 「ヒト」「スピード」の視点から評価できているか?
- セキュアな認証、組織情報に即した認可が出来るか?
- 定型処理の自動化や、分業体制の構築は可能か?
選定結果
- Power BIを選定
- 最大の理由は、バンダイナムコグループウェアとしてOffice365を採用していたこと
- Power BIは、Office365から認証基盤やAD上の社員情報を引き継げる
- 各ダッシュボードについて、部署や雇用形態といった単位での閲覧権限管理が可能
- 列志向に対応したAzure SQL DB Premiun(RS)を用いて、レスポンスの高速化を低コストで実現
様々な観点からの評価
- ヒト ◎
- 情報統制やセキュリティは、Office365が担保
- モノ 〇
- データソースを選ばない。インフラの変化に強い
- 日時のローカライズなど、可視化やUIにおける課題は多い
- カネ ◎
- デスクトップ版(コンテンツ作成)が無償という安心感
- スピード 〇
- グループ機能を用いた共同作業がブラウザ上で可能
- プログラムによるレポート作成ができれば、尚良い
Excel使いにとってのBIツール
- Excel標準機能では難しい計算が簡単にできる
- スキルがインフラに依存しない
- ビックデータのインフラはまだ過渡期(Hadoop,Spark,Redshift,BigQuery...)
今あるインフラがずっと使われる保証はなし - BIツールも過渡期であるが、インフラよりは自分の裁量で決められやすいはず
- ビックデータのインフラはまだ過渡期(Hadoop,Spark,Redshift,BigQuery...)
分析官にとってのBIツール
- Power BIの場合、Rとの連携が可能(決定木デモ参照)
- Rを用いた様々なアドインが公開済み
まとめ
- 商用BIツールについて
- 非常に便利
- 無料で出来ることもたくさん
- 本運用時にツール選定を気を付けよう
- サービスの価値が上がれば、求めらえるものが変わる
- 予算や機能だけでなく、より多面的な評価
- 「ヒト」セキュリティ、情報統制
- 「スピード」スケーラビリティ、分業体制の構築
OSSで構築・運用する、いまどきのデータ分析・可視化システム
開催日
- 2017/9/1(金) 18:20 〜 18:45
開催場所
- 横浜パシフィコ 304
登壇者
- 伊澤 徹 (株式会社スクウェア・エニックス)
所感
- 運用を考慮した準備がいかに大切であるかが分かった
- ゲームサーバーのログはJSONを選定するのがよい。
対象
- 対象範囲
- システム構築~運用
- 対象外
- 得られたデータの使い方、運営施策
システム構成
- GameServer - GameDB - 蓄積 - データ可視化
収集:ゲームサーバーから収集
- 対象
- イベントログ:何がいつ発生したか
- 送信方法
- 一度ローカルに出してFluentdなど拾う
- ゲームサーバーから直接送る
- データフォーマット
- JSONが楽
収集:ゲームDBから収集
DBにあるデータの例
- ユーザーデータのスナップショット
- マスターデータ
- 失われてはいけないログ
方法
- スレーブから定期的に取得する
蓄積
加工
- データの変換・結合
- 可視化とセットで考える
- サーバー1台では足りない場合は管理が必要
可視化
- クエリーを投げ、グラフを出す
- ここ1~2年で実用的な選択肢がだいぶ増えた
Apache Zeppelinの紹介
- コード・クエリーを実行、結果をテーブルやグラフで表示
- コード + 描画内容を保持
- cronのような定期実行機能を持つ
- CSV出力対応
運用
- ソフトウェアを知る
- 何が起こっているのかを知る
ソフトウェアを知る
- 仕組みを理解する
- 設定可能項目全て眺めておく
ログ集約
- sshでログインして見て回るのは不可能
- 複数の指標を比較したい
- 実例:Fluentd ⇒ Elasticsearch ⇒ Kibana
- INFOログ仕分けが必要なため、テキスト検索に強いシステムに
ディスクが溢れる
- Kafkaが溢れる、Elasticsearchが、InfluxDBが・・・
- Retention(保持期間)が設定できるシステムはそれで
- 生logはローテート、定期削除
ディスクが空いているのに溢れる
- inode(管理領域)が細かいファイルで埋まる
- ファイル削除コマンド実行したが掴んだまま
- lsofで確認
まとめ
- 運用を考慮した準備をして
- 接続可能な分析・可視化システムを実現して
- OSSのバグ報告も布教も小さな貢献
CentOS7にPytho3.6をインストールして、virtualenvで2.xと切り替える
- 1.IUS Community Project のリポジトリを追加する
yum install -y https://centos7.iuscommunity.org/ius-release.rpm
- 2.Python 3.6をインストール
yum install -y python36u python36u-libs python36u-devel python36u-pip
- 3.エイリアスを設定する
ln -s /bin/python3.6 /bin/python3
- virtualenvがインストールされていなかったらインストールする
sudo pip install virtualenv
- 4.virtualenvコマンド実行
virtualenv my_env --python=/usr/bin/python3 cd my_env source bin/activate python -V Python 3.6.2 deactivate python -V Python 2.7.5
http://sonaiyuutemo.hatenablog.jp/entry/2017/05/31/180025 http://www.lifewithpython.com/2015/01/python-select-python-interpreter-on-virtualenv.html
yamlとjsonの構造比較
yamlの構造についてあまりできていないので jsonと比較して理解を深める。
- yaml形式
dev: app_function: your_module.your_app s3_bucket: your-code-bucket events: - function: your_module.your_function event_source: arn: arn:aws:s3:::your-event-bucket events: - s3:ObjectCreated:*
- json形式
{ "dev": { "app_function": "your_module.your_app", "s3_bucket": "your-code-bucket", "events": [ { "function": "your_module.your_function", "event_source": { "arn": "arn:aws:s3:::your-event-bucket", "events": [ "s3:ObjectCreated:*" ] } } ] } }