ゲームプログラミング/バランス調整

出典: フリー教科書『ウィキブックス(Wikibooks)』
ナビゲーションに移動 検索に移動

バランス調整[編集]

ゲーム作家の体感の難易度はズレやすい[編集]

プログラミングというよりゲームデザインの話題かもしれないが、そのゲームの簡単さ・難しさといった難易のバランス調整も、コツがいろいろとある。

結論から言うと、やや簡単めに調整されたバランスでゲームを作るのが安全である。

書籍『ゲームプランナーの新しい教科書』(STUDIO SHIN 著、翔泳社)でも、作者がやや簡単だと思うくらいに作ると良くなる場合が多いという経験則が語られている[1]

一般的にゲーム作家の側は、自作のゲームをプレイしたときの体感の難易度(なんいど)が、(他のプレイヤーよりも)自作ゲームを「やさしめ」に感じてしまいまちである。

つまり、本当は難しいゲームなのに、作家自身は「やさしい」と錯覚しやすい傾向がある。なお、このを現象を俗に(ぞくに)「作者バイアス」と日本では言う。


このような現象の起きる理由はおそらく、下記のような理由であろう。

・なぜなら、作家自身は攻略法を知っている。
・ また、作家は、「自分のシステムこそ合理的」だという先入観に基づいて作っているので、自作ゲームだけに最適化したゲームプレイのスタイルを取りがちである(しかし、一般プレイヤーはそうではない)。


作家ごとにゲームのシステムは多様である。だが、不慣れな新人作家は、そういう事を知らず・気づかず、過去に自分のプレイした人気ゲームだけに特化したスタイルをとり勝ちである。

たとえば、RPGなら、人気シリーズであるドラゴンクエストのシステムしか想定せず、結果として不慣れなRPG作家はドラクエのシリーズでしか通用しないようなプレイスタイルを前提に難易度の調整をしがちである(もしくは、初期ドラクエの前提になったウィザードリィなど)。

しかし、世間には、まったくゲームシステムに対する考え方のゲームもある。

たとえば、ドラクエでは、戦闘を繰り返してザコ敵を倒すことでキャラクターが成長するレベルシステムや経験値システムがある。しかしRPGでも「サンサーラナーガ2』というゲームは(レベルシステムがあるが)キャラクターがほとんど成長しない。戦闘をしただけで人間が何十倍も強くなるのはリアリティが乏しいという発想で、サンサーラナーガ2では、レベルアップしても、あまりキャラクターが強くならない。

なのに不慣れな作家は、RPG制作ならドラクエだけを前提にしたシステムを作りがちであり、その結果、不慣れな新人フリーゲーム作家などはクソゲーなのに経験値かせぎに時間を何十時間もかけないとクリアできないという大クソゲーを作りがちである。


文芸の作家志望の新人などでも、つまらない作品なのに長編の原稿とかを書かれたら、読ませられる編集者や査読者は、つらい。

というか、そもそも実績の乏しい新人には、そういう長編の仕事は来ない。長編を書いたからって「偉い」わけでなく、信頼のある作家に「では、次は長編を書きましょうか」と編集から依頼が来るのである。まったく実績のない新人作家が長編を作っても、編集などにとっては迷惑なだけで、偉くない。

新人は短編から作るのが安全である。ゲームなら、難易度はあまり高めにしないのが安全である(例外は、レトロゲームで難易度の高いゲームの再現ゲームくらいか)。


・ また、ゲームを作るような趣味や職業の人は、当然ながらゲームプレイに掛けられる時間も長いので、最初は不慣れでも、1日に何時間も練習しているうちに上達しがちである。しかし、世界には自分と職業や趣味の違う人もいて、自分よりもゲームに投ずるプレイ時間の少なめの人もいて、週に1~2時間しかプレイしない人や、月に2~3時間くらいしかプレイしない人もいる。世間には、ゲーム趣味以外に釣りや読書やサイクリングやイラスト制作やDTM作曲などの趣味の人もいるのである。
不慣れなゲーム作家は、こういった事を忘れがちである。自分や自分のまわりの人がゲーム趣味なので、ゲームに投ずる時間を長いことを前提にして、ゲーム難易度を調整しがちであり、その結果、初心者やゲーム以外の趣味の時間の長い人にとっては「難しめ」の難易度のゲームを、平均的なノーマル難易度のつもりで作りがちである。

ゲームにかぎらず、文芸でもイラスト趣味でも、こういった事を忘れて、狭いコミュニティ内の内輪ウケばかりに特化していって衰退していっている文化は多い。そうならないように気をつけよう。


