Mais conteúdo relacionado Semelhante a 難易度ボラタリティグラフという分析手法 (7) Mais de Tokoroten Nakayama (20) 難易度ボラタリティグラフという分析手法2. お前誰よ
• ところてん
• @tokoroten
• プログラマ、分析屋、ゲーム屋
• 情報処理学会・社団法人未踏
• 経歴
• 半導体計測機研究開発
• 電子透かし、フィッシングサイト検出
• マルウェア解析、ハニーポット運用、VMMいじり
• 広告分析、ゲーム分析、ゲームデザイナ、ゲームディレクター
• ECサイトの分析、行動経済学、機械学習
• 独立して社長業
• 会社作った
• 傭兵業で外貨稼ぎ
• ゲームディレクタ・ゲームデザイナ、半導体計測機開発、機械学習コンサル
• お仕事募集中
12. 本提案の狙い
• 心理学と統計学、ゲームデザインを融合
• 心理学によりAestheticsとDynamicsを定義
• どのような現象が発生していると、人は面白いと感じるのか
• 統計学により、運用中のゲームからDynamicsを計測する
• オンラインゲームは数万人のプレーヤが毎日プレイ
• 統計情報を分析することで、Dynamicsが実現出来ているかを確認する
• AIによるテストプレイが発達すれば、運用前からAIによるテストプレイでバランス調整が行える
• AI時代を見据える
• AIによるテストプレイが発展すれば、そのログから分析可能
• リリース前からAIによるバランス調整が行える
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
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%
52. データ分析のためのデータ構造
• ゲームのデータ構造と、データ分析のデータ構造は違う
• ゲームのデータは基本的にアップデートされる
• レベル、所持金、所持アイテム…
• データ分析のデータは、基本的にはログ
• ~~~というイベントが起った瞬間のユーザのレベル、所持金、所持アイテム
…
• この違いを念頭に置いていないと、ログ設計で事故る
• 過去のデータをどう保存するかが重要
• 基本的にjoinが必要なデータは全部joinして保存する
• クエストに入った瞬間のデッキ情報等
• ユーザの所持金、経験値、アイテム情報等はデイリーで保存
• 全ユーザだと死ぬので、アクティブユーザのみの制約が必要
• 統計を取ると何のリソースがいつの時点で不足しているかが分かる
Notas do 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