「ゲームプログラミング/バランス調整」の版間の差分
削除された内容 追加された内容
→では、どうするべきか: 公式にすると、バランス調整などでも :必要なテストプレイの回数 ∝ ゲーム中の重大な選択肢の数 です。 |
→類似の問題: テストプレイ回数の公式 |
||
857 行
=== 類似の問題とテストプレイ回数 ===
上述のような問題は、レベルアップ時のパラメータ振り分け以外にも、あります。
864 行
たとえば、「レベルが5アップするごとに、習得スキルを4個の中から1つ選べる」というようなシステムの場合なら、プレイヤーがどの習得スキルを選んでも快適にゲームクリアできるように、設計する必要があります。
レベルに関わらず、たとえば、「
877 行
つまり、ゲーム中の重要な選択肢の数だけ、必要なテストプレイの回数は増えます。
標語的に公式にすると、バランス調整などでも
です。
（※ ∝ は「比例する」という意味の数学記号です。中学または高校で習っているハズです。）
または、難易度を下げることで、テストプレイを減らせます。ここで重要なことは、その場合、ゲームクリアに必要な難易度も必ず下げる事です。つまり、難易度は、ゲーム中盤とゲーム終盤で、必ず（難易度を）ほぼ統一する必要があります。
ときどき、
:ゲーム序盤～中盤の難易度は低いのに、しかしゲーム後半の難易度が高い
ゲームが、アマチュア作品でたびたび見受けられます。
せっかくゲーム序盤の難易度を低くして、たとえば低レベルでも進行できるようになっても、ゲーム終盤の難易度を上げてしまうと、ゲーム終盤でレベル上げを
する必要が生じてしまい、序盤の難易度設計が無駄になってしまいます。
また、シミュレーションRPGなどの場合で、経験値の入手回数が限定されている場合などでは、もし序盤の難易度が簡単なのに終盤の難易度は高いと、ゲーム終盤でレベル不足になるなどして、クリア不能（詰み）になる可能性があります。
こういう事も考えると、上述のテストプレイの公式を改良する必要があり、難易度も含めた必要テストプレイの回数の公式を標語的に書くならば
(必要なテストプレイの回数) ∝ (ゲーム中の重大な選択肢の数) × (難易度の高さ)
でしょうか。
== 参考文献・脚注など ==
| |||