いまのところ演出の処理は更新メソッドに詰め込んでいくことになりますから、泥臭くなるのは仕方ないです。
もちろんある程度実装を進めるごとにまとまった部分を関数化するなどのリファクタリングを意識してください。
わたしが書いたサンプルプログラムでは、Chara::anim_countがアニメーションフレーム数とアニメーション再生フラグの両方の機能を担っています。
なのでアニメーションフレーム数を代入した時点で再生が始まってしまい、一時停止することができません。
待機というのは第1フレームで一時停止させることと同じです。
一時停止は真偽値を持つ変数をひとつ用意することで可能になります。
土門 さんが書きました:移動先のマスになにがあるかを移動する者が判定してやれば、
一番話が早いという考えなのですがこれはナンセンスでしょうか?
フラグの種類をむやみに増やさずに、移動先のマスにアイテムやブロックがあるというのは
どのように判断させてやればいいのでしょう。。。それもわかりません。
キャラが他のキャラを直接判定するためには、キャラが他のキャラすべてを知っている必要があります。
最初に土門さんがアップロードしたプロジェクトでは、キャラの組み合わせごとに条件分岐が書いてありましたよね。
あのような形だと新しいキャラの種類を増やすたびにキャラの組み合わせを増やしていくことになります。
2種類なら組み合わせは2
3種類なら組み合わせは5
4種類なら組み合わせは9
アイテムひとつ増やせば組み合わせが一気に増えます。
組み合わせに漏れがないかなど気を使うことになります。
過去に書いたコードがどんどん負担となって覆い被さってきます。
がむしゃらに進むこと自体は悪いことではありませんが、進む方向を誤ると何もかもが無駄になります。
失敗は成長の糧だとしてもただ同じ失敗を繰り返すことにメリットはありません。
組み合わせを1つしか用意しないのがわたしのやり方です。
最初からひとつしかないので過去に書いたコードの影響を受けません。
コードを書くときに考える必要があるのはいまやろうとしていることだけです。
土門 さんが書きました:進入禁止判定メソッドがあくまで進入禁止かどうかを判断するためのメソッドとするならば
オブジェクト同士の判断の処理として、当初のやり方と同じように
オブジェクト同士の接触判定クラスを利用していいのでしょうか??
土門さんが用意した接触判定クラスというのは、比較する対象である自分と相手を直接参照しますよね。
進入禁止はマップ上で進入禁止になっているかどうかを判定しているだけです。
キャラが自分の立っている地面を見るだけです。
誰が進入禁止フラグを立てたのかなんてことは判定時に知る必要がないことです。
ゲームのキャラというのは、概念的には同じ世界で動いているのではなく、個々のキャラはそれぞれの独立した並行世界にいます。
すべての並行世界が同じ形をしているので、重ねてみるとひとつの世界のように見えますが、キャラ同士には接点がないのです。
ですから接点のないもの同士で比較等を行う処理というのは、とても非効率的なことです。
キャラと常に接点があるのは地面、すなわちマップですから、マップを通して他の並行世界と同期を取るのがもっとも効率が良いというわけです。
というわけでクラスにまとめるべきなのは、地面です。
現時点では各キャラに二次元配列を渡して直接フラグを使わせていますが、各キャラが自分の情報を地面に渡して進めるかどうかなどを判断してもらうというのが理想形です。
アイテムの効果などを特殊効果としてまとめて、地面の役割とすることもできます。
特殊効果に抽象化することで、回復アイテムでも回復の泉(地形)でもヒーラー(キャラ)でも同一に扱えます。
特殊効果は回復だけではありません。
罠によるダメージ、地形によるダメージ、戦闘によるダメージ、これらもすべて同一に扱えます。
新たにクラスを作ることにしたらスレがとてつもなく伸びてしまうので中間的な実装に抑えました。
ですから、現時点でも設計としてはあちこちいびつなところがたくさんあります。
いびつなところを直す方向で実装することをお勧めします。
少なくとも並行世界同士に接点を持たせると世界そのものが崩壊しますからそこだけは避けましょう。
複数の並行世界に同時に触れることのできる神の視点を持つオブジェクトを必ず用意してください。