気に入って戴いたみたいで何よりです。 ぜひ、目標の1000回を達成してください。 私は腕が死にそうになるので挑戦しませんが（笑）

QSPそのものは初心者でも簡単に作ることができますが、知識や技術向上によって同じ上限文字数なのにできることがどんどん増えていくのが楽しいです。

はるさんへ GOTOの場合は文字列化の仕方が特殊で GOTO @LA+"BEL" は GOTO "@LA+"BEL"" として処理されているためSyntax errorとなっているのではないかと思います。

SPANIM命令の使い方がよく分からないとか思ったように動いてくれないという場合は私の自作命令SPANIM2を使ってみてください。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0fsz6Tuqg

これがプログラムリストです。公開キーは【 P3KNEJZ1 】です。 目標の「1000」を達成したらぜひ教えてください！ ちなみに私は20秒くらいで腕がつりそうになりギブアップしました。

こういちさんが私の「連射計測QSP」の90秒改造してくださっていますが、単純に時間を増やすだけでは表示レイアウトが崩れてしまうため新たに「簡易計測QSP 90秒バージョン」を作ってみました。 画面表示バランスやゲームバランスもこの90秒バージョンに特化したものとなっています。

ボタンを押しても反応しないのは単純にループ内にBUTTON()関数が記述されてないからだと思います。（少なくとも見える範囲内には見あたらないためただの予想ですが） BUTTON()関数はプログラムリスト中に1回記述したらOKという類のものではなく判定処理を行うループ内に記述しておく必要があります。 ループ内にちゃんと記述しているならば、だにえるさんが書かれているように XON EXPAD の記述漏れですね。

私はプログラミング経験は30年以上ありますが、プチコン3号に慣れるのに1ヶ月以上かかりました。 プログラミング未経験の人がプチコン3号を買って1ヶ月くらいで作れるようになったという人を希に見かけますがそれはあくまで例外です。 とはいえプログラミングは誰でも習得可能なので1、2年かけるつもりでじっくりとやってみてください。 習得するのに「すごい努力」なんてする必要はなく自分が興味あることを少しずつコツコツとやることが重要です。 「プログラミングを勉強するんだ！」と気構えをするととうまく行っている間は良いですが、そうでないと「勉強＝つまらない」という認識になりがちなので「プログラミングを楽しもう」くらいでやるのが個人的にはオススメです。

線を挟んでどちら側にあるかを知りたい（相対角度が0～180度か0～ｰ180度かを知りたい）場合はベクトルの外積、相対角度が鈍角か鋭角かを知りたい場合はベクトルの内積、絶対角度を求めたい場合はATANという感じで使い分けると良いと思います。 単純に座標の大小比較だけで判断しても縦横判定は可能なのですが、難しいのは角の付近にボールがある場合です。 そういう場合でもベクトルの外積を使えばどちら側にあるのかが分かるということです。 坂道のように基準とする直線を一次関数として考えて座標を元に傾きや切片を求めるとベクトルの外積を使わなくても判定は可能になります。 こんな感じで正解は1つではなく無数にあるわけです。

Shibapediaさんへ IF文においては条件部分がtrueの場合（0以外の値の場合）にTHEN以下の処理を実行するのですが、IF BUTTON() AND #L+#A THEN ～という書き方だと「LボタンとAボタンを両方押した場合」ではなく「LボタンもしくはAボタンを押した場合」になってしまうんですよね。 ANDを使ってLボタン、Aボタンの両方を押している場合を判定するにはIF (BUTTON() AND #L+#A)==#L+#A THEN ～とか、IF BUTTON() AND #L && BUTTON() AND #A THEN ～のようにする必要があります。 Lボタン、Aボタン以外のボタンを押していてもOKか否かで記述方法が変わります。（L、A以外のボタンを押していたらダメならばMIKIさんの書き方になる）

これがMIKIさんの（SPANIM、SPHITSP）初体験ゲームですか・・・。 私は先日大量のオタマジャクシを避けるゲームを作って青い鳥SNSにて公開したのですが、511個のオタマジャクシを動かした場合でもNew3DSならば60fpsを維持できたものの旧3DSでは19fpsしか出ず速度的には辛かったですね。 処理的にSPCOLもSPANIMも使いにくいのも速度低下の要因ですが。

