みむ*mimさんも言われているように弾の発射と弾の処理は分けた方がプログラムが書きやすくなると思います。 今は全てまとめてやろうとし過ぎて、弾の発射の処理で一度に全ての弾を同じ場所に出してしまったりしていますし、出てない弾まで位置を変えるような処理が入ってませんか？ 皆さんが言われている内容を考えてみて、わかりにくい所とか理解出来ないところとかあったらまた質問してみるといいと思いますよ。

横は完全固定？　スーパーマリオみたいに一定範囲は移動じゃなくて？

インデントというのは行頭にスペースを入れる事でIFやWHILEなどの範囲（階層）をわかりやすくする方法です。一般的な言語ではほぼ利用されている考え方です。 スペースの数は決まってなくて普通の言語だと4つが多い気がしますが、2つもあります。またプチコンの場合は画面に入る文字数が少ないので1つも多いです。 参考までに僕がインデントをつけて書いたサンプルのプログラムを載せてみます。ループはIFの範囲がわかりやすくなっていると思いませんか？　そういう効果があります。 また空行などで処理のまとまりに区切りを入れるのもプログラムが見やすくなるコツです。 こういう工夫をすることでミスが発見しやすくなり、また全体を俯瞰でとらえられるので便利な感じです。

流れとループを意識するようにインデントをつけてみるといいかもしれませんね。

一般的なカレンダーの機能をどれだけ実装するかにもよりますが、カレンダー分析機能？みたいなのがあっても良いかもですね。 例えば、誕生日があるなら、その月に誕生日な人の人数が表示される。とか？ 休日があるなら、あと何日（何時間？）で休日、みたいな表示があるとかも面白いかもしれません。 なんか日付に絡めた機能があってもいいですね。目標日を設定してあと何日の他にも、スタート日を決めて何日経過（例えば禁煙スタートみたいな？）とか？

とりあえずこんな感じ？ ちょっと微妙だけど…。 珍しく:(コロン)の省略してみた。

スプライトを使うときはSPSETがスタートですね。 ただたまにループの中で何度も同じ管理番号をSPSETしているケースを見かけますが、それは大抵は間違った処理というか、SPSETは一度使えばSPCLRするまでは再度SPSETしなければいけないケースは多くないです。 なので大抵はループの外（上）に出してしまって問題ないはずですし、その方が早いはずです。

プチコンのIF判定は０が偽でそれ以外は全て真になります。 二進数の10000は10進数だと16ですが、結局のところ0ではないので真です。ビット列の中の一つでも1になれば、それは0にはならないので結果的に真ということですね。

みんなの話をまとめた違い。 １　条件を満たしたときにループを抜ける場所（頭か最後か。頭の場合は始めに条件が満たされないときはループの中身を実行しないが最後の場合は1回は実行される） ２　ループ終了条件。WHILEの場合はFALSE(0)の時に終わって、REPEATの場合はTRUE(1以上)の時に終わる。 ３　処理速度。REPEATの方がWHILEより早いらしい。

なんか色々間違っている気がするけど、なんで76行目がそうなったのかよくわからない…。 とりあえず5行待ちたいなら、WAIT 60*5(または300)でいいですよ。60×5になるのは、WAITで指定するのはフレーム数なので、1／60秒が基準なので、1秒なら60になるので、5秒ならその5倍って感じです。

上ボタンは１なのでたまたまうまく動いたみたいですね。 ANDと＆＆の違いを理解すると簡単に直せる問題ですね。

移動して謎を解くだと脱出ゲームと言うよりゼルダっぽいですね〜。 まあゼルダ風脱出とかも面白いと思うし、単純にアドベンチャー風の画面じゃないだけで内容はコマンド選択に近い感じでも良いですしね。 はるさんの言われるように仕様書までいくとベストですが、そうじゃなくてもまずはその辺の内容のイメージを書いてみると良いと思います。 そしたらそれをある程度の段階に分解して、一つ一つ作っていけばだんだんと完成に近づくと思いますよ。

さっきはスマフォからで長文を打つのが面倒だったのでPCでちょっと補足。 SPSCALEで0にすると表示されないのはさっき書きましたが、当たり判定の範囲は変化していません。もしスケールに合わせて当たり判定の範囲も変えたい場合は、SPCOL 0,TRUEのように第2引数にTRUEを指定する必要があります。 またこのSPCOLはSPSCALEの前に実行しないといけません。SPSCALEの後にSPCOLしてもスケールのサイズは変化しないので注意。 あと当たり判定もFORで全てのスプライトに対してしようとしている感じがありますが、SPHITSPは対象のスプライトに当たったスプライト番号を返す命令なので、 IF SPHITSP(0) != -1 THEN でスプライト０が他の全てのスプライトのどれかに当たったかどうかの判定が出来ますよ。

AOがRND(3)なので0-2の範囲だから、0の時はスケールが0だから画面に表示されない（けど画面上を移動しているから当たる）という感じですよ。

とりあえず当たってないのに当たるのは、スケール0で見えないスプライトに当たっている可能性が高いですね。

即席なので微妙なところも残ってますが、ちょっとだけいじってみたのでアップします。プログラムだけなので画像は自分のものを使ってください（PRVECKNV） キャラが中央固定なので本当はX,Y座標を中央の位置として直接BX,BYを求めた方がいいんですが、とりあえずそのままの形にしています。 またSPDEFを少し変えました。SPDEFはアニメーション分用意した方がメインのプログラムが楽になるのでそうしました。 （[0,1,2,1]の繰り返しじゃなくて[0,1,2,3]の繰り返しで済むように） それに伴ってアニメーションカウンタの処理も少しいじりました。 この形にこだわる必要はありません（配列などで順番を入れる方法もある）が、とりあえずIFでのアニメーション管理が煩雑だったので変えた感じです。 まあメインは衝突の部分なのでそこのイメージだけ見れればいいかなぐらいで…。

僕はON GOTOやIF でのGOTO省略はGOTOカテゴリーに含めてしまいましたねー…。 MAINCNTについて説明しないのも始めにFORによるカウンタ変数を使っていたので、まずはカウンタ変数でのやり方を覚えるのかなと思ってました。 あとはまあ一度に詰め込みすぎると混乱しそうだというのもあったんですけどね。

合作の場合、始めから最終目標を見過ぎるとつまづくので、まずはその最終目標の段階を細かく分けて、その一つ一つを達成していく感じにした方がいいんじゃないかなって思いますよ。

とりあえず無駄を省きましたが、さらに効率化して短くすることも出来ます。とりあえずそれは課題（？）として残しておきましたが、やり方としては複数のアニメパターンの処理を一つにまとめることが必要になるので、その際は配列やREAD、DATAを使ったりする感じになると思います。（配列だけでも可） 時計の更新がうまくいかないのはメインループがしっかり出来てないからなので、その辺も今後の課題でしょうね〜。まあ上記のように効率化していくと、自然とメインループの形になったりするんですけどね。 という感じですが、自分で試行錯誤するのも大事なので、色々と頑張ってください！

ちょっと見てみました～。 細かいところはともかくとして、ちょっと気になった所を変えてみたのを載せておきます！ というのは、流れのところでメインループの意味がなかった部分を省いてデッドコードを減らしました。 参考にしてみてくださいな。