・ また、プログラム的な作業をするゲーム作家はパラメータ調整の思考が好きなので、パズル的にアレコレと戦略を考えるのが好きなので、バランス調整でもパズル的に戦略などを考える要素をプレイヤーに要素を要求しがちである。そういうのも楽しいかもしれないが、しかし、度が過ぎると、作家の想定した単一スタイルだけにプレイのスタイルを制限しがちになる。
世間には、表面的には多様なプレイに対応したゲームシステムを謡っていても、バランスの制約がキツすぎて実質的には「特定のプレイスタイルでないとクリアできねーじゃん」と言いたくなるような糞ゲームも多い。そうならないように気を付けよう。


大学受験の数学の二次試験とかの問題でさえ、証明さえ出来ていて計算があっていれば、解法は自由なわけです。
ゲームなどの娯楽ジャンルのクリエイターを自称するのでしたら、せめて、受験数学よりかは上の自由度を目指しましょうよ(笑)。早い話、作者が馬鹿(思考力が低い、という意味)だと、クソゲーになります。


ともかく、上述のような理由で、作家側は、体感の難易度が、本当は難しめのゲームなのに「やさしめ」に感じがちである。

実際、日本のゲーム史でも、1990年代の前半ごろは、ゲームの難易度が「むずかしめ」に調整されがちであった。しかし、その結果、世間では「最近のゲームは難しい」と感じる人が増え、日本のゲーム人気は一時期、衰退し、アニメ産業などに人気を取られる事態になった。


さて、作者バイアスでバランスが分からなくなるのは作者だけではなく、テストプレイヤーやデバッガーも、そのゲームに慣れてゆくと、次第に感覚が一般プレイヤーとズレていき、イェストプレイヤー達もゲームの適切なバランス側が分からなくなっていく。

かといって、テストプレイヤーの人数にも限りがあるので、ゲーム作者は、たとえ自作ゲームのバランス調整が不完全でも、最低限の調整をしたら、もう「えいやっ」とゲームのver1.00および以降バージョンを出さざるを得ない。


教育的視点でのバランス調整[編集]

バランス調整を成功させるために対策として、いくつかありますが、簡単に言うと、プレイヤーに習得してもらいプレイ技法を、ある程度の想定をしておくのです。

そして、プレイヤーがそういうプレイ技法を習得して実践できていたら、敵キャラを簡単に倒せるようにするのが良いでしょう。


ただし、このように教育的な視点が有効な場面は、あくまでバランス調整だけでしょう。企画などのアイデア出しは、教育的視点ではなく、もっと大衆娯楽エンタメ視点で行うのが定石です。(なお一般的に、ゲーム業界にかぎらず企画手法の定石として、面白い事どうしの組み合わせ、というのがあります。)


さて調整の話題に戻ります。

たとえば、アクションゲームの調整なら、

もし敵が飛び道具を使ってくるなら、まずプレイヤーは物陰に隠れて移動して近づくとか、あるいはプレイヤーも飛び道具で応戦するとか、そういうプレイ技法が必要でしょう。

そして、プレイヤーがその技法を実践できていたら、その敵を簡単に倒せるように難易度を調整します。

たとえば、飛び道具を使ってくる敵は、そいつに攻撃を当てるまでは難しいが、しかし敵の防御力を低くしておいて、もし敵が(プレイヤーからの)攻撃を受けたら、敵はすぐに倒されてしまう・・・のような強さの敵としてパラメータ調整しておくのが良いでしょう。

つまり、プレイヤーに教えたいスキルとして、そのアクションゲームを通して、飛び道具を使ってくる敵の対処法を教えるのです。


もし意味もなく、その敵の弓使いがボス敵でもないのに、

作者が浅知恵で単に「ゲームが難しいほうがウケるだろう」と誤解して、

道中で何体も出てくるザコ敵に飛び道具を使わせて、なおかつ、その弓つかいの敵が頑強で防御力が高くって、何十発も攻撃を当てないと倒せない敵だったら、 プレイヤーには面倒くさいだけですし、作者は馬鹿です。


たとえるなら、読者の大人は、(すでに自分が解法を知っている)小学校の算数ドリルを何十問や何百問も解きたくないでしょう? ご褒美がないのに、そんな簡単だけど面倒なドリル、解きたくないでしょ?

ゲームプレイヤーも、それと同じです。

