おいらもがんばるナリ!

初めて触ったオフコンのBASICがLOCATE Y,Xだったわ

ぼくなんかミーバースの存在すらプチコン買うまで知らなかったもんねー ﾁｸﾁｮｰ!

壁の方はottaさんと同じ感想です 演出なのかもしれませんが、単に場当たり的なコードのようにも見えます えさをばらまくのも無駄が多く、ループ内で代入している(42,45行)とか、乱数の指定に定数を使っているとか、やり直し判定？にcontinue文がないとか、全体的に作りが甘いような印象を受けます

一から作りなおしたら、挙動も行数もさほど変わらないけど、だいぶ読みやすいコードになりました ねこはちさんの助言のおかげで工夫できました　ありがとです 今度はツララさん提案の探索を作ってみたいと思います いい歳した大の大人が平日の朝っぱらから何やってんだかw 休みだから遊んでんだが

起きて気付いた MOD使えばいいだけでしたorz

ねこはちさんの角度案は「うーん」と思ってましたが、「角度」を「方角」として見たら、新たな発想が浮かびました 先に述べた通り、上から時計回りに0,3,4,1と方向を設定してます それを0,1,2,3（≒0°,90°,180°,270°）とすれば楽だなと さて、3の次を0にするにはどうしようかな…zzz

ぼくの場合も実際に試してみたら…なんですよね…w 自信を持って作ってみたらgkbrとさほど変わらんてオチw gkbrのくせにやたらコードが長い クッソーｸｯｿｰ！

仮想コードから動作を想像してみましたが、壁に当たるまでは直進するって感じでしょうか？ ドン突きでないと方向転換しないような？

特に変更してませんよ 具体的な動作を見てもらうための公開キーなんで 敵の数を増やして初期位置をランダムにして色も変えてみたらえらいことになりましたｗ

大山鳴動して鼠一匹 W3VXV3J4

コードの長さも然りなんですが、実際の動作の方も、なんかgkbrコードよろしくの動きなんですよね 自分なりに考えた割にはたかが痴れてたって言うか もっとエレガントな方法はないもんでしょうか…

角度じゃなくて向き情報は持たしてます 各方向を上から時計回りに0,3,4,1（2は無効）としてます

こんな感じ。 ☆動作はします

移動ルーチンの考え方は以下の通り 移動したい方向を乱数で取る 　移動してきた方向を取った場合やり直し 　移動したい方向に壁があった場合もやり直し やり直しが続いた場合反転する（袋小路に陥ったと見なす） なんかどっっか穴がある それか、考え方自体がおかしい ぼくにはもう無理

＞ねこはちさん x,yの2の倍数値のところは必ず壁 その4方どこか一箇所も壁 て感じで作ってます 昨日ぐらいにZEXさんが同じアルゴリズムを使ったゲームを投稿していたんで、それを参考にしてください 同じアルゴリズムでも書く人によってはこんなにも差があるとは…orz

後退しないランダム移動ルーチンを作ってみたけど、なんかやたら長い… 考え方の段階でおかしいんだろうか？

chkchrと言う関数は、指定座標のキャラクタコードを取る関数です なので、移動、表示したあとに、そこのキャラクタコードを取っても、自分のキャラクタコードしか入りません 移動する前に、移動後の場所を想定(chkchr(x+bx,y+by))してキャラクタコードを取ることで、当たり判定の目安となります （ついでに言えば、当たってない判定をされた後でないと、移動してはいけない。当たってない判定をせずに移動すると当然壁にめり込む） chkchr自体は当たり判定の「目安」となるものであって、当たり判定自体は自分で書くものです

ぶっちゃけ言います 移動用の増分と実座標を分けて考えて下さい 移動前に移動後の状態を想定し、その判定をして下さい 現状コードでは 移動用の増分を加減算している 移動したあとに、更に移動後の状態を判定をしている です 代入すべきを計算していることがそもそもの間違いです とは言え、こうやまさん以外の方々は指摘してますね 計算を代入に変えたとしても、処理順序に問題があります 「なんで移動後に、その後の移動先を判定している？」 けいさんあとは任せた←さっきのしかえしw

けいさんひでーな＃ まあいいや その上で 自機を4方向に押した方向に動かすようにするにはどうしたら良いか？ →斜めの処理をなくそう →上の場合は上だけにし、左右は無効にしよう →ボタン判定時は各座標の増分だけ記すようにしよう と、更に設計を掘り下げていきます 掘り下げはともかく、おおまかな設計が自分でもできてないように思えます 一度、それを「ノート」に箇条書きしてみてください それが「流れを読む一番のコツ」だと思います