VNCTST games 開発日誌

ゲーム開発日誌

電ファミニコゲーマー企画記事分析 #9 ダビスタ回

電ファミニコゲーマー企画記事分析のルールに従って、 http://news.denfaminicogamer.jp/projectbook/dabisuta を分析するエントリ。

まとめ

  • 既存の何か面白いもの(元記事ではスポーツや競馬等)をテーマにしてゲームを作る場合について

    • 「対象の最も面白い部分を切り出してゲーム化する」事を検討する?
    • 何も考えずに漫然とシミュレーションを作っても面白くなりづらい
  • ゲーム開発のモチベーションについて

    • そのゲームの一番魅力的な部分(だけ)を、まず最初に作り込んで形にする。これがモチベーション維持に有効との事
    • インタラクティブ開発(実際に動く部分を荒く作り、動かしてみて動作を確認するサイクルを素早く回していく開発。REPL駆動開発)の重要性
  • 「解説の面白さ」

    • ラジオとかでスポーツの解説だけ聴いていても成り立つ面白さがある
    • この「解説」の中に出てくる用語は、そのシステムの本質を推測するヒントになる
      • また、ゲームで同様の表現を使う事による各種の効果も期待できる
    • ゲーム内アイテムの解説等が面白いゲームも多数ある、そういう方面でも役立つ
  • パラメータの抽象化

    • 基本的なパラメータはなるべく数を絞る。増やさない事
    • ある一つのパラメータは長所と短所を兼ねるとより良い
      • スピードのパラメータが高いほどスタミナの消費が激しい、攻撃力のパラメータが高いほど弾薬の消費が激しい、等々
    • 「打率」はあくまで結果なので、これをそのままパラメータとしてしまうのはよくない。各種のパラメータから「ヒットするかどうか」を決定し、それがたくさん試行された結果、「打率」を算出するようにすべき
    • パラメータの数値を敢えてユーザに見せない手法
      • ユーザが「これとこれはどっちが強いのか?」と自分で考える面白さにつながる
      • 一方で、取っつきにくくなるデメリットも
    • 敵など、キャラを大量に量産する場合にパラメータが多いと大変
    • パラメータの数は少なくても、自分でも最適解が分からないぐらいの複雑度を持つように組む必要がある
      • 最高スコアの理論値が計算等で分かってしまったりするのは面白くない
  • プレイヤー人数が多くなれば、製作者の想定を越えるプレイヤーが必ず出る

    • ものすごく低確率で、ものすごい事が起こる余地を入れておく(三連複で100万馬券が出るとか、キャラメイクでボーナスポイント99が出るとか)
  • レース物は基本的に、後出しの方が有利

    • 最初に全力を出す戦略の場合、そのままゴールまで維持できなかった場合は疲労によって動けなくなり、ペースを維持していた競争相手に追い抜かれる
    • 前半はペースを維持し、ラストスパートのタイミングで全力を出す戦略であれば、疲労して動けなくなるタイミングが勝負の決着後となる為、基本的にはこれがベストの戦略となる
  • 『いじるのはキリがないから、「今のイイ感じだったから、これでいっか」みたいな見切りも大事』

引用パート

競馬の面白さの何をフィーチャーしたらいいかと考えて、僕は競馬を最も面白くしているのは「実況」だろうと思ったんです。だから、そこから作った

実際、競馬というものの盛り上がりは、テレビの実況による部分が相当にあると思いませんか

野球だって解説がなかったら面白くない

実際に「この馬の脚はすごい」と言われながらレースシーンを見ると、本当にすごく見えてくるわけです

われわれ競馬好きからしても、確かにレースでの実況に一番のカタルシスがあるわけですよ。そこに最もインパクトがあると判断されたときに、薗部さんは迷わずそこから手を付けられた

プログラマ視点でもう一つ言うと、そもそも目に見えるモノがないと開発が楽しくならない

計算式だけを書いているゲーム開発なんて、つまらないですよ。まずは自分の目で動くものを見て、出来ぐあいを確認できるからこそ、発想が形になりだして手が動いていく

そういう気持ちが高まる作り方をするのが、そもそも大事でした。自分でやってみれば分かりますが、やる気が全然違います

まずは魅力的な部分を最初に作り込んで形にする、というのは確かに開発の考え方として大事

まずは、色々なアナウンサーのセリフをメモしていきました。他にも、競馬にまつわる言葉がありますよね。「この馬は勝負根性がある」「この馬は気性が荒い」みたいな、そういう要素を抽出していくんです。そこから、馬の強さというものを自分なりに組み立てたんです。例えば、「ナタの切れ味」という表現があったときに、その言葉で表現される強さとは何か?――それを考えぬくんです

――つまり、実況の言葉や競馬用語を収集して利用シーンを調べ上げて、そこから逆にそういう言葉が登場するようなアルゴリズムを組み立てていった

汎用性があって、しかしフレーズ的に何回出てもウザくならないものを残していく作業が大事になる

長々と同じセリフを読むのはイヤじゃないですか。極力シンプルなものにして、プレイヤーがその場面に応じて想像力で補えるものに磨いていきました