どうしても、そういうメンドウなだけで新鮮味の無い敵を出すなら、その敵を倒したあとに得られる(ゲーム内の)報酬を増やしましょう。スコアを増やすとか、経験値や獲得ゴールド(金額)を増やすとか。


なお、余談だが、「難易度」の「高い」「低い」の意味は、

「むずかしい」=「難易度が高い」
「やさしい」=「難易度が低い」

である。


ゲームを難しくする目的は、プレイヤーに創意工夫を呼び起こすためです。創意工夫を呼び起こさない難しさは不用です。

そして、創意工夫はどういう時に生まれてくるのかというと、

手持ちの手段がたくさんあり、
しかし制限がある場合です。
制限の必要性

制限の必要性とは、たとえば、ゲーム中での主人公が丈夫で死にづらいのは構いませんが、しかしどんなに敵の攻撃を食らっても死なずに倒れずに不死身なのは駄目です。

また、主人公の所持金が多いのは構いませんが、しかし所持金が無限大なのは駄目なのです。

また、敵の動きが少し単純なのは構いませんが、しかし、プレイヤーが油断しすぎているのにプレイヤーが負けないのは駄目です(たとえばアクションゲームで一時停止ボタン(ポーズボタン)を押さずにトイレに行ってウンコを数分してきても、ウンコから戻ってきてもキャラが負けてないのは明らかに駄目)。

このような駄目な例のゲームのままでは、プレイヤーが創意工夫をしなくなってしまいます。


このため、そのゲームでのゲームオーバーの条件を、作者は早めに決めておきます。あまり気が乗らないでしょうが、しかし、ゲームにはゲームオーバーや敗北の条件が必要ですし、プレイヤーには敗北を回避するように努力してもらわなければなりません。

手持ちの手段

さて、手持ちの手段がたくさんあるとは、たとえば、アクションゲームなら、主人公のもてる武器の種類が、槍や弓矢のほか、トマホーク(投げ斧)や鞭や鎖鎌や鈍器やブーメランなど色々とあれば、敵の種類によって、攻撃を使い分けられます。たとえば、空を飛ぶ吸血コウモリを倒すには「弓矢やトマホークで攻撃してみよう」とか、プレイヤーに創意工夫が生まれます。


手持ちの手段が1つしかないのは、危険信号です。 どんなゲームでも、解法が1通りしかなくなったら、そのイベントの設計に失敗しているかもしれないと、気をつけるようにしたほうが良いでしょう。

もしストーリ上、どうしても1通りの手段にせざるを得ない場合は、いっそ自動進行イベントにしてしまい、プレイヤーはそのシーンでは操作できないようにしrてしまうなどの方法もあります。

マンガ・アニメのバランス調整との違い[編集]

マンガやアニメのバランス調整というか、物語での敵の強さの見せ方と、ゲームでの敵の強さのありかたは、少し差異があります。

マンガ・アニメだと、たいてい強敵は、主人公がなんとか苦戦しながら倒せるギリギリの強さになっています。しかしゲームでは普通、このようなギリギリの強敵にしてないほうが安全です。

マンガやアニメの強敵よりも、やや弱めにしておく必要があります。そうしないと、プレイヤーに創意工夫が生まれません。

マンガやアニメでは、一回の戦闘での強敵の倒しかたが一通りしかなく、いちばん読者に魅力的に見える奇想天外・破天荒な倒しかたで、敵を倒します。なのでマンガやアニメでは、ギリギリ倒せる強さのほうが良いのです。

しかしゲームの強敵では、多くのプレイヤーの、それぞれ異なる色々なアイデアに対応した倒し方を何通りも準備する必要があるので、ゲームでの強敵の強さは、ギリギリ倒せる状態よりも少し弱めにする必要があります。

調整のさいの順序[編集]

さて、実際にバランス調整をする段階になると、何種類ものパラメータを調整することになります。

たとえばRPGの場合、戦闘の難易度のバランスを決めるのは、味方キャラの能力値などといったプレイヤー操作キャラクターの能力、装備品の攻撃力や防御力などのパラメータ、敵の強さ、その探索エリアの回復ポイントの有無や、探索エリアの罠(ワナ)の威力の程度などのマップ形状など、あるいはそもそものダメージ計算式など、多様な要素の影響を受けます。

これらを、もし、すべて同時に調整すると、とても大変になりますし、おそらく同時調整は不可能です。


なので、一般に、目立ちやすい部分は、調整前に、先におおよその数値を決めてしまいましょう。

そして、調整の実行では、ほぼ1種類のパラメータだけに限定して調整できるようにしましょう。


