なるほど〜…。 基本的にGOTOで飛び回るのは設計的にはあまり良くない感じもあるんですよね…。まあでもケースバイケースなので使い方によっては問題ないパターンもありますが、それは見てないのでわからないし…。 とりあえずGOTOで飛んでまたすぐにGOTOで戻ってくるようなプログラムがあったらGOSUBにするとか、そんな感じですかねぇ…。

WHILEやREPEATから抜けるときはBREAKという命令があるのでGOTOはほとんど使わなくても大丈夫なはず。出来るだけGOTOは減らせるなら減らした方がいいですよ〜。 まあGOTOやGOSUBはBAISCの特徴でもあるので使わないまで極端に制限する必要はないと思っていますが、使わなくても大丈夫な場所に関しては上記のBREAKやDEFなどを利用したりして減らした方がいい感じです。 SPANIMを待つときはSPCHK命令を使った方がいいです。この時に単純にSPANIM開始したらSPCHKで終わるまでウエイトするという方法もありますし、逆にコマンドが実行されたとき（ボタンが押された時など）にSPCHKでアニメが終わってるかもチェックして終わってなければ処理をスキップするという方法もあります。 後者の方がプログラムを並列に動かせるので、慣れればやれることが増えるので便利ですね。

なるほど〜。OPTION STRICTつけているなら単純なスペルミスでのバグなどは防げそうですね。 プログラムにバグは付きものですがたくさんのバグを経験することで、だんだんとバグに関する勘どころも強くなり、バグが少なくなったり、バグが出たときに原因を突き止めるのが早くなったりすると思うんで、それはそれで経験なんだろうなーって思います。 始めからバグの全く無いプログラムが書けたら理想ですが、そんな人はほとんど居ないでしょうしね〜。（一部の天才には居るのか？！） 今って、GOTO、GOSUBは多用している感じですか？　GOTOは出来るだけ通常のループ命令（WHILEやREPEATなど）、GOSUBはDEFに変えていくことでも多少はバグが出にくくなるとも思います。 という感じですが、これからも頑張ってください！

あ、勘違いさせてしまっていたらすいません。 変数を壊した可能性というのはあくまで自分のミスでということです。（変数名の重複があったりなど） プチコンの場合、配列などは変な扱いで壊れる可能性があるみたいですが、それ以外では通常は変数の値がおかしくなる事はないはずです。 基本的にはおかしな症状はほとんどが自分のミス（プログラムのミス）で、システムのミス（バグ等）は滅多な事ではありません。なので動作がおかしい場合、なんらかのミスをしている可能性が高いです。 公開キーなどを出せるのであれば他の人に調べてもらう事も出来ますが、そうじゃない場合は自分で解決するしかないので、色々と気をつけて調べてみるといいと思います。 あともしOPTION STRICTを使ってなかったら使うのもオススメします。プログラムのミスが発見しやすくなるので…。

勉強のためにシンプルなプログラムを書いてみるのは良いことだと思いますー。 不具合じゃないけど7行目だけPRINTが？なのが気になったり…。どっちでも良いけど統一した方が良いかも…？　まあ統一じゃなくても1行に収めるためにあえて？になったという理由があれば気にならないんだけど、そういう感じでもない気もするし…。 あと僕の場合は:（コロン）の使い方というのも考えたりします。基本的には1行1命令の方がすっきりするのですが、関連性がつよいものは:で繋げてもいいかもという考えがあったりするので…。ただ1行に収まらない場合は:は使いません。 とまあそれは僕の考えなので真似する必要はないですが、色々考えてプログラムを書くようにすると自分なりの個性が出るような気もしますし、これからも頑張ってください！

ぶつかったときにフラグを立てても動けなくなるので、ぶつかったら戻すようにしないとダメかと…。 BGの場合はぶつかる前に移動先を調べて動かない方法もありますが、SPHITSPの場合はぶつかったときの処理になりますしね。 とりあえず簡単な方法は、移動前の座標（一つ前の位置）も保存しておいて、SPHITSPでぶつかったときは、その前の座標に戻すようにする感じかなぁ？ ただこのやり方だと複数のスプライトが同時にぶつかったり相手のスプライトも移動していたりすると厄介かもしれませんが…。