（続き） プチコン3号の自作命令は引数が省略できないですが、引数が原則整数値の場合はこんな感じで小数部分を使えば擬似的に引数を省略できる命令を作ることが可能になります。 ただし、1.10と1.1は区別できないため1桁の数値限定ですが3bit分のオプション設定が可能です。 なぜ、(P-Q)*10を整数化する場合はシフト演算ではなくROUNDを使っているかというと小数値は丸め誤差があるため10倍した際に期待される値にはならないためです。 例えば ((8.2-8)*10)>>0 は「2」という値になりそうですが、実際は「1」になります。（8.2-8は0.2よりも小さい値になる） これが ((4.2-4)*10)>>0 ならば「2」という値になります。（4.2-4は0.2より大きい値になる）

ツララさんへ 個人的には「（初心者であろうと）便利なものは使えば良い派」です。完成させることが何より重要なのでその後でより詳しく知りたい時になったら自分で勉強すれば良いだけと考えています。 とはいえ、SPANIMの書式が面倒なのでできるだけ簡潔に記述したいという中級者の方が使える場面は多いかもしれませんね。

「ランダム」といってもその動きには様々なバリエーションがあります。 単にX=X+RND(3)-1でランダムに左右に動けますが、これだと震えながら微妙に動いている変な人にしかならないためNPCっぽく普通に動いているように見せるためには下記のようにすると良いかもしれません。 ランダムで移動開始フラグを立てる→フラグが立ったら移動先の座標を決める→その座標へ移動 みたいな感じで問題ないと思います。 あくまでこれは一例で、自分がどのような動きをイメージしているかを考えてから作ると良いでしょう。

そうなるとくの一ではなく忍者のキャラを使用したのにも何やら深い理由がありそうですね。（性別を偽って生活しているとか）

8方向移動サンプルプログラムの一部にミスがありました。 4つ目のIF文となる IF B AND #RIGHT THEN Y=Y+1:C=1 において#RIGHTではなく#DOWNです。 ただのタイプミスなので公開キーによってダウンロードしたリストは全く問題ないので安心してください。 それ以外にも何か問題があれば言ってください。 SPANIM2命令は十分なテストを行っており普通に使う限り不具合は見られませんが、それでも何らかの不具合がもしも見つかれば報告お願いします。　

glatteHautを使ってみましたが、やはり一番最初の何も選択していない状態では描けないというのは辛いですね。 それ以外は少し使っただけで操作に不慣れな部分もあるため割愛しますが、mohさんの××をモチーフにしたようなブラシスライダーはなかなかユニークで良いと思います。

私が先日作ったCHANGE_LR関数は青い鳥SNSで書いたようにプリセット値が左右ボタンの完全入れ替えになっているからそう命名しているだけであって単純にボタンのテーブル化をしているだけなのでどのボタンをどのボタンへと変更するのかは簡単に設定できます。 個人的にはボタン割り当ては使用頻度と同時押しの必要性で考えると良いと思います。 決定はA、キャンセルはBというのはパッドとして利用している状態ではベターな選択ですが、絵を描いている時はベターな選択かというとそうではなくこれは決定とキャンセルを何に使うのかどれくらいの頻度で出てくるのかで変わってくると思います。

一部訂正 ベクトルの外積において「Ax*By-Ay*Bxを求めれば相対角度が分かる」は正しくは「Ax*By-Ay*Bxを求めればsinθの値が分かる」です。 角度をちゃんと求めようとするならばarc sin（ASIN関数）を使う必要があります。

ブロックの中心を原点(0,0)とした時のブロックの頂点の座標を(AX,AY)、ボールの座標を(BX,BY)とすればAX*BY-AX*BYが正か負かでブロックの中心と頂点を結んだラインを境にしてどちら側にボールがあるかが分かります。これを利用すれば縦横どちらに当たったのかの判定は可能ということです。 あとは、先日の坂道の当たり判定のようにGRPを使って縦横判定を行うという方法もあります。 ブロックやボールがスプライトであってもGRPの上に描画するなり透明色のGRPを使えば何ら問題はありません。 方法は1つではなく無数にあるので用途などに応じて選択すると良いと思います。