フリーゲームや同人ゲームなどでも、よく開発版未公開の部分(たとえばゲーム後半部など)を、リバースエンジニアリングしてみてデータの中身をのぞいてみると、データの種類によって、ほとんど完成版と数値が同じ種類のパラメータもあれば、まったく数値の違うパラメータもあります。

操作キャラクターの基礎能力値や、装備品の能力は同じなのに、敵の強さが違っていたりします。

おそらく、プレイヤーに見える部分(操作キャラクターの能力値など)を基準にして、プレイヤーに見えない数値(敵の強さ)のほうでバランスを調整するというテクニックでしょう。


また、商業作品でも、たとえば攻略本やファンブックなどに書いてあるゲーム開発裏話などを見ると、RPGでは、(プレイヤーからは数値の見えない)敵の強さのほうを動かすことで、バランスを調整するという事例などもよく紹介されています。よくある話が、最終ボスなどの能力値です。原理的には、敵側の能力値ではなく、味方の能力値で調整したり、あるいは装備品で調整したりしてもイイはずですが、しかしよく開発裏話に出てくるのは、なぜか敵側の能力値の話題ばかりです。(ただし、あくまでRPG限定の話題。アクションゲームなどでは、違うかもしれない。)


また、こういった調整順序の前提として、調整はゲーム序盤から順番に、ゲーム後半に向かって調整していくしかありません。

そのため、古いゲームなどでは、よくゲーム後半で、調整不足のために、極端に難しかったり、あるいは逆にあっけなく簡単すぎる後半だったりなどの話題も、よく聞きます。

現代のフリーゲームでも、開発版(ver0.01~ver0.99)の非公開部分などをリバースエンジニアリングして調べると、やはり、ゲーム後半の非公開部分のバランスは、完成版とで、敵の能力値などが明確に違う場合もあったりします。(それどころか、非調整のモンスターのHPが0とか1だったりするような事態すらある。敵HPが0だと遭遇した瞬間に敵が自動的に全滅すると言うナゾの現象も発生する。)


さて、プレイヤーに目立つ部分(たとえば味方キャラの能力値や装備品の性能など)を基準にして調整するといって、けっして全く数値をイジラないというワケではないのです。あくまで、(調整による変動幅の大きい敵能力値と比べたら、)「比較的には、味方キャラ関連の数値は、調整による数値の変動の幅が小さめ。敵の能力値は、調整による変動の幅が大きい。」という事にすぎません。


つまり、けっして、すべての調整を、同じ思い入れで調整しようとしては、ならない。なぜなら、それはほぼ不可能だし、時間が膨大に掛かるからである。

なので、事前に、優先的に実現したい機能を明確に決めておく必要があります。

なので設計のさいに、優先度べつに到達目標を作っておく必要があります。


欧米の経営者が、経営哲学でよく「目標はすべて実現しようとするのではなく、優先度の差をつけろ」というのは、おそらく、こういう事を言ってるのでしょう。日本人の知ってる例でも、ソニーの元経営者のハワード=ストリンガーは「アブストラクトを作れ」と日本社員に言ってたようですし(ここでいうアブストラクトとは、けっして日本語でいう「抽象」ではなく、論文とかの冒頭に書く要点の文を「アブストラクト」と言うように、要点のことであり、つまり設計の際に優先実現したい機能のこと)。米国アップルのジョブスなども似たような事を言っていました。


背景となる工学的な考えかたとして、下記の「パラメータ・バリエーション」という考えかたがあります。「パラメータ・バリエーション」とは何かと言うと、複数の変数からなる多変数関数のようなモノの適正値を探すときに、とりあえず1種類の変数だけを実験的にイジッてみて、その後に測定してみることで調整していく方法です。フレデリック・テイラーという機械工学者が、工作機械の研究での旋盤加工の回転速度・送り速度・直径・角度などの他変数の最適条件を探す研究の際に、こういう探求手法を1880年ごろに提案しました。[2]

ただし、あくまでテイラーのこの手法そのものは、研究の方法でしかなく、つまり活用可能なのは大企業の工場のような十分な予算と研究員のいる場所でのビッグビジネス的な企業での科学研究的な方法なので、中小零細の企業での設計の実務では、そのままでは合わない方法かもしれないので、私たちは適宜、自分の勤務先の状況に応じて「パラメータ・バリエーション」をアレンジして応用する必要があるのでしょう。

