面白いと思って作ったゲームが、実際作ってみたら面白くなかった！さてどうする？

えーと、バカっぽいタイトルでゴメンナサイ（´Д｀；
　
kenmoはよくこの状態になります。
　
例えば、構想段階では、
「このゲームやべぇ…、、。面白い！面白すぎるぞ！」
とか思ったりするのですが、
作りこんでいくうちに、
「…？あれ？…全然面白くないんですけど、このゲーム」
となってしまいます。
　
　
ただ、最近、そういった状況に陥ったときの打開策が見えてきたので、
それを解説しておきます。
　
先に結論を書いておくと、kenmoなりの打開策は、

リソースの増加
レベルデザインの構築

の２つです。
　

リソースが少ない

リソースが少なすぎるためゲームが面白くない場合はよくあります。
例えば、アクションゲームを作る場合には、

敵
アイテム
地形

の３大要素はほぼ必須です。
これをリソースの「大分類」とします。
　
そして、例えば敵の種類が１つだけでは面白くありません。
色々なタイプの敵が必要になります。
これをリソースの「中分類」とします。
　
さらに、敵の思考ルーチンに、
通常モード、発狂モード、逃亡モードなどの状態遷移を持たせると、
ゲーム性が向上します。
これをリソースの「小分類」とします。
　
　
以上のことを表にしてみます。

大分類	中分類	小分類
敵	弾・雑魚・中ボス・ボスなど	発狂モード・逃亡モードなど
アイテム	回復・得点・ボムなど	出現条件・タイマーで消滅など
地形	落ちる床・移動する床など	落下タイマー・移動量など

ゲームとして面白いものにするには、
「中分類×小分類」が最低20ぐらいは存在する必要があると思います。
（なんとなくですが）
　
ただ、リソースをとにかくたくさんつぎ込めば面白いものになるわけではありません。
リソースをつぎ込むほど管理の手間は増えますし、
無意味なものはゲームを複雑化させるだけです。
　
では、どんなリソースを増やせばいいのか。
　
それは、今作っているゲームの特性を分析することです。
その特性に大きな影響を与えるものが、必要なリソースとなります。
　
影響の大きさから考えると、ゲームの目的に対する「相反的な要素」を入れると
面白いリソースになる可能性が高いです。
　
例えば、ひたすら上に進むゲームだったら、
強制的に下に進ませるリソースなんかが影響力の大きいといえますよね。
　
　
ただ、注意しなければならないのが、
リソースの増大は、レベルデザインに多大な影響を与えるということです。
　
なので、設計の段階でリソース量をある程度追加しやすいような作りにしておくことが必要です。
　
　

ゲーム開発には大きく２つの段階が存在する

もう１つkenmoが陥りがちな罠が、
「ゲーム開発には大きく２つの段階が存在する」
ことに気づかなかったことです。
　
その２つとは、

システムの構築
レベルデザインの構築

です。
　
システムの構築というのは、ゲームのコアとなる部分です。
レベルデザインとは、「プレイヤーを楽しませる仕掛け」です。
　
kenmoは最近、システム作りに満足していて、レベルデザインを放棄していたような気がします。
　
また、レベルデザインの存在を意識していなかったため、
「いつまで作っても面白くな〜い」
という状況が発生していたように思います。
　
　
レベルデザインを乱数などで手抜きすると、
「パターンを覚えてクリアする」
という楽しみがなくなり、飽きが早いです。
　
そのため、
「プレイヤーが繰り返して遊んでくれる」
という状況は発生せず、
「１回遊んで終わり」
という最悪のゲームになります。
　
ということで、
レベルデザインは、テーブルデータとして、
こつこつ手で作るべきなのです。
　
　

おまけ（外部スクリプト化）

面白いゲームを作るには、リソースの増大が重要です。
そしてリソースの増大は、レベルデザインを複雑化します。
　
そういった場合に、レベルデザインの作業を少しでも楽にする方法が、
「外部スクリプト化」
です。
　
プログラムに敵の出現情報などを、ハードコーディングしてしまうと、
どうしてもコード量が肥大化してしまいます。
また、バグも起こりやすいです。
　
なので、プログラムの外部データとして、
敵やアイテム、地形の出現情報を保持しておくと、記述・修正作業が楽になります。
　
ただ、全てをスクリプト化するのは大変です。
kenmo的にオススメなのが、
「出現情報」だけ記述できるようにすることです。
　
例えば、こんな感じです。

// 120フレーム何もしないで制御を返す
wait 120 
// ID「100」の敵を座標(0,-64)に270°方向に5の速度、90°方向に1の加速度、発狂モードで出現
addenemy 100, 0, -64, 270, 5, 90, 0.1, crazy
// ID「5」のアイテム出現
additem 5
wait 540
・
・
・

1行1命令であれば、スクリプトの設計はとても簡単です。
　
そして、敵・アイテムの細かい制御は、ハードコーディングします。
あくまで「出現情報」のみになります。
理由は「出現情報」だけであれば、スクリプトの設計が楽でありかつ、リソース追加などの修正時の影響が少ないからです。
　
あと、外部スクリプトには、

ループ（ネスト可）
変数
サブルーチン呼び出し

があると便利です。
　
これは実際kenmoがスクリプト化してみて、
「ああ〜、この機能を入れておくべきだった…」
と思った機能です。
正直これらがないと、スクリプトの可読性がかなり下がります。
　
　
以上でーす。