SlideShare a Scribd company logo
Submit Search
Upload
Login
Signup
難易度ボラタリティグラフという分析手法
Report
Tokoroten Nakayama
Follow
雑用 at 株式会社NextInt
Nov. 26, 2017
•
0 likes
•
257,156 views
1
of
52
難易度ボラタリティグラフという分析手法
Nov. 26, 2017
•
0 likes
•
257,156 views
Download Now
Download to read offline
Report
Science
IGDA日本 ゲームサーバ勉強会 #7で話しました。 「難易度ボラタリティグラフ」という、心理学と統計を組み合わせた、ゲームにおける難易度調整手法です。
Tokoroten Nakayama
Follow
雑用 at 株式会社NextInt
Recommended
データマイニングの話詰め合わせ
Tokoroten Nakayama
17.2K views
•
65 slides
【Unite Tokyo 2019】Unityだったら簡単!マルチプレイ用ゲームサーバ開発 ~実践編~
UnityTechnologiesJapan002
61.8K views
•
82 slides
Unityでスマホアプリが作れるか?
MakotoItoh
16.5K views
•
28 slides
プログラマが欲しい仕様書とは
Katsutoshi Makino
90.8K views
•
48 slides
なぜコンピュータを学ばなければならないのか 21世紀の君主論
Tokoroten Nakayama
91.9K views
•
58 slides
DAUを評価指標から捨てた会社の話 #tokyowebmining
Tokoroten Nakayama
150.9K views
•
49 slides
More Related Content
What's hot
データサイエンティスト養成読本の解説+書き忘れたこと
Tokoroten Nakayama
24.4K views
•
18 slides
ゲームの仕様書を書こうまとめ
Sugimoto Chizuru
63.9K views
•
82 slides
ゲーム仕様書の書き方 ~大久保磨編~ ver.1.2.0
Osamu Ohkubo
87.5K views
•
16 slides
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
DeNA
60.3K views
•
82 slides
【Unite Tokyo 2018 Training Day】ProBuilderで学ぶレベルデザイン レベルデザインについて
Unity Technologies Japan K.K.
16.3K views
•
95 slides
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
Tokoroten Nakayama
9.3K views
•
34 slides
What's hot
(20)
データサイエンティスト養成読本の解説+書き忘れたこと
Tokoroten Nakayama
•
24.4K views
ゲームの仕様書を書こうまとめ
Sugimoto Chizuru
•
63.9K views
ゲーム仕様書の書き方 ~大久保磨編~ ver.1.2.0
Osamu Ohkubo
•
87.5K views
スマホゲームのチート手法とその対策 [DeNA TechCon 2019]
DeNA
•
60.3K views
【Unite Tokyo 2018 Training Day】ProBuilderで学ぶレベルデザイン レベルデザインについて
Unity Technologies Japan K.K.
•
16.3K views
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
Tokoroten Nakayama
•
9.3K views
UE4のためのより良いゲーム設計を理解しよう!
Masahiko Nakamura
•
27.6K views
あなたのチームの「いい人」は機能していますか?
Minoru Yokomichi
•
169.4K views
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
•
187.9K views
任天堂の呪いとナラティブについてバンナム編
Kawamura Yasuhisa
•
15.5K views
ゲームデザインを改善/批評するための時間構造モデル「ワンダールクス」
Sho Iwamoto
•
12.4K views
Unityでオンラインゲーム作った話
torisoup
•
10K views
RPGにおけるイベント駆動型の設計と実装
Koji Morikawa
•
9.3K views
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
•
53.5K views
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
•
160.8K views
プロジェクト予算と試算表_180815
Sugimoto Chizuru
•
14.3K views
ゲーム企画書の書き方? ~大久保磨編~ ver.1.4.0
Osamu Ohkubo
•
79.5K views
仕様書作成のポイント_180814
Sugimoto Chizuru
•
25.1K views
HowToDevelopATeamGrowsByThemselves_SCF_OSaka2022.pdf
Kei Nakahara
•
1.3K views
MMORPGで考えるレベルデザイン
Katsumi Mizushima
•
53.7K views
Similar to 難易度ボラタリティグラフという分析手法
強化学習による 「Montezuma's Revenge」への挑戦
孝好 飯塚
17.7K views
•
45 slides
ITの今とこれから public
Daiyu Hatakeyama
441 views
•
47 slides
一攫
Yasukazu Kawasaki
1.2K views
•
12 slides
統計をとって高速化する Scala開発
Mitsuki Ogasahara
4.6K views
•
46 slides
統計をとって高速化する Scala開発 by CyberZ,Inc.
scalaconfjp
962 views
•
46 slides
Mac Rubyではじめる!Macアプリ開発入門
宏治 高尾
9.5K views
•
63 slides
Similar to 難易度ボラタリティグラフという分析手法
(7)
強化学習による 「Montezuma's Revenge」への挑戦
孝好 飯塚
•
17.7K views
ITの今とこれから public
Daiyu Hatakeyama
•
441 views
一攫
Yasukazu Kawasaki
•
1.2K views
統計をとって高速化する Scala開発
Mitsuki Ogasahara
•
4.6K views
統計をとって高速化する Scala開発 by CyberZ,Inc.
scalaconfjp
•
962 views
Mac Rubyではじめる!Macアプリ開発入門
宏治 高尾
•
9.5K views
TensorFlow を使った機械学習ことはじめ (GDG京都 機械学習勉強会)
徹 上野山
•
319.5K views
More from Tokoroten Nakayama
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
Tokoroten Nakayama
19.9K views
•
72 slides
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
52.4K views
•
26 slides
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
121.6K views
•
99 slides
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
164.6K views
•
67 slides
機械学習の精度と売上の関係
Tokoroten Nakayama
47K views
•
14 slides
インターネット上の情報発信手段の変遷 情報発信の簡易化
Tokoroten Nakayama
14.7K views
•
17 slides
More from Tokoroten Nakayama
(20)
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
Tokoroten Nakayama
•
19.9K views
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
•
52.4K views
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
•
121.6K views
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
•
164.6K views
機械学習の精度と売上の関係
Tokoroten Nakayama
•
47K views
インターネット上の情報発信手段の変遷 情報発信の簡易化
Tokoroten Nakayama
•
14.7K views
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016
Tokoroten Nakayama
•
29.1K views
ヒューレットパッカード社の社員の離職リスク予測 第一回機械学習ビジネス研究会 #ml_business
Tokoroten Nakayama
•
18.2K views
機械学習ビジネス研究会(未踏研究会)
Tokoroten Nakayama
•
9.7K views
失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi
Tokoroten Nakayama
•
47.4K views
失敗から学ぶデータ分析グループのチームマネジメント変遷
Tokoroten Nakayama
•
25.2K views
プロダクション環境でオンラインで機械学習を動かすにあたってツライ話 #MLCT
Tokoroten Nakayama
•
17.8K views
特徴ベクトル変換器を作った話 #dogenzakalt
Tokoroten Nakayama
•
11.5K views
特徴ベクトル変換器を作った話
Tokoroten Nakayama
•
8.3K views
jubatusのECサイトへの適応 #jubatus_hackathon
Tokoroten Nakayama
•
17.2K views
スマホマーケットの概要と、マーケティングの失敗例と改善 (アナリティクス アソシエーション 特別セミナー)
Tokoroten Nakayama
•
197.3K views
BattleField3に見る自己表現としてのゲームプレイ
Tokoroten Nakayama
•
31.4K views
情報処理とは何か あとbigdataとか
Tokoroten Nakayama
•
29.5K views
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
Tokoroten Nakayama
•
5K views
ソーシャルゲームにレコメンドエンジンを導入した話
Tokoroten Nakayama
•
9.4K views
難易度ボラタリティグラフという分析手法
1.
難易度ボラタリティグラフ という分析手法 IGDA日本 ゲームサーバ勉強会 #7 https://techplay.jp/event/638904 中山ところてん
2.
お前誰よ • ところてん • @tokoroten •
プログラマ、分析屋、ゲーム屋 • 情報処理学会・社団法人未踏 • 経歴 • 半導体計測機研究開発 • 電子透かし、フィッシングサイト検出 • マルウェア解析、ハニーポット運用、VMMいじり • 広告分析、ゲーム分析、ゲームデザイナ、ゲームディレクター • ECサイトの分析、行動経済学、機械学習 • 独立して社長業 • 会社作った • 傭兵業で外貨稼ぎ • ゲームディレクタ・ゲームデザイナ、半導体計測機開発、機械学習コンサル • お仕事募集中
3.
最近遊んでいるゲーム
4.
本が出るよ • 仕事ではじめる機械学習
5.
なぜデータ分析の話をするのか • サーバ・インフラはデータ分析に最も近い • サーバに触れる=全部のデータが見える •
データ分析部門がない会社では、インフラ部門がデータ分析を必然的 に担うことになる • とりあえず分析してみるだけなら、SQL一発で行けることが多い • 覚えておいて損はない • アレなディレクターを殴り殺そう
6.
この発表について • 学会で話した内容の焼き直し • 第56回プログラミングシンポジウム 「オンラインゲームにおけるゲームバランスの調整手法の提案」 •
本番データが使えないのでシミュレーション • とあるタイトルでは、本番利用しました • シミュレーションは眠い内容なので、無視してOK
7.
オンラインゲームの課題 • ゲームバランスの重要性が非常に高い • 家庭用では買った後にゲームバランスが評価される •
F2Pオンラインゲームでは、ゲームを遊んだ後に面白かったら課金 する • F2Pオンラインゲームは常にアップデート • 最強の武器防具を手に入れたプレーヤーは、それ以上やることが なくなる • =ゲームに課金しなくなる • アップデートでゲームバランスが壊れる • 常に修正し続けなければ収益が悪化する • バランス調整の効率化が必要
8.
先行研究:MDAフレームワーク • ゲームデザインを三層に分解して考える • Mechanics
(データ、アルゴリズム) • Dynamics (発生する現象) • Aesthetics(生成される感情) Mechanics Dynamics Aesthetics ①どのような現象が 面白いと感じられる のか? ②どのようなルール やパラメータにする と、目的とする現象 が得られるのか? ③意図した現象は 生まれているの か? ④意図した感情は 得られているの か?
9.
先行研究:MDAフレームワーク • MDAフレームワークの特徴・課題 • Aesthetics(感情)から順に定義するので、ゴールがブレない •
仕様書やソースコードはMechanicsに相当 • 面白さのためには、仕様を曲げてもよい、となる • 課題 • 分析者によって得られる結論が異なる • ゲーム開発におけるワークフロー、マインドセットなので、システ ム化できるわけではない
10.
先行研究:Machination • Machination • ダイアグラムによる、リソース変換記述言語 •
ゲームとは、複数種類のリソースを変換して、 目的に到達するものと定義 • ゲーム内で獲得、変換するリソースを記述することで、ゲームが正常に 回ることをシミュレーションする • 「ゲームメカニクス」というタイトルで解説本が出てます
11.
先行研究:Machination • 課題 • ゲーム内の経済が回ることは検証できるが、 面白いことは検証できない •
MachinationはMDAフレームワークにおけるM→Dをシミュレーショ ン • Aの正しさまでは検証できない • アクション性の検証はできない • マリオはリソース変換で記述できない
12.
本提案の狙い • 心理学と統計学、ゲームデザインを融合 • 心理学によりAestheticsとDynamicsを定義 •
どのような現象が発生していると、人は面白いと感じるのか • 統計学により、運用中のゲームからDynamicsを計測する • オンラインゲームは数万人のプレーヤが毎日プレイ • 統計情報を分析することで、Dynamicsが実現出来ているかを確認する • AIによるテストプレイが発達すれば、運用前からAIによるテストプレイでバランス調整が行える • AI時代を見据える • AIによるテストプレイが発展すれば、そのログから分析可能 • リリース前からAIによるバランス調整が行える
13.
今回ターゲットとするゲーム • ステージクリア型のゲームを対象 • パズドラ、モンスト、etc… •
クリア済みのステージはいつでも再挑戦可能 • クリアできなかったら過去のステージでレベル上げ可能 • プレーヤースキルを、ゲーム内リソースで補えるもの • 対象としないゲーム • ハースストン、シャドーバースのような、TCG • レベル上げ要素が存在しないゲーム • プレーヤースキルを、ゲーム内リソースで補えないもの
14.
ゲームにおける「面白い」とは何か • 面白い=フロー体験 • プレーヤースキルとチャレンジの難易度がかみ合っている状態
15.
フロー体験の条件 1. 達成できる見通しのある課題に取り組んでいる 2. 自分がしていることに集中できている 3.
行われている作業に明瞭な目標がある 4. 直接的なフィードバックがある 5. 深いけれども無理のない没入状態である 6. 自分の行為を統制しているという感覚を伴う 7. 作業中は自己についての意識は消失する 作業後は自己についての意識は明瞭になる 8. 時間の感覚が変わる
16.
退屈なゲーム、不安なゲーム • 退屈なゲーム • 敵が弱すぎて絶対に勝てる •
新しい体験が起こらない • 学習が回らない • 不安なゲーム • 敵が強すぎて絶対に勝てない、ストレス • 勝利の目が見えない • どうしていいか分からない • 学習が回らない • 「おもしろいのゲームデザイン」にも同じ話が
17.
フロー体験が発生するゲーム • フローの条件の一部 • 直接的なフィードバックがある •
深いけれども無理のない没入状態である • 自分の行為を統制しているという感覚を伴う • 集中力を欠いたプレイでは失敗する状態 • ゲームの勝率が高すぎず、低すぎない状態 • フロー状態は勝率で定義できる、と仮定する
18.
フロー理論と勝率のマッピング 勝率100% 勝率0% 勝率10%~90%くらい?
19.
ゲームにおけるフロー体験の適応 • フロー理論のスキル軸はゲーム内資産で補える • ゲーム内のキャラクターの成長がフローを阻害することもある •
ガチャがゲームをクソゲーにすることも
20.
フロー体験の図をゲーム用に修正 • 強さ=ゲーム内資産+運+スキル • 計測しづらい •
チャレンジ=ステージの難易度 • 多次元なので、定量化しづらい
21.
難易度ボラタリティグラフの提案 • 計測可能なものに軸を変換する • 横軸、ゲーム内資産 •
パーティーのATKの合計値等の疑似的な値を利用する • 縦軸、勝率 不安 退屈 フロー ゲーム内資産 勝率 強さ ス テ ー ジ 難 易 度 =ゲーム内資産+運+スキル キリトル
22.
難易度ボラタリティグラフの特徴 • 動いているゲームのログから簡易に生成できる • ステージの難易度が間接的に計測可能 •
ステージ難易度=勝率が50%になる点におけるゲーム内資産 • ボラタリティの大きさ=プレーヤースキルの寄与度合 不安 退屈 フロー ゲーム内資産 勝率 ステージの難易度 ボラタリティ
23.
ボラタリティが大きすぎる • プレーヤースキルが、勝敗に影響しない • 運ゲーで面白くない ゲーム内資産 勝率
24.
ボラタリティが小さすぎる • プレーヤースキルが、勝敗に影響しない • 課金ゲーで面白くない •
フロー体験を提供できるユーザが少ない ゲーム内資産 勝率
25.
ステージ間の比較に利用する • 二つの連続するステージ間のボラタリティの重複領域を調べる • 重複領域が存在しない場合、そのゲームにおいてフローが感じられない領域が生 まれてしまう •
勝率100%のステージと、勝率0%のステージしか供給されていない場合、ユーザ は離脱してしまう ゲーム内資産 勝率
26.
仮想ゲームによるシミュレーション • TRPG風のゲームを想定する • x+2D6≧s
でクリアとなるゲーム • x ゲーム内の資産 • 2D6 6面ダイス*2 (運+プレーヤースキルを表現) • S ステージの難易度 • 架空のプレーヤをゲームに投入し、何%のプレーヤがゲー ムを継続して遊んだかを調査する • n=10000 26
27.
仮想ゲームによるシミュレーション • x+2D6≧s でクリアとなるゲーム •
S=15、xを変化させたグラフ 27 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 勝率 ゲーム内資産 X
28.
プレーヤーのモデリング • 架空のプレーヤーに遊ばせることで、難易度ボラタリティグラフを検証する • 100回連続でゲームをプレイ •
10回連続で勝利->退屈なゲームなので、ゲームをやめてしまう • 10回連続で敗北->不安なゲームなので、ゲームをやめてしまう • 勝率50%程度くらいの領域が一番ゲームを継続する 28 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ゲーム内資産 X 勝率 生存率
29.
ステージの難易度上昇と成長 • ゲームの難易度は上昇する • 3回連続勝利で、次のステージが解放 •
sを3上昇させる、初期値7 • プレーヤのゲーム内資産xも上昇する • 勝利時に確率rでxが1成長、xの初期値0、r=0.6で最大 29 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 勝率 ゲーム内資産x s=7 s=10 s=13 s=16 s=19 s=22 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 継続率 成長確率r
30.
シミュレーション環境まとめ • x+2D6≧s で勝利となるゲーム •
x 初期値0、勝利時0.6の確率で1上昇 • s 初期値7、3回連続勝利で3上昇 • 10回連続勝利、10回連続敗北でユーザは離脱 • 100回連続プレイ時のユーザ継続率を評価 • sの設定を変えて、シミュレーション • レベルデザインを難易度ボラタリティグラフを用いて可視化し、 生存率と比較検討する 30
31.
難易度上昇が急過ぎる場合 • S=16のステージを除外する • 難易度上昇が急激になるため、S=19での敗北が増加、 ゲームからユーザが抜けてしまう 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 勝率 ゲーム内資産x s=7 s=10 s=13 s=16 s=19 s=22 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 勝率 ゲーム内資産x s=7 s=10 s=13 s=19 s=22
32.
難易度上昇がぬる過ぎる場合 • S=14,15,17,18のステージを追加する • 難易度上昇が緩すぎるため、ユーザの成長速度に対して、難 易度上昇が追い付かず、適切な難易度をユーザに提供でき ず、離脱する 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 勝率 ゲーム内資産x s=7 s=10 s=13 s=16 s=19 s=22 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 勝率 ゲーム内資産x s=7 s=10 s=13 s=14 s=15 s=16 s=17 s=18 s=19 s=22
33.
ファネル分析との併用 • ファネル分析によりユーザが離脱する箇所と、難易度ボラ タリティグラフを突合 • 離脱が多い箇所の難易度ボラタリティグラフのステージ密度か ら、難易度調整の適切性を判断可能 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 7
10 13 16 19 22 25 28 31 34 37 40 ステージの難易度s 生存率 生存率(s=16を除外) 生存率(s=14,15,17,18,20,21を追加) 0% 10% 20% 30% 40% 50% 60% 70% 7 10 13 16 19 22 25 28 31 34 37 40 ステージの難易度s 離脱率 離脱率(s=16を除外) 離脱率(s=14,15,17,18,20,21を追加)
34.
ヒートマップによる可視化 • 5つ以上のステージの難易度比較に、難易度ボラタリティグラフは不適当 • 難易度が前のステージよりも低いステージは区別がつかない •
難易度ボラタリティグラフをヒートマップで可視化する • 横軸:ゲーム内資産x、縦軸:ステージ番号、濃淡:勝率 • ボラタリティ領域の重複が一目でわかる • バランス崩壊している過剰に難しいステージや、過去のステージよりも簡単なステー ジが可視化可能 x=0 x=1 x=2 x=3 x=4 x=5 x=6 x=7 x=8 x=9 x=10 x=11 x=12 x=13 x=14 x=15 x=16 x=17 x=18 x=19 s=7 59.6% 71.8% 82.4% 91.0% 97.1% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% s=10 16.8% 28.3% 41.6% 58.5% 72.3% 83.3% 91.7% 97.1% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% s=13 0.0% 2.9% 8.3% 16.6% 28.1% 42.4% 58.2% 71.7% 83.5% 91.9% 97.4% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% s=16 0.0% 0.0% 0.0% 0.0% 2.9% 8.4% 16.2% 27.9% 41.9% 58.2% 71.9% 83.6% 92.0% 97.3% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% s=19 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 2.6% 8.8% 16.4% 27.9% 40.8% 58.7% 72.6% 84.0% 91.4% 97.3% 100.0% 100.0% 100.0% s=17 0.0% 0.0% 0.0% 0.0% 0.0% 2.7% 8.4% 17.0% 27.6% 41.1% 59.2% 72.2% 83.5% 91.8% 97.4% 100.0% 100.0% 100.0% 100.0% 100.0% s=22 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 2.7% 7.9% 16.5% 27.6% 41.2% 58.1% 72.2% 83.8% 97.2% 100.0%
35.
まとめ • フロー理論をステージクリア型の オンラインゲームに合わせて変換 • スキル=ユーザスキル+ゲーム内資産+運 •
チャレンジ=ステージの難易度 • 難易度ボラタリティグラフを提案 • 横軸:ゲーム内資産、縦軸:勝率 • オンラインゲームのログから容易に描くことができる • ゲームの性質に依存しないで、ゲームバランス可視化が可能
37.
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
38.
ステージ継続率曲線、ファネル分析 • ステージ継続率曲線 • 一般に継続率というと、横軸に日数をとる •
一般的な継続率曲線は、収益予測には使えるが、ゲーム改善には利用できない • ステージ継続率曲線では、横軸にステージIDをとる • ゲーム離脱ユーザに限定して描くとより鮮明になる(ラストログイン等で絞る) • 「スタミナ切れで止まっている」ユーザを除外、「飽きたからやめた」ユーザに限定 継続率 ステージID リセマラ離脱 2回目の10連ガチャでのリセマラ離脱
39.
ステージ継続率曲線、ファネル分析 • ステージ継続率曲線をステージ間離脱率に変換する • ステージ間離脱率(s)
= 1 - クリア人数s/クリア人数s+1 • リセマラ領域以外でピークが立って居る場所を探し、ユーザの離脱要因を考える 継続率 ステージID ステージID ステージ間離脱率 !? 難易度が高すぎる? シナリオが面白くない? 同じようなステージが続いている? ここで離脱したユーザを詳細に調べる
40.
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
41.
強さ分布曲線 • 強さをベースとしたヒストグラム • 理想的なユーザ分布は下図のようになる インストール直後
強さ 人数
42.
強さ分布曲線 • ゲーム内リソース不足 • これ以上強くなれないユーザが増えてきている •
やることが無いので、超優良顧客が離脱する • コンテンツの追加タイミングを測ることが出来る 強さ 人数
43.
強さ分布曲線 • 一週間程度の時間をおいて分布を確認する • 山が右側にシフトしていれば、プレーヤーが成長できているため、問題ないと判断する •
特定の強さのセグメントが減っていないか確認する 強さ 人数 インストール不足からくる 下位層の減少 ミドル層の成長 上位層の成長と飽和
44.
強さ分布曲線 • 末期のゲームの分布 • 報酬ばらまきで分布が固まる •
上位層はコンテンツ不足で飽和徐々に離脱 • 新規インストールしても上位層にしかコンテンツが提供されないため離脱 強さ 人数 ゲームコンテンツ提供領域 ゲームコンテンツが提供されないた め、新規ユーザが遊ぶものがない
45.
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
46.
ランキングの報酬設計手法 「仕事ではじめる機械学習」 の中でのコラムで触れています
47.
ランキングの報酬設計手法 • 報酬が存在しない場合のランキング、課金分布 • イベントでランキングがあったと仮定してグラフを作る •
実際はこんなキレイな曲線にはならないので、 10位ごとの平均値などで均すとよい 課金額 順位
48.
ランキングの報酬設計手法 • ある順位以上に報酬を出すようにした場合 • ランキング境界付近の課金額が持ち上がる •
あと少しで報酬がもらえる、というところで競争が生まれる 課金額 順位 報酬境界
49.
ランキングの報酬設計手法 • ランキング境界による持ち上がりがオーバーラップしないように、ランキング境界を切っていく • ランキングが適切に設計できると、オレンジ線のような歪みが生まれる •
曲線が歪んでいないのであれば、ランキングイベントの設計が失敗している • オレンジ線-灰色線=ランキングの効果 課金額 順位
50.
ランキングの報酬設計手法 • ランキング=オークションシステムだと考える • 配布物の価値=ランキングのボーダーラインの課金額 •
レアカードであれば、そのレアカードの価値が決定する • ユーザはガチャを回すよりも安いから、イベントに参加していると仮定する • イベント課金額が下がってきているのであればカードの強さ、絵柄が足りない • ガチャでの排出期待値と比較して、ランキングの価値が適当かどうかを考える • カード価値が下がってきていると分かったら、インフレさせることを考える 課金額 順位 ランキング報酬で レアカード配布 ボーダーライン の課金額
51.
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
52.
データ分析のためのデータ構造 • ゲームのデータ構造と、データ分析のデータ構造は違う • ゲームのデータは基本的にアップデートされる •
レベル、所持金、所持アイテム… • データ分析のデータは、基本的にはログ • ~~~というイベントが起った瞬間のユーザのレベル、所持金、所持アイテム … • この違いを念頭に置いていないと、ログ設計で事故る • 過去のデータをどう保存するかが重要 • 基本的にjoinが必要なデータは全部joinして保存する • クエストに入った瞬間のデッキ情報等 • ユーザの所持金、経験値、アイテム情報等はデイリーで保存 • 全ユーザだと死ぬので、アクティブユーザのみの制約が必要 • 統計を取ると何のリソースがいつの時点で不足しているかが分かる
Editor's Notes
SELECT stage_challenge_log.stage_id, AVG(stage_challenge_log.result) FROM stage_challenge_log JOIN uses ON stage_challenge_log.user_id = users.id WHERE users.last_login_at < DATEADD(day,-7, GETDATE()) GROUP BY 1 ORDER BY 1