歴史的には、パラメータ・バリエーションの考え方のほうが古く、ストリンガー経営哲学やゲーム調整方法よりも古いですが、しかし歴史の順番どおりに学ぶ必要はないです。学習はたいてい、現代の実務的な方法から学んでいくほうが効率的です。

もし数学の用語に読者が詳しいなら、「パラメータ・バリエーション」とは、実験による検証において「偏微分」(へんびぶん)や「変数分離法」を合わせたような、謎(なぞ)の調整手法を、解を求める代わりに擬似的に実験(ゲームの場合ならテストプレイ)で用いたモノという表現でしょうか。
ちなみに物理学の解析力学という分野にある「変分法」(へんぶんほう)という計算手法を英語でバリエーションというが、しかし、ギルブレスのいう「パラメータ・バリエーション」は明らかに(物理学の)変分法とは別の手法である。


各論[編集]

成長曲線の設計[編集]

RPGで、たとえばレベルが上がったとき、「ちから」が何ポイントあがるとか、「すばやさ」が何ポイントあがるかとか、ああいうのは、どう設計するのでしょうか?

ゲーム作家によって、パラメータの計算式をどういうふうに設計したいかが違います。

いちばんラクな方法は、ツクールやウディタなどの標準設定のとおりにしておく事です。


いっぽう、もし独自の計算式を使いたい場合や、自分でゲーム開発ツールを開発する場合には、自分で設計する必要があります。

そもそもレベルの上限をいくつにしたいかすら、作家によってバラバラです。レベル100までにしたい人もいれば。レベル1000とかも可能にしたい人もいますし、レベ10くらいで打ち止めにしたい人もいます。


では、たとえばレベル1からレベル40まであるゲームの場合、どうすればいいでしょう?


考え方[編集]

序盤でレベル1の主人公の攻撃でそのストーリ-地点での標準的なモンスターにダメージ5を与えたとして、レベルアップでレベル2でダメージ10になったら2倍ですので印象に残ります。


ですが、ゲーム終盤でレベル30主人公がダメージ150くらいを与えているあと、レベルアップでレベル31になってダメージ155を与えるようになっても、なんの印象も感じませんし、そもそもダメージ量がアップしたかどうかもプレイヤーが気づけないかもしれません。

つまり、単に等差数列のように上昇するだけでは、駄目な場合が多いのです(ダメージ計算式の設計にもよるが)。

これはつまり、単一の1次関数だけではダメな場合が多いという事です。


かといって、レベルアップするたびに最初を基準に2倍、4倍,8倍,16倍としていくと、

レベル32あたりで、もうダメージ 4294967296 くらいになってしまいます。(2の32乗が 4294967296 なので )

なので、指数関数も、能力曲線としては、ほぼアウトです。(ただし経験値の曲線としては、経験値曲線は多くのゲームで後半はインフレ気味なので、使える可能性がある)


なので、大まかな解決策として、

・1つの関数だけでなく複数の関数を連結する方式
・2次関数や3次関数など、増加率が1次関数を超えるが、しか指数関数よりかは増加スピードの小さい関数を使う方式
・数式で表現するのを諦め(あきらめ)、全部、各レベル時の基準の能力値を作者が数値を手入力する方式(上限レベル数がせいぜい10程度の小さい数値の場合のみ)

などが解決策になります。

もしくは、上記を組みあわせた方式が考えられます。

ゲーム序盤は、作者が直接、基準の能力値をプログラムに手入力しておき、ゲーム中盤からは数式による能力値に切り替えるなど、です。



重要な知識1

解決策よりも先に、まず知って置くべき重要知識が、いくつか、あります。

それは、現在のネット全盛の時代、調整によるバージョンアップの際、能力値も再計算する必要があるという事です。

たとえば、昔のゲームでは、レベルアップの際の能力上昇の幅がランダム(偶然)なゲームがありました。

しかし現在のネット環境のゲームにおいて、こういうランダムな能力上昇のレベルアップシステムを作ると、バージョンアップ時の管理が、かなりメンドウです。

なぜなら、もしランダムな能力上昇だと、いまやバージョンアップの再計算のさい、更新後の数値がランダムに決まってしまうからです。

つまり、もし完全にレベルアップ能力上昇のランダムな能力上昇システムを作ってしまうと、たとえば、ver1.00からver1.01に更新するのをセーブデータを3個つくって、3回別々に更新を試してみて、3種類とも同じver1.01であるにもかかわらずに更新後の数値の能力値が異なっているような事態になってしまうので、奇妙です。

なので、たといプレイヤーから見たらランダムな能力上昇値に見えても、プログラム内部では能力曲線は(ランダムではなく)確定値、確定した数式でなければなりません。

