桝田方式によるユーザーストーリーの作り方(2)

シリーズは以下。

桝田方式と書いているけれど、桝田方式と現在の僕の方法は原理的な部分は同じなのだけどアプローチは変わっているので、元の桝田方式はどんな形式で、なぜそれを変えたのかについて説明しておきたい。
まず、桝田方式はもともとは1987年に桝田さんが桃太郎伝説1(ファミコン版)の戦闘バランスを作るために考えたものだ。
桝田さんはそれまではゲームを遊んだことがなく、仕事で慌ててドラクエをプレイしたというのは有名な話…だと思う。

僕が覚えているエピソードを書くと、一度もやったことがなかったテレビゲーム、それもドラゴンクエスト1を計算式を作らないといけないというので、24時間ほとんど寝ないでプレイして、最後まで辿り着き「せかいの半分をお前にやろう」の問いで「はい」と答え、全てがパーになり(ファミコン版はバッテリバックアップがなく、セーブはパスワードで行われるが、そのパスワードも一度もとっていなかった)、またほぼ24時間かけて、クリアした…と言っていた。

余談はともかく、桝田さんはドラクエの数値バランスをリファレンスにして、桃太郎伝説を作ったわけだが、その方法はどんなものだったのか?
もともとの桝田さんの方法は、クリアレベルを決定して、そこでのキャラクタの強さ(敵を何撃で倒せる/敵は何撃で自分を殺す)を決めて、クリアレベルとレベル1からパラメータを決める方法で、プレイ時間に着目した作りではなかった(もちろんプレイ時間も桝田方式から導き出すことは当然出来る)。

桝田さんのオリジナルの方法がまとめられたtogetter。

togetterで読みづらいから、簡単にまとめると

  1. 平均的なバトルバランスを考える。
    例えばプレイヤーは2~3発で敵を殺せ、敵は10発でプレイヤーを殺す。
  2. 単純に初期値は、HP=攻撃力=防御力=100として考える。
    HP減少値=攻撃力100 – (1-(1/N))*防御力(100)
    敵はN=10、プレイヤー側はN=2.5になる。
  3. 次にレベル50、全パラメータ600でボスをクリア出来ると決める。
  4. すると1レベル当たり10上がることになる。
  5. これのうち50%が装備であると決める。すると装備50%+パラメータ50%なので、1レベルあたりパラメータは5あがる。
  6. これを主人公(プレイヤー)と設定し、仲間を作る。
  7. 敵のパラメータも大雑把に決める。
  8. 冒険の順路に沿って想定レベルを割り振る。(想定レベル=敵のレベルと考えると分かりやすい)
    想定レベルを高くすると難易度が上がり、低くすると難易度が下がる。
  9. 攻撃力<守備力になるとダメージが出なくなる。これを解決するには攻撃力/64とか、もしくは0~4あたりの乱数を振る。

9はバランスではなくテクニックだ。
桝田方式をさらに短く単純化してまとめると

  1. 適正(とゲームデザイナーが判断する)バトルバランスを想定する。
  2. クリアレベルとパラメータを設定すると基本的な成長曲線が決まる。
  3. スタートとゴールが決まるので、シナリオに沿ってレベルを配分する。
  4. 味付けを行う

つまり、バトルバランスとクリアレベルから始めるのが桝田方式なわけだけど、僕の紹介している方式では時間(リソース獲得)に着目したバランスの取り方になっている。なぜか?
理由は簡単でレベルより時間の方がいろいろ便利なことが多いからだ。
まずバトルバランスを考えること自体は意味があるが、これはあとでもやれる(最初に作る必要はない)。
つまりレベルとバトルバランスを最初から結びつけて作業を始める必要はない。

ちなみにここでバトルバランスと書いたが、これが本当に戦闘である必要は全くないことも意識しておくべきだ。

次にレベルとプレイタイムには強い相関がある。だから想定レベルはプレイ時間に置き換えられる。
ではプレイ時間とはなんなのかと考えると、何らかのリソースの獲得のために投入される時間と見なすことが出来る。
例えばユーザーの成長を促す経験値、ゲーム内の通貨、特定のアイテム、互いに合成することで強化が可能なユニットやカードなど、ユーザーのプレイ上の制限を解決する様々なモノを獲得するために必要な時間だと考えられる。
だから時間あたりに手に入られるリソース量(TNL)とレベルの関係を組み立てて、バランスを作る方が、より合理的だと考えられる。
というのが第一点。
また、もうひとつ大きな理由がある。
この形に変形するほうが、F2Pによくあるスタミナ型のゲームに簡単に対応できる。
スタミナ型のゲームの基本的なルールは以下。

  • プレイヤーは「スタミナ」と呼ばれるリソースを持っている。
  • スタミナは上限がある。
  • なんらかのプレイヤーアクションを行うと、いくばくかのスタミナが消費される。
  • スタミナがプレイヤーアクションを実行できる量がない場合はアクションは実行できない。
  • スタミナは時間で回復する。

これが一般化したのはかの有名なZyngaのfacebook gameで、海外ではスタミナではなく”Energy”がよく使われる。
上記ルールに加えて、中国ではプレイヤーアクションに失敗したら、スタミナが戻ってくる場合があるとか、スタミナはいつ減算されるかとか、スタミナは課金可能か? とか、韓国のようにスタミナとわかりにくい形のスタミナ実装はどう扱うか? とか細かいルールは実にイロイロあるが、ともかくスタミナ制は「一回のセッションでスタミナを幾ばくか消費してなんらかのリソースを手に入れるメカニクス」と解釈することが出来る。
このスタミナは(無課金での)一日のプレイ回数の上限、すなわちプレイタイムを決定するので、スタミナ型のゲームでゲームバランスを取る時には一日のセッション回数の上限が、一日のプレイタイムの上限で、かつ手に入れられるリソースの上限になる。
そしてこういったシステムでは、基準ユーザーが遊ぶ回数をTNLなどに置いたほうが実情に近くなるので、戦闘回数=1レベルあたりユーザーが遊ぶ回数とすれば、直接プレイタイムを把握出来るので、よりバランスが取りやすいわけだ。

スタミナのないゲームを作る場合には、ゲームデザイナーはプレイヤーがその気になれば24時間をフルに投入可能なことを留意する必要がある。
そしてゲーム内のコンテンツを消費する速度が桁違いに上がり、いわゆる廃人プレイヤーと一般プレイヤーの差が広がりやすく、一般ユーザーの脱落を招きやすいこと、レベルキャップに到達する速度差が大きいことにも留意する必要がある。
つまりスタミナの全くないゲームはいわゆる廃人と一般人の差が、スタミナありよりも大きくなるので、そこに十分留意する必要があるわけだ。

というわけで、オリジナルの桝田方式がどのようなものか説明をし、なぜそれから変化させたのかを説明したので、次は時間が把握できた状態で、どのようにユーザーシナリオを作っていくか、について書いていきたい。

LinkedIn にシェア
Pocket

1件のコメント

  • AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
    続きを早く読みたいです!!

コメントは現在停止中です。