フリーゲーム・フリーソフトの開発過程を記録していく、TDtechnic公式ブログです。製品はカテゴリの「ダウンロード場」からダウンロードして頂けます。
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

こんにちは。前回述べた「どのコードがいつ実行されるのか」わからない状況は非常にまずいです。私のプログラムはたいてい、ここから崩れていくのです。こんなに堅牢()なタスクシステムなのに、なぜだ…。よく考えると、タスク分離がまずかったようです。
今作では調子に乗って、各モーションは切り換え時に補間するようにしています(エセ線形補間)。そのため、もしタスク遷移しようと思うと補間パターンも全て別々のモーションにしなければなりません。例えば停止・歩行・走行なら「停止」「歩行」「走行」「停→歩」「停→走」「歩→停」「歩→走」「走→停」「走→歩」ですが…あまり作りたくありませんね。更にモーションを増やそうと思ったらそりゃもうヘッダだけで大騒ぎになります。実はこれ、元祖状態遷移であるswitch文を使うと一気に解決します。停止も歩行も走行も一つのクラスで管理して、単純なフラグで合成すれば補間できます。モーションを追加する時は、caseを一つ増やすだけで全パターンに対応できます。
ところが、被弾を追加した際に問題が起こりました。被弾は強制的なものなので、別のモーションへの補間は許されません。しかし前述の通りこのタスクは全ての補間を自動サポートする設計なので、被弾時は全くの別処理に分岐することになります。でもよく考えたら被弾も前のめりと仰け反りがあって、さらに死亡モーションも…と考えていったらやっぱり無理があります(笑)強引に条件分岐で実装した結果が冒頭の状態というわけです。

この古典的な詰み方はどうせswitchが原因です。でも補間は自動でしたい。switchの改良に勤しんでいたとき、あることに気づきました。被弾や死亡を実行時に補間することはありません。動作が決まっているからです。しかもその動作は全然違います。つまり、「通常状態」「被弾」「死亡」というようなタスクを作って、switch補間はあくまで通常状態の中で行えばよかったのです。これにて原則どおりの分離ができました。

また、前回も書きましたが、当たり判定もタスクの分離を難しくする原因の一つです。これは、当たり判定モデルを統合した「ゲームオブジェクト」クラスを新たに作って、ゲームのオブジェクトは全てこれを継承することで解決しました。このクラスは、別のオブジェクトを引数に取る当たり判定用の仮想関数を持っているので、ステージが全てのオブジェクトに対してこの関数を呼び出すだけで、各オブジェクトは自分で好きなように当たり判定を行えます。これで当たり判定処理をタスク内に分離できました。
関連記事

[2014/09/05 16:57] | 不死女 -Immortal girl-
|
コメント:
この記事へのコメント:
コメント:を投稿
URL:

パスワード:
非公開コメント: 管理者にだけ表示を許可
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。