とにかく、バージョンアップの再計算の際、確定した結果になるようにしなければ、なりません。


現代では、1980年代や90年代のファミコンやスーファミのような1回だけ販売すれば更新しなくて済んだ時代とは、もはや違うのです。


また、バージョンアップの再計算により、攻撃力や守備力などの数値も変動し、現在レベルや経験値から再計算するので、なので、「攻撃力」「守備力」などのすべての能力パラメータは、バージョンアップ時に現在レベルの値から再計算できるような仕組みに設計しなければなりません。


なお、ゲーム中のいつのタイミングで能力値を再計算をするのが作者的にラクかというと、セーブデータのロード時に再計算してしまうのが、いちばん簡単で管理もラクです。

実際、たとえばアクションRPGなどのフリーゲームなどをデータ改造でメモリ書き換えなどの改造をしてみて能力値を書き換えてみても、ロード時などに、すぐに能力が現在レベルの数値をもとに再計算されてしまうフリー作品も、いくつかあります。(たとえばステータス上昇時に「ピコーン」と音のしたりステータス下落時に「ボンッ」とか音のするゲームの場合、レベル以外の「攻撃力」「守備力」などの(レベル以外の)能力値のデータ書き換えすると、ロード直後にピコーンと音がしたりボンッと音がしたりして、ステータス画面を見ると改造内容とは違った内容のレベル相当のステータスに戻っていたりするような作品もいくつかある。)


また、バージョンアップする際も、たとえばver1.38にアップする場合、必ずしもプレイヤーの皆が、直前のver1.37から更新するとは限らない、というような事にも気をつける必要があります。

たとえば、ver1.20とver1.37とでは、もしかしたら同じキャラの同じレベルでも「攻撃力」などの能力が違っているかもしれません。

もし、(ver1.37の次バージョンである)ver1.38へのバージョンアップ時に、更新前バージョンの(レベルではなく)能力値を基準に能力値を再計算してしまうと、更新前バージョンごとに更新後の最新版バージョンの能力値が違ってしまうので、不合理です。

なので、バージョン更新時の能力更新において再計算の基準にするべきパラメータは、(前バージョンの能力値ではなく)かならずレベル値であるべきです。


重要な知識2

表計算ソフトのエクセル、またはlibre OfficeのCalcには、多項式近似をしてくれる機能があるという事です。多項式とは、一次式や二次式、三次式、・・・といった、次数が正の整数の数式のことです。

ゲームの場合、よく、次のレベルまでの経験値の曲線で、多項式近似をする場合があります。


なので、もし数値の入力の手間を減らすために数式を表現したい場合には、

あらかじめ、成長曲線の近似の折れ線グラフをエクセルなどで作っておき、
そのあと、多項式近似する、

という順番で、目的の成長曲線の形に近い多項式を得ることができます。


成長曲線にかぎらず、ウディタでは経験値カーブ(レベルアップに必要な経験値のグラフ)を二次関数で設定できますが、しかしエクセルの機能を知らずにヤミクモに当てずっぽうで計算しても、手間が掛かりますので、エクセルの機能を知っておきましょう。


なお、一般にIT業界での実務の多項式近似では、原理的には9次でも20次でも、どんなに次数が高くても(おそらく int 整数型の限界くらいまで)計算できてしまいますが、

しかしIT業界でに実務では人間の検算などの手間を減らすために、なるべく、せいぜい2次式や3次式といった、低めの次数におさえて利用するのが、IT企業では普通です。

もし先端科学のための多項式近似なら、9次を超えるような多項式近似をするような場合もありますが、しかし、一般の企業では、そこまでの多項式近似は不要ですし、むしろ検算などの管理の手間が増えるので、9次のような多すぎる次数は嫌われますので、なるべく2次ていどに抑えましょう。


気にすべき事

成長曲線や経験値レベル曲線は、あくまでゲームの手段です。

成長曲線のプログラムだけを技巧的に作りこんでも、あまり面白いゲームになりません。

もし、上述のような成長曲線のプログラムを作るのがメンドウなら、いっそレベルはせいぜいレベル10が最高レベルとかのように、低い数値を限界にしてしまう方式もあります。

こうすれば、たった10回だけ成長曲線を具体値で直接に指定すれば済みますので、計算の必要が無くなります。


複数のキャラクターや職業のある場合

複数のキャラクターや職業ごとに成長の度合いが違う場合、すべてを別個に成長曲線を計算すると大変なので、

