「ゲームプログラミング/バランス調整」の版間の差分

削除された内容 追加された内容
Honooo (トーク | 投稿記録)
Honooo (トーク | 投稿記録)
786 行
 
そのため、過去のゲームでは、ゲーム後半の調整がうまく機能せず、極端に難しかったり或いは簡単すぎたり、そんな場合も多かったようだ。ドラゴンクエスト2の後半ダンジョンであるロンダルキア洞窟とその次ステージがその典型例という指摘もある。
 
 
;手戻りを防ぐ
とくに出典は無い話題なのですが、調整の際、「せっかく調整したのに、その後前提データが変わってしまったので、再調整、前に戻ってやり直しが必要になる」という手戻りが発生しないようにしないといけないでしょうすねこのため、もし序盤のパラメータを一度調整したら、中盤以降の調整では原則、もう序盤そのパラメータを大きくはイジらない、という事です。同様、中盤の調整が終わったら、終盤からの調整ではもう中盤のパラメータをイジら変更しないようにします
 
そこでパラメータは原則定数であり、数式で決めずに、その定数での状況を実際にプレイして確認する。
 
なので、たとえば推奨できない例ですが、もし仮に一次関数や二次関数などの数式などでパラメータを決定するプログラムを内蔵すると、たとえば中盤の調整でその関数の係数をイジった際、序盤のパラメータまで変更されてしまいます
このため、けっして数式などではパラメータを決定せず、実際にプレイして確認する必要があります。
 
スーパーファミコン時代のRPG で、武器、装備品の強さのパラメータを調べると中盤での武器のランクアップの上昇幅は、おおむね一定、たとえば約10 ポイント間隔が多い。
なので、たとえば推奨できない例ですが、もし仮に一次関数や二次関数などの数式などでパラメータを決定するプログラムを内蔵すると、たとえば中盤の調整でその関数の係数をイジった際、序盤のパラメータまで変更されてしまいます。
 
多くのスーファミ時代のRPGで、武器など装備品の強さなどしかしこのパラメータを調べると、は定数にしとえば中盤での武器のい。「ランクアップごとの攻撃力の上昇幅をおおむね一定値10なっています(たとえば約10ポイント間隔の場合が多かったりする)。で、なんとなく法則性がありそうプログラムは避けるべきです。
 
それをすると、もし中盤以降で「ランクアップごとの武器上昇幅を12にしたいな・・・」となったとき、せっかく以前に確認した序盤の装備品の強さまで変更されてしまうからです。そして序盤のパラメータが変更されるたびに、実プレイによる調整をやりなおしになります。
しかし、だからといって最初からプログラミングで「ランクアップごとの攻撃力の上昇幅を10にする」などのプログラムは避けるべきです。
 
世界中のゲームには多種多様なゲームがあるので、もしかしたら装備品のランクアップごとの攻撃力の幅を1個の数式で計算するプログラムを導入しているRPG作品もあるかもしれません。
それをすると、もし中盤以降で「ランクアップごとの武器上昇幅を12にしたいな・・・」となったとき、せっかく以前に確認した序盤の装備品の強さまで変更されてしまうからです。そして序盤のパラメータが変更されるたびに、実プレイによる調整をやりなおしになります。
 
そういう作品の中にも面白い作品があるかもしれないので、そういう作品に出会ったら真似したくなるは、思います。ですがそれは調整が難しくなる、とだけ指摘しておきましょう調整不可能ではないでしょうが、初心者あらゆる人とって調整のハードルいと思いますくなるでしょう
世界中のゲームには多種多様なゲームがあるので、もしかしたら装備品のランクアップごとの攻撃力の幅を1個の数式で計算するプログラムをしているRPG作品もあるかもしれません。
 
アルテリオス式(攻撃ダメージ=オフェンスの攻撃力-ディフェンスの防御力)の特徴として、ほんの些細なパラメータの違いにより、大幅に戦闘の難易度が変わることがあります。
そういう作品の中にも面白い作品があるかもしれないので、そういう作品に出会ったら真似したくなるかと思います。ですがそれは調整が難しくなる、とだけ指摘しておきましょう。不可能ではないでしょうが、初心者には調整のハードルが高いと思います。
 
アルテリオス式の特徴として、ほんの些細なパラメータの違いにより、大幅に戦闘の難易度が変わることがあります。
 
極端な場合、防御力 80 の敵に対して、プレイヤー側の攻撃力の合計値 79 ならば攻撃ダメージがゼロになるので、絶対に敵に勝てません。
 
たとえば一方序盤のあるボス戦で、そのボス敵が防御力80 ,HP 5 なら、もし武器装備時の調整前のパラメータが攻撃力81なら、たった5ターンで勝てます。(81-80=1 でターンごとに1ダメージ与えるので。)
 
一方、たとえば序盤のあるボス戦でそして調整後に攻撃力が79に低下したら、ダメージ0になるので、100ターンたとうが絶対に勝てません。
 
このようにアルテリオス式では1~2ポイントの差で大きく戦闘バランスが変わることがあります。
 
このWikiの執筆者め、もし商業レベル作品を作りたいなら推測では、手戻りが発生するような調整をしてしまうとった場合絶対にプレイしてによる確認しなおさなければならなくが必要になるでしょう(実務経験ないので推測ですが)(なお推測ですが、市販の多くのゲームではういう事例なるべく避けるために、敵の防御力を低めに設定、丈夫な敵は防御力ではなくHPを高くする、または最低ダメージ保証(たとえば「原則、攻撃力の1割以上のダメージを必ず与える。メタル系などは別途プログラムを組む」とか)などのシステムを搭載したり)が必要にどの定石があだろでしょと思います(推測)。
 
参考ですが、ちなみに wikisource [[s:プログラマが知るべき97のこと/共有は慎重に]] にも似たような話題があります。
 
参考ですが、wikisource [[s:プログラマが知るべき97のこと/共有は慎重に]] にも似たような話題があります。
<pre>
私がコードをライブラリ化してしまったことで、それを利用する部分には依存関係が生じました。まるで、一本の靴ひもを、両足の靴に通したような状態になったのです。ライブラリのコードを1行変更しただけで、その影響は複数箇所に及びます。互いに独立していた時なら、該当部分の保守コストは無視できるほど小さかったのに、ライブラリ化してから、変更のたびに大変な手間をかけてテストをする必要が生じました。
</pre>
 
本来なら実際にプレイして確認すべき箇所で、むやみにパラメータを数式化してしまうプログラムを採用してしまうと、上記のwikisourceの例のようにテストの手間が大幅に増えてしまいます。
 
ちなみにこのウィキソースの書籍は、ちらりと見た感じでは、現編集者もいい本ではないかと感じた。
 
この本の一番最初に書いてあることは、すべての Wikimedia執筆者、全てのWeb上の発言者、すべての現実の生活者も頭の片隅に入れておくべきことだと思う。
 
以下引用します^^
 
{{Quote|何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。|作者不明}}