昨日ネガティブなこと書きまくっていたのですが、今日は一転して調子いいですｗ敵のＡＩの実装・マップエディタの作成の目処が立ち、当たり判定の処理オチを改善できました。ＡＩ→マップエディタ→当たり判定の順で書いていきます。
ＡＩについてなのですが、手持ちのスクロールアクションをやってみると敵の行動パターンは非常に単純なものでした。ランダム性はほとんどと言っていいほどなく、その単純さを敵の種類で補っているという感じでした。シューティングの時と同じで、敵の配置場所は行動パターンはランダムでなく決まったパターンのほうがいいみたいです。なので敵のＡＩを作るというより敵の動きのパターンを定義すると言ったほうがいいですね。ということなのでシューティングでやった時のように敵のパターンを作っていくという方法でやっていこうと思います。ＡＩというと格闘ゲームの敵みたいに複雑な動きをするのを指すのかな。ボスに限り（そこまでやれるか分かりませんが）ＡＩに挑戦してみようかなと思っています。
マップエディタについてですが、木や雲・石などのオブジェクトを並べていきマップを構成しようと思います。必要な情報は座標・オブジェクトの種類くらいだと思うので（ステージがある場合はステージ数も）大して苦労しないと思います。
何度も悩まされていた処理オチですがやっと改善できました。処理オチしていた地形（斜めの坂）の当たり判定ピクセル数は６００。まずＸ座標が一致している場所を調べて、一致しているのならばＹ座標を調べ判定していました。よく考えたらこの計算の回数で処理オチするはずがありません。原因はstrmid命令にありました。当たり判定のあるＸ・Ｙ座標が書いてあるテキストをmapdataという文字列型配列変数（sdimのやつ)に入れてからそれをstrmidで読み出して判定していたのですが、このstrmid命令が原因かと考え（他に原因が見当たらなかった）当たり判定の情報をmap_x、map_yという配列に入れて配列を使って判定させるようにしてみたらまったく処理オチしなくなりました。
sdim mapdata,15000
bload "map.txt",mapdata
dim map_x,600;この６００というのは当たり判定の個数です。本来変数に入れておくべきなのですが。
dim map_y,600
repeat 600
map_x(cnt) = strmid(mapdata,cnt*10+20,4);ここで配列に入れてしまう
map_y(cnt) = strmid(mapdata,cnt*10+25,4);
loop
何でもっと早く気づかなかったのかとも思いますが、うまくいってよかったです。前回地形は平らにしようと決め、地形との当たり判定にはもはや見向きもしなかったのですが、敵のＡＩについて考え終わってマップエディタが結構簡単に作れそうだなーとか考えてた時に、ふとコメントアウトしてある当たり判定のコードを見ているうちに気が付きました。必死で考えているときには気づかずどうでもいいときに気づくとは・・・。面白いものです。
今日のまとめ＆今後の課題
- 地形との当たり判定の処理オチ改善
- 敵の動きを考える
- マップエディタを作る
現在の総コード数７５３行