どれか一人のキャラクターを基準、もしくはひとつの職業を基準にして、他のキャラクターおよび他の職業は、基準値からの倍率で計算した結果を流用すると、ラクでしょう。

「攻撃力」「素早さ」「魔力」「守備力」「魅力」「運」・・・などパラメータが多い場合も、どれか1つか2つのパラメータを基準にしてしまうのがラクでしょう。


具体的な解決策[編集]

具体的な解決策は、下記のようにいくつか考えられます。


序盤は一次関数A、中盤は二次関数B、終盤は一次関数C、みたいな複数の関数を連結する方法

重要な考え方として、学校の物理の公式とかとは違い、ゲームにかぎらず産業のための応用数学では、必ずしも、システムをひとつの数式だけで表す必要は無いのです。


一次関数や二次関数は人間の計算がラクなので、これをいくつも組み合わせる事も可能です。

なお商業作品の例では、たとえばロマサガ2の戦闘中ダメージ計算式における、攻撃力とダメージの関係を表した関係式は、二個の関数の組み合わせだと言われています。


この方法の長所として、手間は増えるものの、どんな形状の曲線でも対応可能です。

いっぽう、他の方式では、対応できるグラフ形状に制限があります。


ただし、この方法(複数の関数を組み合わせる方式)の欠点として、

もし一部の関数が調整によって位置が変更すると、その両端の関数も変更する編集をしないと、グラフが不連続になるので、訂正しないと場合によってはレベルアップ時に能力ダウンしかねないリスクがあります。

もしくは、そういう編集プログラムを、最初からゲーム本体に成長曲線システムとして組み込んでおく方法もアリかもしれません。


なお、後述のような、1つの多項式で表す方式は、経験値の曲線のようにインフレするものには実用的ですが、しかし、インフレの程度の弱い攻撃力などの能力値の成長曲線では不適切になります。


数値をいくつか指定して多項式を作る方式

この多項式による方式は、経験値曲線で使われる場合があります。「経験値曲線」とは、次のレベルアップに必要な経験値を計算するための数式のグラフです。

経験値のようにゲーム後半でインフレしやすいパラメータがあるなら、多項式近似も手段として効です。

しかし、あまり、攻撃力などのインフレしづらい能力値の式としては、多項式近似は扱いが複雑なため、オススメできないです。


さて、もし二次以上の近似式を使う場合、原則的に、グラフが単調増加であるようにしてください。

もし能力曲線が単調増加でないと、このグラフを能力値の曲線だと解釈した場合、レベルアップしたときに能力ダウンすることに相当してしまい、不合理になってしまいます。(ウィザードリィとかそういう例外はややこしいので、いまは考えない。)


そして、そうやって設計した全レベルの数値(式でなく数値)を、まずエクセルなどの表計算ソフトに出力します(というか、最初からエクセルで計算するのが早い)。

そして、その結果のエクセル数表を、CSVファイル形式か何かでデータベースとして作っておき、ゲーム実行ファイルに組み込んだりします。


ただし、この方法の欠点として、実行ファイルのサイズが増えます(数値データが増えるので)。ただし、しょせん、数百個ていどの数値を記録しただけのテキストデータまたは機械語なので、あまりサイズは大きくないです。

気にするべきは、けっしてデータサイズの大小ではなく、成長曲線が単調増加であるべき事、です。

ゲーム用のスケジュール計画の注意点[編集]

※ ページ内容が完成するまでの間、このバランスのページを間借りする。

要点は

  • エンディングを先に作る
  • 機能の実験を簡易でいいので事前にしておく
  • 使用頻度の高い部分から作る

です。

エンディングを先に作る

まず、ゲーム用のストーリー(ゲームシナリオ)の作り方ですが、学校などでの作文の書き方の順序と、ゲームシナリオの書き方の順序は、違います。

まず、ゲームシナリオを作る場合、エンディングを早い時期に作ります。このエンディングは、当面の仮のエンディングなので、あまり作りこむ必要がりありませんが、しかしエンディングが必要です。

エンディングのシナリオがあることにより、そのゲームで何を主人公に目指させるべきなのかが、作者にハッキリとします。

プレイヤー視点では、開発中の段階ではエンディングが隠されているので、あたかもエンディングの作られる時期がまるで開発終盤かのように錯覚されますが、しかし実は割合に早めの時期にエンディングも作られています(同人ゲームをリバースエンジニアリングすると分かる)。


そのゲームの全体像を決めるのが先です。


