まずは前回までだとキャラが重なっても平気だったので、マップの石、HEROキャラがいるマスには入れないという判定を作るところから。
特に石の判定。うーん・・どうすれば良いのか・・ようやく考えついたのが01のFlattenしたマップデータと同じ数の座標データを作って、2つのリストを並行して読み込ませる事で1の時に読み込んだ座標データだけを'()にconsしていき、キャラの移動先の座標をmemberでその座標リストに#tだったら動かない処理をする、と。前日ほぼ徹夜、昼間もバイト尽くしだったのでなかなか思い浮かばなかった・・今回はFoldで作ったけど、確かForの時に使えそうな機能があったと思ったんだよな〜とか思いながら、けど調べる気力がわきませんでした。
いずれ外部の関数にしないといけないけど、テストのためにLeftキーの場合だけを書く。Condで移動先がHERO構造体の場合も動かない判定、先程の石の場合の判定（将来的には敵の場合は攻撃発生判定も）を書いて、そうでないなら移動。移動力の消費のためにCHARACTER-Moveを減らして返す、と。
ここまでテストしてオッケイ
続いて、移動力を使い切った時に次のキャラクターがアクティブにならないといけないので
こうやって・・移動可能判定時に移動力を−1して、0になってたら移動した座標に変更した上でCdrしたC-LISTに現在キャラをConsして返す。残ってれば普通に返す、と。
これ・・ちゃんと動くのかなぁ・・と思いつつ実行
ま、動くんだなコレが！
と、まるで何事もなかったかのように結果だけ書きましたけど、今記事を書き始めた時点では失敗談を書くつもりでした。
どうしても次のキャラへの移行が思いつかなくてStop-whenで一旦終わらせて、出てきたBATTLE構造体を読み込んで次のキャラにするとか・・？などトンチンカンな事を考えてました(^_^;)
一夜明けてみると・・なんか解決するもんなんですね。記事にするために流れを再確認する作業によるメタ認知的な効果なんですかねぇ。
今日はここまで。今回もハッピーエンドで終わった(^o^)
で、次回はENEMYの行動の場合・・これがもう、どう考えても苦戦必至だ。今回の処理は全部人間がKeyを入れての反応だから良いけど、まずはプレイヤーに単純に寄って来て移動力を使い切ったら次のキャラへ・・って動作をOn-keyにどうやって入れるんだ？って話。
そもそも、On-key自体にHEROの場合とENEMYの場合でキーマップを分けるってことが出来ないと思うんだよなぁ・・
と、ここまで書いてまた疑問が湧いた。
もしかしてだけど、CaseでVariantを使って型がHEROとENEMYで場合分けしてキーマップって複数用意できるんじゃないか？（前にラピュタで複数使えなかったので思い込みがあっただけで・・）
Caseではうまく動かない。
が！Condで構造体HEROの場合を書いたら・・動いてしまった！やったぜ！いやまあ、動いてしまうと「動くだろ」とは思うんですが(^_^;) これで動くならMatch-letの問題も解決するし、後は移動部分を関数化して全部の方向キーに対応させるリファクタリング？をやれば良いな！
いまだENEMYの自動行動をどうするかという課題は残ってるけど、根本的な動作の問題が解決したので「いずれ何とかなる」問題に過ぎん！
いや〜・・やっぱり日記って大事ですね
