制作中のゲームが
ようやく完成が近くなってきました。
会話イベントの細かい演出調整
画像では伝わりにくいですが
このゲームはキャラ同士の
会話イベントがメインとなるので
会話イベント演出の細かい調整が必要です。
細かい調整と言ってもそれほど大した事はしていませんが
キャラ数だけはやたら多いゲームなので
イベント数もそれなりにあり
少々大変なところではありますが
大体できあがってはいます。
エンディングとちょっとしたコンプリート要素
このゲームでは銀行強盗の人質にされた
女性を救助できればクリアというルールです。
クリア成功時のエンディングを作成しました。
また、召喚できる女神は
全部で13種類いるので
全ての女神を1回以上召喚できたら
ちょっとしたお祝いメッセージが出るようにしました。
システム
このゲームでは、
フキダシが画面に出現している時にクリックすると、
出現しているフキダシの内容に応じて
女神が召喚されるシステムです。
フキダシの種類は乱数で決定しています。
先週の時点では、単純にランダムで
フキダシが選ばれるようになっていましたが、
ただ単にランダムにフキダシを表示させるのではなく
ある程度内容を制御するようにしました。
運が絡む要素はデバッグが大変
乱数が結果に影響するもの、
言い換えると「運」が絡む要素は
ちょっとデバッグが大変です。
例１：運が絡まない動作
例えば、
宝箱を開けたら100%の確率でAというアイテムが出現する
という動作を作るとします。
これは結果が運に左右される要素がありません。
これが正常に動作するかどうかを
確認するとしたら
実際にその宝箱を開けてみて
Aというアイテムが出現するかどうかを確認する
これだけで動作確認はOKです。
最低でも1回確認すれば済みます。
例２：運が絡む動作
では、次のような動作はどうでしょう？
宝箱を開けたら20％の確率でAというアイテムが出現し、
80％の確率で何も出現しない
これは運によって結果が変わってきますね。
これが正常に動作するか確認するとしたら
宝箱を開ける試行を何度も繰り返し
Aというアイテムが出るのが20％
何も出ないという結果が80％
程度の割合になっているかデータを取る
という作業が必要になってきます。
宝箱を何度もを開ける作業が必要になるので
運が絡まない場合に比べて
確認の手間がかかるという事です。
上記の例だと
きっちり20％、80％の確率になっているか
調べようとすると数十回は試行が必要になるでしょう。
だいたい20％、80％に近い割合になってる事がわかればいいや
という場合でも5～10回程度の試行は必要かと思います。
運絡みの要素はデータ取りが手間
つまり、運が絡む要素を作った場合
ちゃんと動作しているか確認するためには
十分な回数の試行を行い
データを取る作業が必要になってきます。
もちろん、運が絡まないからといって
デバッグが簡単とは限らないのですが
運絡みの要素はデバッグしようとすると
試行を重ねる事が必要になるので
そこが手間になるよねって話です。
私が作っているフキダシで女神を選ぶシステムも
運絡み要素なので
プレイを重ねて動作を確認していきます。
にほんブログ村
ゲーム制作ランキング
