Inicio
Explorar
Enviar búsqueda
Cargar
Iniciar sesión
Registrarse
Publicidad
Check these out next
ゲームをおもしろくする技術 「ゲームとお笑い」
Kouji Ohno
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
Tokoroten Nakayama
時代遅れと言われようとMdaフレームワークの紹介
MaxNeetGames
MMORPGで考えるレベルデザイン
Katsumi Mizushima
ゲームの仕様書を書こうまとめ
Sugimoto Chizuru
シリコンバレーの「何が」凄いのか
Atsushi Nakada
スマートフォンゲームのチート事情
直生 亀山
MMOGで考えるゲームデザイン
Katsumi Mizushima
1
de
52
Top clipped slide
難易度ボラタリティグラフという分析手法
26 de Nov de 2017
•
0 recomendaciones
39 recomendaciones
×
Sé el primero en que te guste
ver más
•
254,444 vistas
vistas
×
Total de vistas
0
En Slideshare
0
De embebidos
0
Número de embebidos
0
Descargar ahora
Descargar para leer sin conexión
Denunciar
Ciencias
IGDA日本 ゲームサーバ勉強会 #7で話しました。 「難易度ボラタリティグラフ」という、心理学と統計を組み合わせた、ゲームにおける難易度調整手法です。
Tokoroten Nakayama
Seguir
雑用 en 株式会社NextInt
Publicidad
Publicidad
Publicidad
Recomendados
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
Tokoroten Nakayama
19.7K vistas
•
72 diapositivas
プログラマが欲しい仕様書とは
Katsutoshi Makino
90.3K vistas
•
48 diapositivas
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
187.2K vistas
•
84 diapositivas
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
120.5K vistas
•
99 diapositivas
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
52.1K vistas
•
26 diapositivas
データサイエンティスト養成読本の解説+書き忘れたこと
Tokoroten Nakayama
24.4K vistas
•
18 diapositivas
Más contenido relacionado
Presentaciones para ti
(20)
ゲームをおもしろくする技術 「ゲームとお笑い」
Kouji Ohno
•
3.3K vistas
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
Tokoroten Nakayama
•
23.4K vistas
時代遅れと言われようとMdaフレームワークの紹介
MaxNeetGames
•
12.9K vistas
MMORPGで考えるレベルデザイン
Katsumi Mizushima
•
53.2K vistas
ゲームの仕様書を書こうまとめ
Sugimoto Chizuru
•
61.5K vistas
シリコンバレーの「何が」凄いのか
Atsushi Nakada
•
182.8K vistas
スマートフォンゲームのチート事情
直生 亀山
•
64.8K vistas
MMOGで考えるゲームデザイン
Katsumi Mizushima
•
9.4K vistas
Unityのサウンド状況を調べまくって分かったアレコレ
Takaaki Ichijo
•
7.1K vistas
ゲーム制作初心者が知るべき8つのこと
MASA_T_O
•
341.9K vistas
スマートフォンゲーム企画書制作のポイント
Tetsuya Kimura
•
63.4K vistas
ワンランク上のゲームデザイン・レベルデザイン・UIデザインを考える 「コンテキスト」「コンフリクト」「コントラスト」デザイン
Kouji Ohno
•
23.7K vistas
コンセプト概論~出張ヒストリア編~
pugmaniac
•
12.9K vistas
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
•
288.1K vistas
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
•
162.5K vistas
Unity開発で使える設計の話+Zenjectの紹介
torisoup
•
121.4K vistas
仕様書作成のポイント_180814
Sugimoto Chizuru
•
24.6K vistas
UE4で実現できた理想のゲーム開発ワークフロー
historia_Inc
•
9.3K vistas
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
Tokoroten Nakayama
•
9.2K vistas
CEDEC2016 「コントラスト」で考えるゲームデザイン・レベルデザイン
Kouji Ohno
•
38.2K vistas
Similar a 難易度ボラタリティグラフという分析手法
(7)
強化学習による 「Montezuma's Revenge」への挑戦
孝好 飯塚
•
17.7K vistas
ITの今とこれから public
Daiyu Hatakeyama
•
441 vistas
一攫
Yasukazu Kawasaki
•
1.2K vistas
統計をとって高速化する Scala開発
Mitsuki Ogasahara
•
4.6K vistas
統計をとって高速化する Scala開発 by CyberZ,Inc.
scalaconfjp
•
962 vistas
Mac Rubyではじめる!Macアプリ開発入門
宏治 高尾
•
9.5K vistas
TensorFlow を使った機械学習ことはじめ (GDG京都 機械学習勉強会)
徹 上野山
•
319.3K vistas
Publicidad
Más de Tokoroten Nakayama
(20)
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
•
160.5K vistas
データマイニングの話詰め合わせ
Tokoroten Nakayama
•
17.1K vistas
機械学習の精度と売上の関係
Tokoroten Nakayama
•
46.9K vistas
インターネット上の情報発信手段の変遷 情報発信の簡易化
Tokoroten Nakayama
•
14.7K vistas
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016
Tokoroten Nakayama
•
29K vistas
ヒューレットパッカード社の社員の離職リスク予測 第一回機械学習ビジネス研究会 #ml_business
Tokoroten Nakayama
•
18.1K vistas
機械学習ビジネス研究会(未踏研究会)
Tokoroten Nakayama
•
9.6K vistas
失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi
Tokoroten Nakayama
•
47.3K vistas
失敗から学ぶデータ分析グループのチームマネジメント変遷
Tokoroten Nakayama
•
25.2K vistas
プロダクション環境でオンラインで機械学習を動かすにあたってツライ話 #MLCT
Tokoroten Nakayama
•
17.7K vistas
特徴ベクトル変換器を作った話 #dogenzakalt
Tokoroten Nakayama
•
11.5K vistas
特徴ベクトル変換器を作った話
Tokoroten Nakayama
•
8.2K vistas
jubatusのECサイトへの適応 #jubatus_hackathon
Tokoroten Nakayama
•
17.2K vistas
スマホマーケットの概要と、マーケティングの失敗例と改善 (アナリティクス アソシエーション 特別セミナー)
Tokoroten Nakayama
•
196.8K vistas
DAUを評価指標から捨てた会社の話 #tokyowebmining
Tokoroten Nakayama
•
150.5K vistas
BattleField3に見る自己表現としてのゲームプレイ
Tokoroten Nakayama
•
31.4K vistas
情報処理とは何か あとbigdataとか
Tokoroten Nakayama
•
29.5K vistas
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
Tokoroten Nakayama
•
5K vistas
ソーシャルゲームにレコメンドエンジンを導入した話
Tokoroten Nakayama
•
9.4K vistas
たのしいうぇっぶくろーら #pyfes
Tokoroten Nakayama
•
1.8K vistas
Último
(20)
在哪里可以做《林肯大学文凭证书|毕业证》
1232hdjk
•
3 vistas
《威斯康星大学绿湾分校毕业证|学位证书校内仿真版本》
d520dasw12
•
2 vistas
☀️《Sunderland毕业证仿真》
DAS54SA
•
2 vistas
国外学历【萨德伯里大学研究生文凭毕业证留学生首选】
ewq15a
•
2 vistas
留信网认证可查【麦吉尔大学文凭证书毕业证购买】
12da12
•
2 vistas
在哪里可以做《帝国理工学院文凭证书|毕业证》
1232hdjk
•
2 vistas
【ブログ記事用】コルテバ事例紹介:課題 vs 導入効果.pdf
IsabelWong26
•
35 vistas
留学生案例《田纳西大学学位毕业证书和学士文凭》
uijn12a
•
2 vistas
留学生案例《卡内基梅隆大学学位毕业证书和学士文凭》
15sdasd
•
2 vistas
在哪里可以做《西雅图大学文凭证书|毕业证》
20das12
•
2 vistas
☀️【威得恩大学毕业证成绩单留学生首选】
25mjhd12
•
2 vistas
《林肯大学毕业证|学位证书校内仿真版本》
w124dsa
•
2 vistas
在哪里可以做《利兹贝克特大学文凭证书|毕业证》
25ds12d
•
3 vistas
在哪里可以做《田纳西大学文凭证书|毕业证》
20das12
•
2 vistas
《马里兰大学帕克分校毕业证|学位证书校内仿真版本》
123shab123
•
4 vistas
LLM Webinar - シバタアキラ to share.pdf
Akira Shibata
•
103 vistas
キャッシュオブリビアスアルゴリズム
joisino
•
3 vistas
★可查可存档〖制作东伦敦大学文凭证书毕业证〗
mmmm282537
•
3 vistas
①【魁北克大学毕业证文凭学位证书|工艺完美复刻】
love445ds
•
2 vistas
留学生案例《利兹大学学位毕业证书和学士文凭》
36dsahj
•
2 vistas
Publicidad
難易度ボラタリティグラフという分析手法
難易度ボラタリティグラフ という分析手法 IGDA日本 ゲームサーバ勉強会 #7 https://techplay.jp/event/638904 中山ところてん
お前誰よ • ところてん • @tokoroten •
プログラマ、分析屋、ゲーム屋 • 情報処理学会・社団法人未踏 • 経歴 • 半導体計測機研究開発 • 電子透かし、フィッシングサイト検出 • マルウェア解析、ハニーポット運用、VMMいじり • 広告分析、ゲーム分析、ゲームデザイナ、ゲームディレクター • ECサイトの分析、行動経済学、機械学習 • 独立して社長業 • 会社作った • 傭兵業で外貨稼ぎ • ゲームディレクタ・ゲームデザイナ、半導体計測機開発、機械学習コンサル • お仕事募集中
最近遊んでいるゲーム
本が出るよ • 仕事ではじめる機械学習
なぜデータ分析の話をするのか • サーバ・インフラはデータ分析に最も近い • サーバに触れる=全部のデータが見える •
データ分析部門がない会社では、インフラ部門がデータ分析を必然的 に担うことになる • とりあえず分析してみるだけなら、SQL一発で行けることが多い • 覚えておいて損はない • アレなディレクターを殴り殺そう
この発表について • 学会で話した内容の焼き直し • 第56回プログラミングシンポジウム 「オンラインゲームにおけるゲームバランスの調整手法の提案」 •
本番データが使えないのでシミュレーション • とあるタイトルでは、本番利用しました • シミュレーションは眠い内容なので、無視してOK
オンラインゲームの課題 • ゲームバランスの重要性が非常に高い • 家庭用では買った後にゲームバランスが評価される •
F2Pオンラインゲームでは、ゲームを遊んだ後に面白かったら課金 する • F2Pオンラインゲームは常にアップデート • 最強の武器防具を手に入れたプレーヤーは、それ以上やることが なくなる • =ゲームに課金しなくなる • アップデートでゲームバランスが壊れる • 常に修正し続けなければ収益が悪化する • バランス調整の効率化が必要
先行研究:MDAフレームワーク • ゲームデザインを三層に分解して考える • Mechanics
(データ、アルゴリズム) • Dynamics (発生する現象) • Aesthetics(生成される感情) Mechanics Dynamics Aesthetics ①どのような現象が 面白いと感じられる のか? ②どのようなルール やパラメータにする と、目的とする現象 が得られるのか? ③意図した現象は 生まれているの か? ④意図した感情は 得られているの か?
先行研究:MDAフレームワーク • MDAフレームワークの特徴・課題 • Aesthetics(感情)から順に定義するので、ゴールがブレない •
仕様書やソースコードはMechanicsに相当 • 面白さのためには、仕様を曲げてもよい、となる • 課題 • 分析者によって得られる結論が異なる • ゲーム開発におけるワークフロー、マインドセットなので、システ ム化できるわけではない
先行研究:Machination • Machination • ダイアグラムによる、リソース変換記述言語 •
ゲームとは、複数種類のリソースを変換して、 目的に到達するものと定義 • ゲーム内で獲得、変換するリソースを記述することで、ゲームが正常に 回ることをシミュレーションする • 「ゲームメカニクス」というタイトルで解説本が出てます
先行研究:Machination • 課題 • ゲーム内の経済が回ることは検証できるが、 面白いことは検証できない •
MachinationはMDAフレームワークにおけるM→Dをシミュレーショ ン • Aの正しさまでは検証できない • アクション性の検証はできない • マリオはリソース変換で記述できない
本提案の狙い • 心理学と統計学、ゲームデザインを融合 • 心理学によりAestheticsとDynamicsを定義 •
どのような現象が発生していると、人は面白いと感じるのか • 統計学により、運用中のゲームからDynamicsを計測する • オンラインゲームは数万人のプレーヤが毎日プレイ • 統計情報を分析することで、Dynamicsが実現出来ているかを確認する • AIによるテストプレイが発達すれば、運用前からAIによるテストプレイでバランス調整が行える • AI時代を見据える • AIによるテストプレイが発展すれば、そのログから分析可能 • リリース前からAIによるバランス調整が行える
今回ターゲットとするゲーム • ステージクリア型のゲームを対象 • パズドラ、モンスト、etc… •
クリア済みのステージはいつでも再挑戦可能 • クリアできなかったら過去のステージでレベル上げ可能 • プレーヤースキルを、ゲーム内リソースで補えるもの • 対象としないゲーム • ハースストン、シャドーバースのような、TCG • レベル上げ要素が存在しないゲーム • プレーヤースキルを、ゲーム内リソースで補えないもの
ゲームにおける「面白い」とは何か • 面白い=フロー体験 • プレーヤースキルとチャレンジの難易度がかみ合っている状態
フロー体験の条件 1. 達成できる見通しのある課題に取り組んでいる 2. 自分がしていることに集中できている 3.
行われている作業に明瞭な目標がある 4. 直接的なフィードバックがある 5. 深いけれども無理のない没入状態である 6. 自分の行為を統制しているという感覚を伴う 7. 作業中は自己についての意識は消失する 作業後は自己についての意識は明瞭になる 8. 時間の感覚が変わる
退屈なゲーム、不安なゲーム • 退屈なゲーム • 敵が弱すぎて絶対に勝てる •
新しい体験が起こらない • 学習が回らない • 不安なゲーム • 敵が強すぎて絶対に勝てない、ストレス • 勝利の目が見えない • どうしていいか分からない • 学習が回らない • 「おもしろいのゲームデザイン」にも同じ話が
フロー体験が発生するゲーム • フローの条件の一部 • 直接的なフィードバックがある •
深いけれども無理のない没入状態である • 自分の行為を統制しているという感覚を伴う • 集中力を欠いたプレイでは失敗する状態 • ゲームの勝率が高すぎず、低すぎない状態 • フロー状態は勝率で定義できる、と仮定する
フロー理論と勝率のマッピング 勝率100% 勝率0% 勝率10%~90%くらい?
ゲームにおけるフロー体験の適応 • フロー理論のスキル軸はゲーム内資産で補える • ゲーム内のキャラクターの成長がフローを阻害することもある •
ガチャがゲームをクソゲーにすることも
フロー体験の図をゲーム用に修正 • 強さ=ゲーム内資産+運+スキル • 計測しづらい •
チャレンジ=ステージの難易度 • 多次元なので、定量化しづらい
難易度ボラタリティグラフの提案 • 計測可能なものに軸を変換する • 横軸、ゲーム内資産 •
パーティーのATKの合計値等の疑似的な値を利用する • 縦軸、勝率 不安 退屈 フロー ゲーム内資産 勝率 強さ ス テ ー ジ 難 易 度 =ゲーム内資産+運+スキル キリトル
難易度ボラタリティグラフの特徴 • 動いているゲームのログから簡易に生成できる • ステージの難易度が間接的に計測可能 •
ステージ難易度=勝率が50%になる点におけるゲーム内資産 • ボラタリティの大きさ=プレーヤースキルの寄与度合 不安 退屈 フロー ゲーム内資産 勝率 ステージの難易度 ボラタリティ
ボラタリティが大きすぎる • プレーヤースキルが、勝敗に影響しない • 運ゲーで面白くない ゲーム内資産 勝率
ボラタリティが小さすぎる • プレーヤースキルが、勝敗に影響しない • 課金ゲーで面白くない •
フロー体験を提供できるユーザが少ない ゲーム内資産 勝率
ステージ間の比較に利用する • 二つの連続するステージ間のボラタリティの重複領域を調べる • 重複領域が存在しない場合、そのゲームにおいてフローが感じられない領域が生 まれてしまう •
勝率100%のステージと、勝率0%のステージしか供給されていない場合、ユーザ は離脱してしまう ゲーム内資産 勝率
仮想ゲームによるシミュレーション • TRPG風のゲームを想定する • x+2D6≧s
でクリアとなるゲーム • x ゲーム内の資産 • 2D6 6面ダイス*2 (運+プレーヤースキルを表現) • S ステージの難易度 • 架空のプレーヤをゲームに投入し、何%のプレーヤがゲー ムを継続して遊んだかを調査する • n=10000 26
仮想ゲームによるシミュレーション • 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
プレーヤーのモデリング • 架空のプレーヤーに遊ばせることで、難易度ボラタリティグラフを検証する • 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 勝率 生存率
ステージの難易度上昇と成長 • ゲームの難易度は上昇する • 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
シミュレーション環境まとめ • x+2D6≧s で勝利となるゲーム •
x 初期値0、勝利時0.6の確率で1上昇 • s 初期値7、3回連続勝利で3上昇 • 10回連続勝利、10回連続敗北でユーザは離脱 • 100回連続プレイ時のユーザ継続率を評価 • sの設定を変えて、シミュレーション • レベルデザインを難易度ボラタリティグラフを用いて可視化し、 生存率と比較検討する 30
難易度上昇が急過ぎる場合 • 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
難易度上昇がぬる過ぎる場合 • 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
ファネル分析との併用 • ファネル分析によりユーザが離脱する箇所と、難易度ボラ タリティグラフを突合 • 離脱が多い箇所の難易度ボラタリティグラフのステージ密度か ら、難易度調整の適切性を判断可能 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を追加)
ヒートマップによる可視化 • 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%
まとめ • フロー理論をステージクリア型の オンラインゲームに合わせて変換 • スキル=ユーザスキル+ゲーム内資産+運 •
チャレンジ=ステージの難易度 • 難易度ボラタリティグラフを提案 • 横軸:ゲーム内資産、縦軸:勝率 • オンラインゲームのログから容易に描くことができる • ゲームの性質に依存しないで、ゲームバランス可視化が可能
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
ステージ継続率曲線、ファネル分析 • ステージ継続率曲線 • 一般に継続率というと、横軸に日数をとる •
一般的な継続率曲線は、収益予測には使えるが、ゲーム改善には利用できない • ステージ継続率曲線では、横軸にステージIDをとる • ゲーム離脱ユーザに限定して描くとより鮮明になる(ラストログイン等で絞る) • 「スタミナ切れで止まっている」ユーザを除外、「飽きたからやめた」ユーザに限定 継続率 ステージID リセマラ離脱 2回目の10連ガチャでのリセマラ離脱
ステージ継続率曲線、ファネル分析 • ステージ継続率曲線をステージ間離脱率に変換する • ステージ間離脱率(s)
= 1 - クリア人数s/クリア人数s+1 • リセマラ領域以外でピークが立って居る場所を探し、ユーザの離脱要因を考える 継続率 ステージID ステージID ステージ間離脱率 !? 難易度が高すぎる? シナリオが面白くない? 同じようなステージが続いている? ここで離脱したユーザを詳細に調べる
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
強さ分布曲線 • 強さをベースとしたヒストグラム • 理想的なユーザ分布は下図のようになる インストール直後
強さ 人数
強さ分布曲線 • ゲーム内リソース不足 • これ以上強くなれないユーザが増えてきている •
やることが無いので、超優良顧客が離脱する • コンテンツの追加タイミングを測ることが出来る 強さ 人数
強さ分布曲線 • 一週間程度の時間をおいて分布を確認する • 山が右側にシフトしていれば、プレーヤーが成長できているため、問題ないと判断する •
特定の強さのセグメントが減っていないか確認する 強さ 人数 インストール不足からくる 下位層の減少 ミドル層の成長 上位層の成長と飽和
強さ分布曲線 • 末期のゲームの分布 • 報酬ばらまきで分布が固まる •
上位層はコンテンツ不足で飽和徐々に離脱 • 新規インストールしても上位層にしかコンテンツが提供されないため離脱 強さ 人数 ゲームコンテンツ提供領域 ゲームコンテンツが提供されないた め、新規ユーザが遊ぶものがない
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
ランキングの報酬設計手法 「仕事ではじめる機械学習」 の中でのコラムで触れています
ランキングの報酬設計手法 • 報酬が存在しない場合のランキング、課金分布 • イベントでランキングがあったと仮定してグラフを作る •
実際はこんなキレイな曲線にはならないので、 10位ごとの平均値などで均すとよい 課金額 順位
ランキングの報酬設計手法 • ある順位以上に報酬を出すようにした場合 • ランキング境界付近の課金額が持ち上がる •
あと少しで報酬がもらえる、というところで競争が生まれる 課金額 順位 報酬境界
ランキングの報酬設計手法 • ランキング境界による持ち上がりがオーバーラップしないように、ランキング境界を切っていく • ランキングが適切に設計できると、オレンジ線のような歪みが生まれる •
曲線が歪んでいないのであれば、ランキングイベントの設計が失敗している • オレンジ線-灰色線=ランキングの効果 課金額 順位
ランキングの報酬設計手法 • ランキング=オークションシステムだと考える • 配布物の価値=ランキングのボーダーラインの課金額 •
レアカードであれば、そのレアカードの価値が決定する • ユーザはガチャを回すよりも安いから、イベントに参加していると仮定する • イベント課金額が下がってきているのであればカードの強さ、絵柄が足りない • ガチャでの排出期待値と比較して、ランキングの価値が適当かどうかを考える • カード価値が下がってきていると分かったら、インフレさせることを考える 課金額 順位 ランキング報酬で レアカード配布 ボーダーライン の課金額
おまけ:細かい分析手法いろいろ • ステージ継続率曲線と、ファネル分析 • 強さ分布曲線の時間変化 •
ランキングの報酬設計手法 • データ分析のためのDB構造をどうするか
データ分析のためのデータ構造 • ゲームのデータ構造と、データ分析のデータ構造は違う • ゲームのデータは基本的にアップデートされる •
レベル、所持金、所持アイテム… • データ分析のデータは、基本的にはログ • ~~~というイベントが起った瞬間のユーザのレベル、所持金、所持アイテム … • この違いを念頭に置いていないと、ログ設計で事故る • 過去のデータをどう保存するかが重要 • 基本的にjoinが必要なデータは全部joinして保存する • クエストに入った瞬間のデッキ情報等 • ユーザの所持金、経験値、アイテム情報等はデイリーで保存 • 全ユーザだと死ぬので、アクティブユーザのみの制約が必要 • 統計を取ると何のリソースがいつの時点で不足しているかが分かる
Notas del editor
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
Publicidad