馬のパラメーターをあまり数字で見せたくなかったんですよ。そこをセリフによって曖昧に伝えられたら……という思いもありました

基本的なパラメーターは4つだけです。馬の「スピード」「スタミナ」「勝負根性」「気性」、それだけ

皆さん、どうもパラメータを増やしたほうが楽だと思いがちなように見えるんです。でも、専用のパラメータを作るのは良し悪しだと思いませんか。だって、その数値だけで結果が予測できてしまうでしょう? そうなるとゲームに意外性を作るのが非常に難しくなって、かえって大変になるはず

ダビスタ』は、あの先行勢がタレて差し込みが決まるようなゴール前のシーンも、全て4つのパラメーターとアルゴリズムでまかなっている

自分で競馬を見ているときに、たまにワープしてくるような速度で出てくる馬がいるじゃないですか。あの驚きをアルゴリズムで再現したいわけですよ。それが可能になるように徹底的に調整していく

例えば、打者の場合なら「打率」そのものをパラメーターにしちゃう人がいますよね。でも、「打率」って結果にすぎないじゃないですか。大事なのは、なぜこの人が3割になるのかを、他のパラメーターで説明すること

一口に3割バッターと言っても、そうなる理由は様々でしょう。  選球眼が良い人もいれば、長打力がある人もいれば、足が速い人もいる。そういう様々な要素の組み合わせで、結果的に3割バッターが一定程度生じてくるようにアルゴリズムを考える

逆にその調整を失敗すると6割打者が何人も登場してしまったりする

野球の場合は、スポーツ新聞の試合結果だけで楽しいじゃないですか。これが野球の面白いところで、試合結果や打率のデータのような「成績表」を見ているだけで充分に娯楽として成立するんです。だから、『ベストプレープロ野球』では選手の成績にフォーカスして面白さを作って、試合のシーンをスキップできるようにした

でも、サッカーはそうじゃないでしょう。点差も1対0とかだし、リアルタイムで試合に立ち会ってギリギリの攻防を観るのが明らかに楽しい。だから、『ダビスタ』みたいにアルゴリズムで試合のワクワク感を再現するのが大事なんだと思いました

最近もカーリングにハマっていたときに、カーリングの面白さを分析して、それを抽象化してカードゲームにしてみたんです。見た目はカーリングのゲームには見えないのですが、カーリングの面白さを構成する要素で出来上がっている

最初にも言いましたが、僕は『ダビスタ』を作るときに「言葉集め」からはじめたわけですよ。  そうして瞬発力やスタミナのような馬の強さを表す言葉を集約していったときに、この4つのパラメーターによる表現に集約されたのはあります。一口に速さを表現するにしても、「瞬発力」とか「キレがある」とか色々な言い方があるわけで、それを考えぬく

瞬発力とは何を表現する言葉なのかということを徹底的に考えたわけです。「スタミナがある馬」という言葉があれば、スタミナとは何かをプログラムでの表現まで含めて徹底的に考える

さっき言ったレースにおける4つのパラメータそのものには「距離適性」は入っていないでしょう。でも、明らかにリアルの馬には距離適性が存在している。そのときに、「じゃあ、この馬は1800M~2400Mで適性があることにして……」と距離適性のパラメータを一つ増やすのは一見、楽に思えるでしょう。でも、そんなゲームは底の浅さを見ぬかれてしまう

あくまでも、スピード・スタミナ・気性・根性が作用する中で、1800M~2400Mに強い馬という存在が生まれてくるアルゴリズムを試行錯誤する

例えば、スタミナもスピードもMAXの馬がいたと仮定しましょう。すると、その馬は1200M~3600Mまで全部走れてしまうわけで、距離適性は消えています。逆に言えば、ここに距離適性の本質が隠れていそうだと見えてきます

そこで僕は――まあ別に隠してもいないから言ってしまうと――「スピードがあるほうがスタミナを消費する」という条件が隠れているんじゃないかと考察したわけ

現実にどうかは分けて考えましょう。我々にとって大事なのは、実際にどうなっているかを突き詰めることではなくて、実際の姿にどう近づけていくかですよ。こういう話も、僕が馬を観察して見つけてきたというよりは、むしろ現実に近づけるためにプログラムをいじる中で、ひねり出してきたもの

プログラムというのはパッと閃くようなものではないんです。もういじくり回して、こねくり回して、それでもダメだということもしばしばです。最初にレースの部分から作ったという話をしましたが、そもそもこういう作り方をしているので、僕は実際にレースの場面を見ながら調整していくしかない

基本的には「スピード×スタミナ」の四角形の面積が最大の馬が強いという考え方になりますよね。しかし、問題はスピードが変化していくわけで、そのときにどうしたらこの面積が最大になるのかが馬によって違ってくる

僕のしているのは現実の競馬の話ではないのだけどもね。ただ、図形を描いて、どの辺でスタートするのがベストになるのか、さらに騎手の能力を掛けあわせたらどうなるのか……みたいなことは延々と考えています

