瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

実際のプレイに即したQAを入れてわかった意外な事実。

私は趣味でゲームを作っています。
お仕事でもシステムを作っているのですが、色々と社外秘の多い業界ですのでWebで語るのは趣味にとどめます。

前回までのあらすじ:
開発に必要なエンジニアの工数が逼迫してきたため、QA作業をデザイナーの方にお任せしました。
ただ任せるだけではモチベーションが続かないので、開発版を使った実況プレイ、という形でファンに新作の機能のアピールをしつつバグ報告をしてもらうことにしました。
YouTuber気分で宣伝とQA、あとスタッフのモチベーションアップができるので大変良い!と思いました。

結果:
最初の頃は思ったより実況が盛り上がりませんでした。
理由としては、たとえば「勇者チームが土壇場で救出に失敗したのはわかった、なぜこの結果になったか?」という部分が実況者に不明で全盛期の古舘伊知郎風の実況がつけづらかったからです。

そこで開発側タスクに「その結果をもたらした数字を出すこと」というタスクが積まれました。
Before
結果:失敗!
After
成功率10%
技能スキルで+20%!
タリスマン装備の効果で+5%!
「才能:ピンチに強い」で+10%!
合計成功率45%!
結果:失敗!
というような表示を出すことで実況がしやすくなりました。

ユーザーの調査の結果以下のことがわかりました。
副産物その1: ユーザーは結果だけを求めていない(ジョジョ5部のアバッキオの先輩の画像は略)

ユーザーは結果だけを求めていません。「親友キャラ、城之内が死んだ」という結果だけを渡されても、それが大事なことだと十分に強調されていないために、若干戸惑います。

しかし実際にはこのような表示の方が「タメ」がある分、ユーザーは満足しやすいということがわかりました。
お願い、死なないで城之内!あんたが今ここで倒れたら、舞さんや遊戯との約束はどうなっちゃうの? ライフはまだ残ってる。ここを耐えれば、マリクに勝てるんだから!

次回、「城之内死す」。デュエルスタンバイ!

いやこれを見たとき「えっ、そうなの?長い分ダラダラしていやなのかと・・・」と思いましたが、計測結果=現実の方を優先すべきと考え以降は「タメ」を重視した演出を入れるようにしました。

副産物その2:
意外なバグが見つかる。
当時の新作は本命キャラ以外に操作不能なサブキャラとしてNPCキャラが多数登場するゲームでした。
上のように数字を出していたことで意外な事実がわかりました。
例を上げると以下の通りです。
天馬騎士フュリーは敵に敗北した!
逃走成功ポイント:20
レベルによるボーナス:42
スキルによるボーナス:30
クラスによるボーナス:25
合計:117
捕獲判定:
敵捕獲能力4 * 敵兵数27 = 108
117 > 108
フュリーは逃走に成功した!

こう書くとたいしたことないんですよ。
逃走成功点を捕獲点で割った数が捕獲成功率になる、結果が1を超えたら100%逃走成功。
これは仕様です。

でもね。
開発側はこのときまで気づいていなかったんです。
「レベルが高すぎると、捕獲イベントが発生しない」という事実に
これに気付かず一生懸命捕獲イベントを作っていたわけです。
「彼氏キャラが助けに来たら絶対面白いって!」とか言いながら。

レベルが高いキャラ=プレイヤーの愛着が強いキャラなのでイベントが起きた方がユーザーの満足度も興奮も高いはずなんですが、実際にはイベントは起きないようになっていたんです。

そこそこ満遍なく強くしたテストデータやテストプレイでは気付かないUXバグが潜んでいたわけです。
この事実をもって実際のプレイに即したテストの重要さを思い知りました。