また、ゲーム中盤のストーリーを作る際や、それにともなうプログラミングをする際には、将来のストーリー変更の可能性を意識しておくことが重要です。

ゲームを作るにつれて、さまざまな事情から、若干のストーリー変更をせまられる可能性があります。

もし、第1話から第10話まで全部で10話のエピソードなるゲームの場合、たとえば第4話と第5話の順序を入れ替えることになったり、あるいは第8話のために用意してたシナリオを第7話に前倒して移動したりとか、そういう細かい順序変更があったりします。

このため、あまり開発当初から、現時点でのストーリーを前提にしすぎない事が重要です。


ファミコン時代あたりの古いゲームなんかでも、メモリ解析などをしたり、バグ技などを使用すると、本来なら通常プレイではゲーム中に入手できないアイテムのデータがゲーム中に残っているのを見れたり、あるいはゲーム中のキャラの会話では本来なら表示されないハズのメッセージ文などが、ゲーム内データに残っていたりするような作品もあります。

これはどういう事かというと、ゲーム開発中に没(ボツ)になったアイデアなどが、ゲーム内データに残っていたりするわけです。


プログラムを組みときも、変更可能性の対策として、たとえば、仮に本来なら第5話で仲間になるハズのキャラクターが、もし前倒しで第4話で仲間になったとしても、ゲームにバグの起きないようにプログラムを組んだり対策しておきましょう。

とはいえ、別に難しいプログラム技法は無く、単に、特定のゲーム進行状況に限定しないようにプログラミングをしておけばいいだけです。


たとえばRPGなら、1個しか入手できないハズの限定アイテムが、もし2個入手できても、バグの起きないようにプログラムしましょう。

たとえばRPGで「扉の鍵」という重要アイテムがあって、ゲーム中で1個だけ入手でき、ある建物の「右の扉」と「左の扉」の2つの扉のうちの どちらか片方を開けたら鍵が消えるとしましょう。

プログラミングでは、もし仮にこの鍵が2個入手できてしまったり2回入手できてしまっても、ゲーム異常停止などのクリア不能バグの起きないようにプログラムしておくのが安全です。万が一、その左右2枚の扉が両方とも開けられてしまっても、けっしてクリア不能バグの起きないようにプログラムしたりするわけです。


これはつまり、ゲーム中のストーリー進行イベントの発生条件で、たとえば

「もし ○○の条件を満たしていると、次のイベント△△が起きて、ストーリーが進む」

というふうに、なるべく肯定型の条件判定にもとづくプログラムをしておけばいいのです。

一方あまり、

「もし □□の条件を満たしてしまっていると、イベント△△が起きない

のような否定型の条件判定を、あまり記述しないほうが安全だという事です。それでも否定型の条件判定をするなら、どうしても必要な場合だけ記述するようにするのが安全でしょう。


ストーリー進行の条件判定は、なるべくストーリーが進みやすいように条件設定をしておくのが、開発者にもプレイヤーにも、お互いにラクでしょう。


機能の実験

また、開発中に思わぬバグの発生や、制作ツールの仕様上の制約が判明したりなどで、いくつかのアイデアを実装できなくなる場合がありますので、盛り込みたいアイデアは早めにゲーム中に実装しておきます。

この実装が、実験の代わりにもなります。


たとえば、もしRPGツクールやウディタで、自作のRPGの後半ストーリーにシミュレーションゲームのパートを追加したいアイデアがあるなら、自分の考えたシミュレーションパートが果たして本当にツクールなどで機能するかどうか、簡易的な実験でいいので、先に実験しておきましょう。必ずしも開発中のゲーム中に同梱で入れる必要は無く、別のソースファイルで実験してもいいですが、とにかく事前に実験しておきましょう。

もしかしたら、仕様上の制約により、自分の当初のアイデアの仕様ではシミュレーションパートが追加できない、または追加が非常に困難になるかもしれない場合があるからです。


このように、プレイヤー視点では見えませんが、しかしゲーム開発者はこういうふうに、機能の実験を事前に結構しています。

テストプレイヤーに限定公開などをする段階でもう、実はけっこう多くのゲーム中の機能が実験済みだったりします。


使用頻度の高い部分の実装

アクションゲームならアクションのシステムを先に実装するのはモチロンですし、RPGならRPGのシステムを先に実装するのはモチロンです。

  1. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版第2刷発行、54ページ
  2. ^ 橋本 毅彦 著『「ものづくり」の科学史 世界を変えた《標準革命》』、講談社、2018年3月13日 第7刷発行、143ページ