解決したのでよかったですが、症状や解決内容から考えると自動イベント発生後の処理でボタン判定に影響する変数を壊してしまったのではないかと思う感じですね。 まあ解決したので問題ないとは思いますが、プログラムの流れや使用変数には気をつけないとよくあることではあります。とくにGOTO、GOSUBやDEF命令でのローカル変数未使用などの場合は変数の上書きは見落としやすいので注意してください。 ではでは。

横入り。 IF FLG==1 THEN は IF FLG THENと書けますよ。 IFは0か0以外かで判断されるので、省略するのはよくある感じです。とくに変数が真偽（TRUE(1), FALSE(0)）のみを保持している場合や関数が真偽を返す場合などは、省略しても混乱もなく短くすっきり読みやすくなるメリットもあるんです。

ちょっと補足。 DEFできちんとENDしておけば、その外では同じ名前の変数名を使っても大丈夫です。ただし上記のようにDEFの中でDIMやVARで宣言されている変数だけなので、宣言してなかったら二重定義のエラーになっちゃいます。（ということでLとIも宣言に足しておくとよい） そうすれば普通にB=BUTTON(0)としてもエラーにならないですよ。

83行目のDEFが閉じてないみたいだけど大丈夫なのだろうか…。 96行目にENDを入れて、DEFの終了をしないとまずそう。 あとDEFの中の宣言した変数はローカル変数になるんだけど、LとIは宣言し忘れているので、DIMの後ろにLとIも追加してください。これは僕がつけ忘れただけだと思うけど…。

あ、あとアニメのDATA文に関しては人による感じかなぁ？ DATAとして1箇所にまとめられるので、そういう面では管理しやすい面もあると思いますし、DATA（動き）としてプログラムで切り替えたい場合もDATAの指定先を変えるだけでよくなるので便利ではあります。 ただ直書きの場合、コードの流れで出てきたSPANIMの動きがわかりやすく感じる面もある（DATAを追わなくていいから）しケースバイケースな面もありますね。 他にも配列で指定するやり方もありますが、これは動きそのものを動的にプログラムで作りたい場合は有効です。ただ決まった動きならわざわざ配列にいれずに直書き、もしくはDATAになると思います。 という感じですね〜。プログラムの規模によっても変わってくる面があるし、色々と試してみるのもいいと思いますよ。

教えてもいいのですが、せっかくなのでだにえるさんも言うようにヘルプで自分で調べる方法を身につけた方が今後のためになると思うので、とりあえずヘルプをみてみたらどうでしょう？ ちなみに2番目の引数だけ補足というか、2番目の引数はアニメ対象なのですが、リストを見ると3と数字で指定していますが、ここは文字列で指定する方法もあります。 個人的は数字よりも文字列の方がわかりやすいと思うので、3よりは同じ意味である"I"の方が良いような気もしています。ちなみに３（もしくはI)は定義番号の指定になります。 0の場合はXY座標の指定になるんですが、その時も文字列だと"XY"になるので、そっちの方が直感的にわかりやすい（見やすい）と思いますしね。 ヘルプを調べてもわからない事があったらまた質問してみてください。

そういえばプチコンマガジンもそうでしたね…。たしか大喜利はやったはずですし、2号が出ても良さそうな感じなんですけどね。 BIGもあるしスマイルブームに余裕がないのかなぁ、とは思いますが…。

ありがとうございます！　使いやすさには気をつけて作ったので嬉しいです。 公式マップツールで気になった点はほとんど改善したはずなのでマップは作りやすくなったと思います。 よろしくお願いします。

こっちも見つけました。PUCHI-MAPの紹介ありがとうございます！ ちなみにマップ可変の場合は、読み込む命令紹介の「LOADBG2」を利用してください。それ以外は公式マップツールのサイズ（64×64）に固定なので…。 なにかわからないことがあったら聞いてください！　ではでは〜。

スプライト用の画像が適切かな？ BG用の画像とかもあるしね。まあ要は画像ではあるけど…

プチマップ使ってくれてありがとう。

手を抜くなら回転・着色・伸縮あたりの組み合わせでなんとかならないかなぁ…？

どうせならコメントとかに実行時の画面とかを載せると興味持ってダウンロードする人が増えるかも？

グラフィック全部を使ったらダメだけど半分の範囲なら分けて読み込んで合成すればいいと思うんだけど、そういう話じゃないのかな？