ただね、こういうレース物というのは、本質的には後出しジャンケンが強いんです。例えば、競輪なんかは先に行った人が必ず不利になるんです。理由としては風の抵抗も大きいけど、やはり足の筋肉を最初に使ってしまうと、後から回復できなくなるのが大きいらしい

後出しが本当は強いはずなのに、ポンと一頭行っちゃう馬が出ると、なんだか強そうに見えるので、「捕まえなきゃ」と馬たちが脚を使ってしまう。そうなると、なし崩し的に一番何もしなかったやつが勝ってしまったり

本来、そのへんは騎手の役割なんですよ。  言うことを聞かない馬は、先にゴーサインを出してしまうと、いきなり幼稚園の100M走みたいに全力疾走をしてしまう。だから、途中で1位を抜けなければタレるしかないんです。とすれば、そういう馬にはゴーサインはギリギリまで待たなきゃいけない。でも、馬が賢いと話は変わってきて、最初にゴーサインを出しても途中でイキが抜けるから、前にいることが有利になる。まあ、奥が深い

特にパラメーターは、もっと減らせないかと常に考えていますね。レースのパラメータも絞りに絞って最終的に4つにまとめたのですが、今でも常に3つにできないか考えています

ライバル馬のパラメーターを2000頭、3000頭と作るときにパラメーターが多いと大変

僕の場合は、まずはライバル馬同士の試合でバランス調整をしていくんです。でも、そういう色んな脚質の馬が揃うときには上手くいくのですが、ブリーダーズカップのように、全部「逃げ」や「追い込み」にした場合にどうなるかというと怪しい

もしかしたらパラメータを増やして、ユーザーが面白がるものが作れる可能性はあるかもしれないですよ。でも、その場合でも僕はやらないと思います。だって、自分が面白くないから

自分でも最適解が分からないように作っているからですよ。作者が何が起きるかを把握できているような浅いプログラムだったら、すぐにユーザーさんたちには底が割れてしまいます

ユーザーは100万人単位で遊んでくるんですよ。この1対100万というメチャクチャな戦いにおいて、せいぜい自分が想定していた程度の範囲で面白さを作ったって、そんな浅はかなものは絶対に勝てっこないと僕は思いますね。  むしろ自分の想像をユーザーが超えていく余地を常に残すことでしか、100万人を面白がらせることなんて出来ない

僕としては、3連複で100万馬券を出した報告なんかは嬉しいわけですよ。だって、そんなのほとんど最低人気の馬から3頭が、1~3着になるくらいでしかあり得ないでしょう。でも、そういう余地を残したプログラムを作っておけば、長い目で見るとあり得ることで、実際にそれが起きたわけです。そういう話こそが面白いのであって、そんなものはこっち側で完全に制御していては作れません。  だから、すごい強い馬が出来る確率にしても、確かに低くは抑えているわけですが、その可能性を僕は完全に潰したくはない

ポケモン』にバトル検定という、プレイヤーのバトルを評価して得点を出す施設があるんですけど、その最高得点は僕にも絶対に計算できないし、たぶんユーザーも計算できていないはずなんですよ。  そういうものを作ると、さぁ最高点はどこまで行くんだろうと、こっちもワクワクするわけですよ。逆に最高点の理論値がわかっていると、なんだか興ざめしてしまいます。それはユーザーも同じ

ユーザーは大体、我々の上をゆくんですよ。だって、束になってかかってきてるんだから

(カメラが一着馬固定ではないという話について) 実は、そこに調味料をいっぱい入れているんです。2番目の馬の方が勢いが良くなれば、そこにカメラを動かしたりね。なかなか大変ですが、ここの作り込みが臨場感を生む

ソリティ馬』は寝ている間に1000回くらいまわしてくれるプログラムを書いて、翌朝に先行・逃げ・差し・追い込みをチェックして、「スローペースのときは先行と逃げがこのくらいの比率になるように……」みたいにパラメータ調整を重ねていった

僕の場合は、自分でライバル馬を走らせてみるんです。すると、「短距離はパラメーター上ではこいつが絶対に強くなる。しかしなぜか勝たない」みたいな問題が出てくるんです。そこを、程よく勝てる程度に何度も繰り返しながら調整していく感じ

結局、自動で回してもわかるのは、勝負の「結果」だけなんですよね。こういうレースだったという「印象」は、やはり自分で見て感じるしかないわけ

いじるのはキリがないから、「今のイイ感じだったから、これでいっか」みたいな見切りも大事

僕はあまりユーザーに面白さを押し付けたくなかったんです。「ほら、ここが面白いでしょう?」と製作者が指示を出してくるのは、どこか違う気がする。そうじゃなくて、「ユーザーがどこに面白さを見出すのか」が大事なんだと思う

僕にとってはプログラムを作る行為そのものが最高のゲームで、基本的には開発という行為そのものが楽しくて仕方ないんですね。だから、それを答えがわかりきったルーチンワークにしたくないんです。  自分でゲームを攻略しながら、プログラムを書いている気分で作る。それが僕のやり方